Practice and Adopt MoRE — Tools, Examples, and Pilot Guidance

Computational-thinking prompts

Use one loop from intent to Evidence.

Frame state

What current state and required state matter?

Decompose

Which smaller transitions are coherent and independently verifiable?

Specify

What inputs, outputs, constraints, errors, and Evidence define each boundary?

Compose

Which Black Boxes produce inputs or consume outputs through each Seam?

Evaluate

What Evidence will establish an acceptable outcome for this Work Item?

Learn

What should change in the current or next model?

Pattern recognition is Evidence, not permission to generalise early. Reuse a template or capability only after the boundary has genuinely repeated.

Contract-first design

Describe observable behaviour, not internal tasks.

Boundary

The Seam being described and its producers and consumers.

State and flow

Applicable current state and/or inputs, required state and/or outputs, errors, and side effects.

Constraints

Invariants, compatibility, security, reliability, performance, and current scope.

Evidence and change

Acceptable Evidence, rollout, migration, rollback, versioning, notification, and change history.

A Contract need not be an API. A migration, research decision, refactor, or manual process can define a transition and acceptable Evidence.

As guiding practice, do not treat stated requirements as facts waiting to be collected. Ask what need they serve, whether they express a changeable policy or proposed solution, and what feedback could improve them. This reflects the “requirements pit” in The Pragmatic Programmer by David Thomas and Andrew Hunt; it is guidance rather than a strict MoRE definition.

Coherent Work Items

Split when a smaller boundary reduces shared knowledge.

A useful Candidate Item has a meaningful outcome, one coherent contract, and independent evidence. It should fit its prospective owners' normal planning horizon. Stop splitting when another cut would expose implementation steps, remove observable value, or create more coordination than it removes.

A Scrum team may use one Sprint as a local sizing heuristic. That is not a universal MoRE limit, and multiple owners remain possible where the organisation allows them.

Architecture-neutral

Choose the level that makes the seam understandable.

Modules and services

Public APIs, events, errors, compatibility, and operational behaviour form the contract.

Ports and layers

Treat a public interface as the boundary and hide internals that consumers do not need.

Events and pipelines

Include ordering, timing, retries, failure behaviour, and data-quality constraints.

Manual or research work

Use decisions, reproducible findings, process outcomes, and state changes as evidence.

Evidence

Agree what an acceptable outcome means.

Evidence may show that the Contract was fulfilled, that the intended product effect occurred, or both. Teams choose what is appropriate for the Work Item and record when it can reasonably be observed.

Claim	Useful Evidence
Behaviour is correct	Contract or acceptance tests and examples
Migration reached the required state	Pre/post checks, reconciliation, and rollback evidence
Reliability or performance holds	Metrics, thresholds, and load or failure tests
User workflow creates value	Demo, usability evidence, or product measure
Research resolved uncertainty	Decision record and reproducible findings
Security boundary holds	Threat analysis, automated checks, and review evidence

“Implemented” is not Evidence. Agree the acceptable outcome before commitment, evaluate it during Execution, and present the available Evidence at the final Demo.

Integration and operations

Make compatibility and operability part of the seam.

Identify producing and consuming teams.
Version or sequence incompatible changes.
Define migration, fallback, and rollback where failure could strand a consumer.
Test at the narrowest stable boundary that proves compatibility.
Include relevant security, accessibility, privacy, reliability, and performance constraints.
Provide logs, metrics, traces, runbooks, or audit records when needed for proof or support.

Template

Work Item

# [Outcome-oriented title]

## Product intent and value
Why this transition matters; relevant background and reasoning.

## Current state and/or inputs
What exists or enters the boundary today.

## Required state and/or outputs
What must be observably different.

## Contract and current scope
Constraints, errors, side effects, invariants, in scope, and out of scope.

## Seams and dependencies
Producing teams, consuming teams, and external dependencies.

## Risks, assumptions, and change boundaries
What remains uncertain and the agreed risk, cost, or time boundaries.

## Evidence
What an acceptable outcome means, how it will be observed, and when.

## Ownership
Owner or owners (preferably a Team or collaborating Teams, with an optional named driver) responsible for driving the Work Item.

