Eighty per cent of the method in four rules of thumb.
MoRE (Modelling, Refinement, Execution) coordinates multi-team product work without all-hands meetings. You can run most of the framework by applying four connected rules:
Write work as a living Contract
Describe each Work Item as an observable state transition: product intent, current state/inputs → required state/outputs, constraints, Seams naming producing and consuming Teams, change boundaries, and agreed Evidence—hiding internal task breakdowns inside the Black Box.
Coordinate early through reviewed Delegates
Each Team elects and periodically reviews time-boxed Delegates to model and refine work with the Product Owner. Delegates are never managers: the Team (or collaborating Teams) is the preferred Work Item Owner, and any Teammate can raise a concrete challenge.
Move each item through 3 phases and 2 gates
Modelling produces a Candidate Item. Refinement produces a Ready Work Item (recorded by the PO and at least one Delegate, with all affected Teams' Delegates aligned before commitment). Planning commits Ready items to an Owning Team. Execution (via Scrum, Kanban, or any internal workflow) produces a Result meeting Definition of Done (DoD), and a final Demo records the PO's product decision.
Protect autonomy with two safety valves
Before commitment, any concrete Team challenge calls readiness back into question. During Execution, record every Contract change and notify affected Teams: amend and continue when within agreed risk, cost, or time boundaries (involving the PO only when intent, scope, value, or priority is affected), or return to Refinement when commitment is invalidated.
See one checkout Work Item evolve through all phases → · Jump to the normative rules →
Scale clarity, not the meeting.
MoRE addresses coordination problems caused by private context, unclear boundaries, oversized meetings, and commitment made before teams can understand the work.
Vague handoffs
Intent, assumptions, ownership, and Evidence are too often distributed across conversations that producers and consumers cannot reliably inspect.
Expensive participation
Organisations compensate for missing durable context by inviting more people to more meetings, whether or not their contribution is needed.
False certainty
Teams are asked to commit before boundaries are understood, while later learning is treated as a failure rather than an expected part of product development.
Three challenges guide the framework.
Focused participation
How can teams maintain alignment while reducing unnecessary meetings and participation?
Boundaries and autonomy
How can cross-team boundaries and dependencies evolve without surprises or excessive control, while teams retain implementation autonomy and shared accountability?
Durable understanding
How can shared understanding survive beyond the people and meetings that produced it?
Structure supports learning; it does not defend an obsolete plan.
MoRE adopts the Agile Manifesto's preference for individuals and interactions, working results, customer collaboration, and responding to change.
People and interaction
Prepared context and focused participation support useful conversation instead of replacing it with process or tools.
Working results
Contracts and documentation are valuable when they help teams produce, evaluate, and learn from observable Results.
Customer collaboration
The living Contract is a shared understanding, not a fixed-scope negotiation that prevents Product Owner or stakeholder feedback.
Responding to change
Requirements and Contracts evolve visibly as teams learn; only changes that invalidate commitment require renewed Refinement.
The Work Item is MoRE's unit of shared intent.
A Work Item describes a coherent, independently verifiable state transition that advances a product outcome. It carries product intent, a living Contract, Seams, ownership, decisions, and Evidence; it is not merely an implementation task.
The term is deliberately generic. A Work Item is a conceptual unit, not a prescribed ticket type, tool, or team workflow. Teams may track it in Jira or another system and organise internal tasks however they need, provided the MoRE lifecycle, Contract, and shared boundaries remain visible.
Authority follows the decision.
MoRE distinguishes product authority, team authority, specialist input, coordination, and delivery ownership so that no participant gains authority merely by attending more meetings.
| Participant | Primary responsibility |
|---|---|
| Product Owner | Product intent, value, priority, ongoing feedback, readiness participation, and the product decision after Demo. |
| Stakeholder | Customer, business, operational, or specialist input when relevant, without mandatory attendance at routine events. |
| Team | Challenges, estimates, Delegate selection, ownership choices, implementation, Evidence, delivery, and internal workflow. |
| Teammate | Direct contribution where useful and the ability to serve as, support, or challenge a Delegate or Owner. |
| Delegate | Prepared modelling, Contracts, Seams, published reasoning, challenges, and coordination. |
| Owner | The Team or collaborating Teams (or a named driver on their behalf) responsible for driving a committed Work Item through implementation, Evidence, and delivery. |
Delegates connect teams without becoming another management layer.
A Delegate is a temporary role granted by a Team. Delegates prepare context, make shared boundaries explicit, carry challenges, and coordinate with affected teams without taking authority away from the Team.
The map shows collaboration, not hierarchy. Product Owners and Stakeholders may work directly with Teams, and Delegates do not stand between Teammates and the people whose input they need.
- Each Team selects and reviews its own Delegate or Delegates.
- During Modelling and Refinement, Delegates share the evolving Work Item with their Teams, gather feedback, concerns, and challenges, and record relevant outcomes.
- Any Teammate may challenge a Delegate's decision or contribute directly when their context is needed.
- A Delegate and Work Item Owner may be the same person, but their responsibilities remain distinct.
- Delegation never grants permanent authority, product authority, unilateral assignment authority, or control over another Team's implementation.
Describe meaningful change before describing tasks.
Computational thinking decomposes a complex outcome into understandable state transitions without requiring every participant to know every implementation detail.
Current state and inputs
Identify what exists now, what enters the boundary, and which conditions trigger the transition.
Required state and outputs
Describe what must become observably different and what other people or systems can rely on.
Constraints and behaviour
Make relevant invariants, errors, side effects, compatibility expectations, and quality boundaries explicit.
Evidence
Agree which observations will establish that the intended transition or product effect occurred.
Make shared obligations explicit without exposing unnecessary internals.
These concepts describe one boundary from complementary perspectives: a Black Box hides how behaviour is produced, its Contract records what others can rely on, and its Seams identify where it interacts with people, Teams, or other Black Boxes.
Expose
Producers, consumers, inputs, outputs, assumptions, dependencies, handoffs, compatibility risks, and required Evidence.
Protect
The owners' implementation decisions, internal workflow, and details that consumers do not need in order to rely on the boundary.
Coordination concentrates at Seams. When a shared Contract changes, affected parties keep the change visible and agree how the boundary evolves while owners retain control over how they deliver.
Requirements are learned, not merely collected.
Conversation, implementation, feedback, and use continually refine understanding. A Contract records the best current shared understanding; it does not promise that discovery has ended.
- Readiness means the next responsible step can begin with uncertainty visible and bounded.
- Important intent, assumptions, challenges, decisions, Evidence, and changes survive the meeting in the Work Item.
- Relevant parties may amend a coherent Work Item and continue when the change remains within agreed boundaries.
- A Ready Work Item cannot depend on private context held only by the people who modelled it.
As guiding practice, ask what need a stated requirement serves, whether it expresses a changeable policy or proposed solution, and what feedback could improve it.
Three phases produce three states.
Modelling, Refinement, and Execution are phases. Candidate Item, Ready Work Item, and Result are lifecycle states. Commitment (between Refinement and Execution) and Closure (accepted or product-rejected after Demo) are recorded decisions or statuses, not additional lifecycle states.
flowchart LR
model["<b>Modelling</b><br/>Set product intent<br/>Discover requirements<br/>Create an initial Candidate Item"]
refine["<b>Refinement</b><br/>Challenge and strengthen the Contract<br/>Produce a Ready Work Item"]
execute["<b>Execution</b><br/>Deliver and learn<br/>Produce a Result with Evidence"]
model --> refine
refine -- "Planning and commitment" --> execute
flowchart LR
discovery["<b>Discovery</b><br/>Set product intent<br/>Discover requirements<br/>Define the outcome and outer boundary<br/>Shape high-level Candidate Items"]
initial["<b>Initial Refinement</b><br/>Add context and reasoning<br/>Draft the Contract, Seams, and Evidence<br/>Decompose and identify risks<br/>Set provisional priority"]
candidate(["Candidate Item"])
discovery --> initial
initial -- "Delegates gather more Team feedback" --> initial
initial --> candidate
flowchart LR
candidate(["Candidate Item"])
main["<b>Main Refinement</b><br/>Challenge the prepared Candidate Item<br/>Clarify the Contract, Seams, and Evidence<br/>Estimate/size and expose dependencies<br/>Address concrete challenges"]
work(["Ready Work Item"])
planning["<b>Planning</b><br/>Verify priority and estimate/sizing<br/>Confirm affected-Delegate alignment<br/>Address concrete challenges<br/>Name the Owner(s) and record commitment"]
commitment["Commitment recorded"]
candidate --> main
candidate -. "Already meets Definition of Ready" .-> work
main -- "Delegates gather more Team feedback" --> main
main -- "PO and Delegate(s) record readiness" --> work
work --> planning
planning -- "Readiness challenged" --> main
planning --> commitment
flowchart LR
committed["Commitment recorded"] --> deliver["Deliver, learn,<br/>and seek feedback"]
deliver --> change{"Contract change?"}
change -- "Amend" --> deliver
change -- "Realign" --> refine["Return to Refinement"]
change -- "No" --> done{"Definition of Done met?"}
done -- "No" --> deliver
done -- "Yes" --> result["Result"]
result --> demo{"Final Demo and<br/>product decision"}
demo -- "Accept or reject" --> close["Record decision and close"]
demo -. "Amend coherent outcome" .-> deliver
Turn product intent into a prepared, bounded proposal.
Modelling begins by defining the problem or opportunity, desired outcome, and outer boundary. Participants then add written context, reasoning, a draft Contract, Seams, decomposition, risks, proposed Evidence, and provisional priority.
Discovery and Initial Refinement may happen together when enough intent already exists or be separated to create time for research, rest, ideation, and individual preparation. Section 17 defines their purpose and typical participation.
A Candidate Item should be decomposed when it cannot be described, verified, or owned through one coherent Contract; the resulting items should represent meaningful state transitions rather than internal task lists.
Examples: early Candidate Item · prepared Candidate Item
Ready means the next responsible step can begin.
Main Refinement strengthens and challenges the prepared Contract without requiring every detail to be known. Relevant Teammates join only when challenge, estimation, or additional context is useful; the event can be skipped when the written Candidate Item already meets the Definition of Ready (DoR). Section 17 defines its purpose and typical participation.
A Ready Work Item makes applicable intent, state, inputs, outputs, scope, constraints, dependencies, Seams, Evidence, risks, assumptions, unknowns, and change boundaries visible. The Product Owner and at least one Delegate record the readiness decision; when a shared Contract affects multiple Teams, they align the Delegates of the other affected Teams before commitment.
Examples: after team challenge · after readiness
Ownership is explicit; collaboration stays fluid.
Planning considers only Ready Work Items. It verifies current priority and estimates (or sizing), confirms that Delegates of all affected Teams agree on shared Contracts, addresses concrete challenges, names at least one Owner, and records commitment to the intended outcome within current constraints.
Commitment does not freeze scope or prescribe task allocation. Owners choose how to organise implementation while preserving the Contract, Seams, Evidence, and accountability; organisations may permit multiple Owners.
Example: after Planning →
Owners deliver and learn through their chosen workflow.
Product discovery continues during implementation. Owners seek Product Owner or stakeholder feedback whenever a prototype or partial Result would reduce uncertainty, while keeping the living Contract aligned with what participants learn.
Amend and continue
Record the change and continue when relevant parties agree that the Work Item remains coherent, the change fits agreed boundaries, and ownership and Evidence remain suitable.
Return to Refinement
Realign the Work Item when a change exceeds an agreed risk, cost, or time boundary, or makes existing ownership or Evidence unsuitable.
Examples: after early feedback · after a Contract change
Agree what an acceptable outcome means.
Evidence is the observations participants agree are acceptable for a particular Work Item. Depending on the claim, it may demonstrate fulfilment of the Contract, an intended product effect, or both.
| Claim | Possible Evidence |
|---|---|
| Behaviour is correct | Contract or acceptance tests and examples. |
| A migration reached its required state | Pre/post checks, reconciliation, and rollback Evidence. |
| Reliability or performance holds | Metrics, thresholds, and load or failure tests. |
| A workflow creates value | Demo, usability Evidence, or an agreed product measure. |
Definition of Done completes Execution when agreed Evidence exists at the specified time, implementation and delivery are complete, the change history is current, and remaining work is visible.
Example: Result after DoD →
The final Demo is the North Star.
Earlier feedback is encouraged, but it does not replace presenting the completed Result to the Product Owner. Acceptance or rejection is recorded before the Work Item closes.
If expectations changed, relevant parties may amend and continue the same Work Item while its intended outcome remains coherent. They may instead close a compliant Result as contract-complete but product-rejected and model a distinct outcome separately.
Example: after the final Demo →
Events exist to produce decisions, not satisfy a calendar.
Events are decision points, not the only times collaboration occurs. Between them, Delegates keep Teams connected to the evolving Work Item and bring their feedback, concerns, and challenges into the next decision.
| Event | Purpose | Typical participants |
|---|---|---|
| Discovery | Shape intent and high-level Candidate Items. | Product Owner and Delegates. |
| Initial Refinement | Prepare Contracts, Seams, reasoning, decomposition, Evidence, and provisional priority. | Product Owner and Delegates. |
| Main Refinement | When needed, challenge prepared work and estimate or size it. | Relevant Teammates and Delegates; Product Owner as needed. |
| Planning | Verify priority and estimate/sizing, confirm affected-Delegate alignment, name Owners, and record commitment. | Teams (or Delegates conveying Team agreement); Product Owner for priority. |
| Feedback | Review partial Results when useful and adapt the Contract. | Owners, Product Owner, and relevant Stakeholders. |
| Demo | Present the completed Result and record the product decision. | Owners, Product Owner, and relevant Stakeholders. |
| Team Review | Improve the process and review the Delegate arrangement. | The Team at its chosen cadence. |
Teams may also use their own syncs and small ad-hoc meetings. Invite only the people needed to resolve the concern, and preserve important outcomes in the Work Item.
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. Shared capabilities act as Contract providers, and product groups connect through explicit producer/consumer Seams rather than permanent joint Refinement.
Good fit
- One product spans several Teams.
- Dependencies and shared Seams need explicit ownership.
- Early coordination meetings have become too large.
- Teams use different delivery cadences.
Probably unnecessary
- One small Team already shares context cheaply.
- Work has no meaningful cross-team boundaries.
- The organisation will not maintain living Contracts.
- Delegates cannot be challenged by their Teams.
Before adding a permanent participant or coordination layer, ask whether a written Contract or small temporary alignment can carry the dependency.
The rules that define MoRE.
The framework explains intent and provides guidance. These rules identify the minimum behaviours that distinguish MoRE while leaving teams free to choose their tools, workflow, and context-specific practices.
A team is not using MoRE if it routinely ignores MUST rules. SHOULD rules can be changed when the alternative remains explicit and supports the same principle.
Work Item rules
- Every Work Item MUST move through the Modelling, Refinement, and Execution phases.
- Phases MUST apply per Work Item; the organisation need not enter them together.
- Modelling MUST produce a Candidate Item, the first lifecycle state of a Work Item, before detailed team refinement.
- A Candidate Item that cannot be described, verified, or owned through one coherent Contract SHOULD be decomposed into smaller Black Boxes with explicit Seams.
- Each resulting Candidate Item SHOULD be a coherent, independently verifiable state transition—not merely an implementation task—and fit its prospective owners' normal planning horizon.
- Refinement MUST produce a Ready Work Item and a recorded readiness decision before commitment.
- At least one owner—preferably a Team or collaborating Teams—MUST be recorded before commitment; organisations MAY allow multiple owners.
- Owners MAY organise collaboration and divide implementation work as they choose while preserving the contract and explicit Seams.
- Commitment MUST be treated as a recorded event or status, not a fourth lifecycle state.
- Execution MUST produce a Result that is complete against the current Contract and supported by the agreed Evidence.
Contract rules
- Every Work Item MUST define its product intent, current state and/or inputs, and required state and/or outputs, as applicable.
- Relevant constraints, errors, side effects, and invariants MUST be explicit.
- Acceptable Evidence and when it can reasonably be observed MUST be agreed before commitment. Depending on the Work Item, it MAY demonstrate fulfilment of the Contract, an intended product effect, or both.
- A Contract MUST remain a living record with a visible change history.
- A Contract SHOULD hide implementation details that consumers do not need.
- When Black Boxes are composed, every shared input/output Seam SHOULD remain explicit and independently evaluable.
- Recurring patterns MAY inform shared templates or capabilities, but MUST NOT replace the context-specific Contract.
- Teams MAY use their own Contract template.
Refinement rules
- Candidate Items MAY be provisionally ordered at any time, but commitment planning MUST consider only Ready Work Items.
- The Product Owner and at least one delegate MUST jointly record the readiness decision, and MUST align delegates of any other affected teams before commitment.
- Main Refinement MAY be skipped when the Product Owner and at least one delegate determine that the Candidate Item meets the Definition of Ready without it.
- A later concrete team challenge MUST call readiness back into question, including a challenge raised during Planning.
- Relevant participants MUST address a concrete challenge before commitment and MAY choose how they reach agreement or handle unresolved disagreement.
- Dependencies and affected teams MUST be visible.
- A Ready Work Item MUST NOT depend on unrecorded context held only by the people who modelled it.
- A Ready Work Item MAY retain bounded uncertainty when its assumptions, unknowns, and agreed risk, cost, or time boundaries are visible.
- Any team with the required domain capability, technical access, and capacity SHOULD be able to assess the Work Item from its written Contract.
- Teams MAY add context-specific Definition of Ready criteria.
Execution rules
- The owner or owners MUST control their implementation approach and internal workflow.
- Every Contract change discovered during Execution MUST be added to its history and communicated to affected producing and consuming teams.
- Relevant parties MUST agree whether the Work Item remains coherent; the Product Owner MUST join when product intent, scope, value, or priority is affected.
- Relevant parties MAY amend the Contract and continue Execution when the change remains within agreed boundaries and the existing ownership and Evidence remain suitable.
- A change MUST return the Work Item to Refinement when it exceeds an agreed risk, cost, or time boundary, or makes the existing ownership or Evidence unsuitable.
- Owners SHOULD seek Product Owner or stakeholder feedback on prototypes or partial results whenever it would reduce uncertainty.
- The Result MUST satisfy the agreed Definition of Done before the final Demo.
- Required implementation and delivery work MUST both be complete.
- Remaining work MUST remain visible and MAY stay in an amended Work Item when its intended outcome remains coherent and relevant parties agree.
Delegate rules
- Each team MUST select its own delegate or delegates.
- A team MUST be able to challenge its delegate's decision.
- Delegation MUST NOT grant permanent authority over the team.
- Delegate tenure SHOULD be time-boxed and reviewed.
- At each review, a team MAY retain, rotate, or replace its delegate; rotation is encouraged for context sharing but is not required.
Cross-team rules
- Producing and consuming teams MUST be identified for a shared Contract.
- While the Product Owner and at least one delegate may record readiness, delegates of every affected team MUST agree before commitment.
- Affected teams MAY decide how agreement is reached and how unresolved disagreement is handled; MoRE does not prescribe a universal decision mechanism.
- The Contract, its history, and decisions MUST remain visible to affected teams.
- The Product Owner need not be informed of every technical change, but MUST be involved when a shared-Contract change affects product intent, scope, value, or priority.
- Ad-hoc coordination SHOULD involve only people needed to resolve the boundary.
Product-decision rules
- Every Result that satisfies the Definition of Done MUST be demonstrated to the Product Owner at the final Demo.
- The Product Owner's acceptance or rejection MUST be recorded before the Work Item closes.
- When expectations change, relevant parties MAY amend and continue the Work Item if its intended outcome remains coherent.
- Relevant parties MAY instead close a compliant Result as contract-complete but product-rejected and create a separate Work Item.
- A distinct outcome MUST enter Modelling as a separate Work Item.
Team Review rules
- Team Review SHOULD remain distinct from Demo and focus on improving the team's process and delegate arrangement.
- Teams MAY run Team Review at their chosen cadence and map it to an existing retrospective or service-delivery review.
Urgent-work rules
- Urgent work MUST use the same phase gates.
- The contract MAY be the minimum adequate record for safe action.
- Participants SHOULD convene immediately rather than bypass Refinement.
Follow one outcome as its shared understanding grows.
The checkout example shows complete snapshots after every significant lifecycle step and labels values that changed since the previous snapshot.
Begin with one real boundary and inspect what improves.
Pilot MoRE with two to four Teams around a product area that already suffers from cross-Team ambiguity. Use real Candidate Items and Results, adopt the default Contracts and challenge path, and expand only when the pilot reduces coordination load.
- Check whether Ready Work Items make sense without private meeting context.
- Check whether Planning verifies work instead of discovering basic scope.
- Check whether changes and shared Seams create fewer surprises.
- Review Delegate tenure and the Team's process at a cadence the Team chooses.
Team Review remains distinct from Demo: Demo evaluates the Result and records the product decision, while Team Review improves the process and Delegate arrangement.