## Decisions and change history
Readiness decision, commitment, Contract amendments and agreement, and product decision.

Apply the canonical Refinement and Execution rules rather than copying separate checklists into the template.

Worked Work Item

One checkout outcome through the full lifecycle.

This example shows how the same Work Item accumulates clarity, commitment, Evidence, and change history. It is illustrative rather than a required document format: a team could keep this information in Jira, another tool, or linked records.

Product problem: a customer can authorise payment without receiving an unambiguous order confirmation, while Fulfilment and Notifications lack a stable handoff.

Values that differ carry a Changed since previous snapshot label. The Discovery snapshot is the baseline, so all of its content is new.

Modelling · After Discovery

What changed: Product intent became the first Candidate Item. Unknowns are visible rather than prematurely resolved.

Title and state: Confirm a paid checkout and hand off fulfilment — Candidate Item.
Product intent: Customers should know that an order was accepted, and downstream teams should receive a dependable handoff.
Current state / inputs: A successful payment authorisation returns to Checkout, but confirmation and downstream handling are inconsistent.
Required state / outputs: A durable customer confirmation and a fulfilment-ready order. Exact outputs remain to be refined.
Contract and scope: Outer boundary begins with accepted payment and ends with customer confirmation plus downstream handoff. Payment authorisation and warehouse processing are out of scope.
Seams and dependencies: Payments produces the initial signal; Checkout owns the transition; Fulfilment and Notifications may consume its outputs.
Risks and boundaries: Duplicate or delayed payment callbacks, guest contact details, and order identifier timing remain unknown. Change boundaries are not yet agreed.
Evidence: Not yet agreed. The PO expects an observable customer confirmation and a reliable downstream handoff.
Ownership: No execution owner. The Product Owner and affected delegates are modelling the item.
History: Discovery created the Candidate Item and assigned the open questions for preparation.

Refinement · After Main Refinement

What changed: Consumer challenges strengthened the event Contract, duplicate handling, accessibility, and failure behaviour.

Title and state: Confirm a paid checkout and hand off fulfilment — Candidate Item under Refinement.
Product intent: Give customers a durable order reference and let downstream teams act on one confirmed order.
Current state / inputs: PaymentAuthorised supplies payment ID, checkout ID, amount, and timestamp; delivery and basket data remain available by checkout ID.
Required state / outputs: Persist one confirmed order, render an accessible confirmation, publish versioned OrderConfirmed, and request a confirmation message.
Contract and scope: The event includes order ID, line items, amount, delivery address, and schema version. Duplicate inputs return the same order ID. Publishing cannot precede persistence; retry exhaustion must be observable.
Seams and dependencies: Payments, Checkout, Fulfilment, and Notifications agree the input/output boundaries and version-one schema.
Risks and boundaries: Provider delay remains a bounded operational risk. A change exceeding one iteration, changing the schema obligation, or making the Evidence unsuitable returns to Refinement.
Evidence: Duplicate-input tests, consumer contract tests, accessibility checks, reconciliation, retry/failure telemetry, and a customer-flow demonstration.
Ownership: Checkout Team remains the prospective owner; Fulfilment and Notifications own their consumer checks.
History: Fulfilment challenged missing line items and versioning; Notifications challenged retry visibility; the team added accessibility Evidence.

Refinement · After the readiness decision

What changed: The Product Owner and Checkout delegate recorded readiness and aligned affected delegates on the shared Contract.

Title and state: Confirm a paid checkout and hand off fulfilment — Ready Work Item.
Product intent: Give customers a durable order reference and let downstream teams act on one confirmed order.
Current state / inputs: Accepted, versioned PaymentAuthorised input plus delivery and basket data resolved by checkout ID.
Required state / outputs: One persisted confirmed order, accessible customer confirmation, versioned OrderConfirmed, and a confirmation-message request.
Contract and scope: Idempotent confirmation, stable order ID, persistence before publication, retryable recoverable failures, and observable terminal failures. Payment authorisation and warehouse execution are out of scope.
Seams and dependencies: Producer, owner, and consumer delegates have aligned on the version-one Contracts and sequencing.
Risks and boundaries: Provider delay remains visible. Cost/time, schema, ownership, and Evidence boundaries are recorded.
Evidence: Automated behavioural and consumer tests, accessibility review, reconciliation, telemetry, and final customer-flow Demo.
Ownership: Prospective owner: Checkout Team. Execution ownership is confirmed during Planning.
History: PO and Checkout delegate recorded Ready and aligned affected delegates; no unresolved concrete challenge remains.

Commitment · After Planning

What changed: Priority, estimate/sizing, owner, and commitment were recorded without creating another lifecycle state.

Title and state: Confirm a paid checkout and hand off fulfilment — Ready Work Item, committed.
Product intent: Give customers a durable order reference and let downstream teams act on one confirmed order.
Current state / inputs: Accepted PaymentAuthorised input plus delivery and basket data.
Required state / outputs: One persisted order, accessible confirmation, versioned fulfilment event, and message request.
Contract and scope: The Ready Contract remains unchanged.
Seams and dependencies: Payments input and Fulfilment/Notifications outputs are sequenced for compatible deployment.
Risks and boundaries: Recorded boundaries remain current; provider delay is monitored rather than resolved in advance.
Evidence: The Ready Evidence plan remains current.
Ownership: Checkout Team owns delivery; Maya is the Work Item driver. Priority: current product goal. Estimate/sizing: fits the team's next iteration.
History: Planning verified estimate/sizing and priority, confirmed affected-delegate alignment, named the owning team, and recorded commitment.

Execution · After early feedback

What changed: A partial customer-flow demonstration corrected misleading language before completion.

Title and state: Confirm a paid checkout and hand off fulfilment — in Execution.
Product intent: Give customers confidence that the order was received without implying that it has shipped.
Current state / inputs: The agreed payment, delivery, and basket inputs remain unchanged.
Required state / outputs: The confirmation now says “Order received” and shows the stable order reference; downstream outputs remain unchanged.
Contract and scope: The observable wording changed; idempotency, persistence, publication, retry, and scope constraints remain unchanged.
Seams and dependencies: No producer or consumer Contract changed.
Risks and boundaries: The wording clarification remains within the agreed time and risk boundary and does not affect ownership.
Evidence: The customer-flow Demo must show the revised wording; accessibility Evidence remains applicable.
Ownership: Checkout Team and Maya remain responsible.
History: Prototype shown to PO and Support; PO clarified the language; the living Contract was amended and Execution continued.

Execution · After a Contract change

What changed: Implementation revealed that some guest orders have no email address. Relevant parties amended the output and Evidence without invalidating commitment.

Title and state: Confirm a paid checkout and hand off fulfilment — in Execution under an amended Contract.
Product intent: Every customer receives an on-screen durable reference; customers with a deliverable address also receive a message.
Current state / inputs: Payment, delivery, and basket inputs are required; email is now explicitly optional.
Required state / outputs: Confirmation page and OrderConfirmed are always produced. A message request is produced only when a deliverable address exists.
Contract and scope: Missing email is valid rather than an error. All other persistence, idempotency, event, retry, and scope constraints remain unchanged.
Seams and dependencies: Notifications accepts an optional request; Fulfilment and Payments Contracts are unchanged.
Risks and boundaries: PO, Checkout, and Notifications agree the item remains coherent. The change fits the time boundary and existing ownership remains suitable, so Refinement is not reopened.
Evidence: Add guest-without-email and guest-with-email examples; all previously agreed Evidence remains applicable.
Ownership: Checkout Team and Maya remain responsible.
History: Optional-email amendment recorded with agreement from PO, Checkout, and Notifications; Execution continued.

Execution · After Definition of Done

What changed: Implementation and delivery completed, and the agreed Evidence turned the Work Item into a Result.

Title and state: Confirm a paid checkout and hand off fulfilment — Result, ready for final Demo.
Product intent: Customers receive a durable order reference and downstream teams receive one dependable handoff.
Current state / inputs: Production accepts the agreed payment input and resolves required checkout data; email remains optional.
Required state / outputs: Deployed confirmation page, one persisted order, versioned fulfilment event, and conditional message request.
Contract and scope: The amended Contract is implemented and its history is current; no required delivery work is hidden.
Seams and dependencies: Producer and consumer compatibility checks pass against the deployed version-one Contracts.
Risks and boundaries: Provider-delay telemetry and retry runbook are in place. No remaining risk invalidates the Result.
Evidence: Idempotency tests pass; consumer tests pass; accessibility review passes; reconciliation shows one order per payment; retry telemetry is visible; guest examples pass.
Ownership: Checkout Team delivered the Result and retains operational ownership.
History: All amendments, deployments, Evidence, and DoD decision are recorded.

Closure · After the final Demo

What changed: The Product Owner accepted the Result and the Work Item closed. Later product learning can create or amend future work.

Title and state: Confirm a paid checkout and hand off fulfilment — closed, accepted Result.
Product intent: Customers receive a durable order reference and downstream teams receive one dependable handoff.
Current state / inputs: The production input Contract is active.
Required state / outputs: The production outputs are active and demonstrated.
Contract and scope: The final living Contract and complete change history are retained with the closed Work Item.
Seams and dependencies: Payments, Checkout, Fulfilment, and Notifications observed the demonstrated boundary behaviour.
Risks and boundaries: No closure blocker remains. Product outcome signals can be reviewed without keeping delivery artificially open.
Evidence: The final Demo presented the customer flow, duplicate handling, optional-email behaviour, event compatibility, reconciliation, and operational telemetry.
Ownership: Product delivery ownership is complete; Checkout Team retains normal operational ownership.
History: PO accepted the Result after Demo. Work Item closed; support-contact and completion-rate signals will inform subsequent decisions.

Working sessions

Prepare first; invite only useful voices.

Discovery and Initial Refinement

State intent, model the outer boundary, shape Candidate Items, identify Seams and risks, and assign follow-up. Combine the events when enough intent already exists; otherwise preserve time between them for research and ideation.

Main Refinement when needed

Restate the prepared Contract, invite relevant challenges, estimate or size, align affected delegates, and stop when the Definition of Ready (DoR) is met. Skip it when the Product Owner and at least one delegate can already record readiness and align any other affected delegates before commitment.

Planning

Verify estimates (or sizing) and current priority, confirm affected-delegate alignment, name at least one owning team, and record commitment. A concrete challenge calls readiness back into question and must be addressed before commitment.

Feedback, Demo, and Team Review

Show prototypes or partial results whenever feedback would reduce uncertainty. These feedback points may adapt the living Contract but do not replace the final Demo. Team Review separately improves the process and delegate arrangement.

Template

Delegate working agreement

Review period:
Delegates:

Delegates will:
- prepare relevant Discovery and Initial Refinement;
- publish reasoning, contracts, seams, and open questions;
- collect and carry team challenges;
- coordinate affected boundaries.

Delegates will not:
- assign work unilaterally;
- override implementation decisions;
- conceal unresolved disagreement;
- treat delegation as permanent authority.

Review date:
Retain, rotation, or replacement process:
Team communication channel:

Continue to pilot and scaling guidance ↓

Getting started

A focused pilot, not a paper transformation.

Choose a boundary

Pick one product area with recurring cross-team ambiguity.

Select delegates

Each team chooses one or two people for a time-boxed, reviewed period.

Adopt the defaults

Start with the MoRE living Contract, Definition of Ready (DoR), Definition of Done (DoD), and challenge path.

Run real work

Use actual Candidate Items and Results rather than workshop examples.

Inspect Evidence

Look for clearer handoffs, earlier challenges, and smaller meetings.

Expand carefully

Add teams only after the pilot reduces coordination load.

Useful starting size: two to four teams around one product goal.

The first cycle

Practise the flow before customising it.

Step	What to establish
Discovery	A product problem, desired outcome, boundaries, and high-level Candidate Items.
Preparation	Research, ideation, questions, and individual refinement before the next meeting.
Initial Refinement	Written reasoning, Contracts, Seams, decomposition, Evidence, and provisional priority. Combine with Discovery when participants agree the intent is already clear.
Main Refinement	Use only when team challenge, estimation, or additional context is needed.
Planning	Verify estimate (or sizing) and priority, confirm affected-delegate alignment, and record owning teams to commit to Ready Work Items.
Execution and closure	Deliver toward DoD, seek feedback when useful, keep the Contract history current, demonstrate the completed Result, and record the product decision.
Team Review	Inspect the process at the team's chosen cadence and review delegate tenure.

Use the templates and worked example above for the first cycle rather than inventing local paperwork.

Keep your delivery method

MoRE works around Scrum or flow.

MoRE concern	Scrum	Kanban / flow
Commitment	Sprint Planning	Pull or replenishment
Team coordination	Daily Scrum	Flow review or team sync
Demo	Sprint Review or a separate Demo	When a Result is ready or in a useful batch
Team Review	Retrospective	Service-delivery review or another chosen cadence
Forecasting	Team's chosen estimate	Flow data, size, or team method

MoRE structures the path from product intent to commitment-quality work. It does not replace team-level delivery mechanics.

Moving from LeSS

Change coordination, not everything at once.

Keep

One product focus where practical
Cross-team transparency
Feature-team autonomy
Inspect-and-adapt behaviour

Change

Prepare early work through delegates
Use explicit Work Item Contracts and Seams
Separate Refinement from Execution
Keep challenges and the Contract change history visible

Travellers and other collaboration patterns remain organisational choices. MoRE requires explicit ownership and boundaries, not a prescribed staffing model.

Pilot health

Look for observable improvement.

Ready Work Items make sense without private meeting context.
Planning verifies priority, estimates (or sizing), and ownership instead of discovering basic scope.
Producing and consuming teams understand each shared Seam.
Challenges happen early and changes that invalidate commitment are realigned.
Delegate tenure is reviewed without creating permanent authority.
Meeting attendance falls without increasing surprises.

Scaling principle

Scale through clearer boundaries, not larger meetings.

A coordination group should serve one coherent product or value stream and remain small enough to model work meaningfully. Work Items move independently; one or more explicit owners choose how to collaborate.

Before adding another permanent participant, ask whether a written Contract or a small, temporary alignment can carry the dependency.

Platforms and multiple products

Treat shared capabilities as Contract providers.

Name producing and consuming teams instead of assigning work to “all teams.”
Include platform delegates when a Candidate Item changes a shared Contract.
Separate internal implementation from consumer-facing behaviour.
Make compatibility, migration, rollout, and observability explicit.
Connect product groups through Contracts rather than permanent joint refinement.

When to split a group

Split when composition is clearer than conversation.

Warning signals

Most items affect only a subset of participants.
Delegates mostly listen or repeat context elsewhere.
One Product Owner cannot clarify intent and review Results promptly.
Teams cannot tell which group owns a decision.

After the split

Name the shared boundary.
Identify producers and consumers.
Publish Contract decisions to both groups.
Use temporary delegates for boundary changes.

Honest constraints

No process fixes missing authority or discipline.

MoRE struggles when product decisions are unavailable, architecture makes every boundary unstable, written records are neglected, or delegates become unchallengeable gatekeepers. Address those conditions before adding another coordination layer.

Inspect the worked Work Item ↑Read the FAQ and glossary →

Turn explicit boundaries into usable work.

Use one loop from intent to Evidence.

Describe observable behaviour, not internal tasks.

Boundary

State and flow

Constraints

Evidence and change

Split when a smaller boundary reduces shared knowledge.

Choose the level that makes the seam understandable.

Modules and services

Ports and layers

Events and pipelines

Manual or research work

Agree what an acceptable outcome means.

Make compatibility and operability part of the seam.

Work Item

One checkout outcome through the full lifecycle.

Prepare first; invite only useful voices.

Discovery and Initial Refinement

Main Refinement when needed

Planning

Feedback, Demo, and Team Review

Delegate working agreement

A focused pilot, not a paper transformation.

Practise the flow before customising it.

MoRE works around Scrum or flow.

Change coordination, not everything at once.

Keep

Change

Look for observable improvement.

Scale through clearer boundaries, not larger meetings.

Treat shared capabilities as Contract providers.

Split when composition is clearer than conversation.

Warning signals

After the split

No process fixes missing authority or discipline.