Three phases produce three states.
Modelling, Readiness, and Execution are phases. Candidate, Ready Work Item, and Result are lifecycle states. Commitment is a recorded event or status between Readiness and Execution, not a fourth state.
Documented boundaries make commitment credible.
MoRE starts from a simple premise: coordination becomes dependable when communication and shared understanding survive the meeting. Important intent, assumptions, boundaries, decisions, and evidence are recorded in the Work Item and its contracts. That gives people a scope they can challenge, plan, and credibly commit to.
Computational thinking
Break a complex outcome into smaller, understandable state transitions. For each transition, make the relevant current state or inputs, required state or outputs, constraints, and observable proof explicit. This supports precise reasoning without requiring every participant to understand every implementation detail.
Black-boxing
Treat each unit as a black box: its contract describes what it must do while its owners retain control over how it is done. A complex system can be understood as a composition of smaller or primitive boxes, and that composition can itself be treated as a box at the next useful level of abstraction.
Seams
Seams are the boundaries where boxes exchange inputs and outputs—and where teams depend on one another. Making Seams explicit exposes handoffs, assumptions, ownership, and integration risks. MoRE concentrates shared coordination at these boundaries while leaving internal execution choices to the owners.
These ideas apply beyond software architecture. They give product leaders, managers, and teams a common way to describe work, preserve decisions, and decide whether a Work Item is understood well enough to enter commitment.
Make every decision and feedback path visible.
flowchart TD
intent["Product intent"] --> model["Modelling — Candidate"]
model --> refine["Readiness — refine as needed"]
refine --> ready{"Meets Definition of Ready?"}
ready -- "No" --> refine
ready -- "Yes — PO + delegate record" --> plan["Planning — verify priority and estimate; name owner(s); commit"]
plan --> execute["Execution — implement, prove, and deliver"]
execute --> change{"Contract change?"}
change -- "Yes" --> assess["Record it; affected teams assess materiality"]
assess -- "Material" --> refine
assess -- "Non-material" --> execute
change -- "No" --> done{"Meets Definition of Done?"}
done -- "No" --> incomplete["Continue Execution — complete missing work"]
incomplete --> execute
done -- "Yes" --> demo["Demo — PO accepts or rejects"]
demo --> close["Record decision and close"]
Prepare before asking teams to commit.
1. Modelling
The Product Owner and delegates turn a problem or opportunity into high-level Candidates. Discovery defines intent and boundaries; Initial Refinement adds context, reasoning, contracts, seams, decomposition, and provisional priority.
Discovery and Initial Refinement may be one meeting when participants agree that enough intent already exists. When separate, the interval gives participants time for rest, research, and ideation.
2. Readiness
The Product Owner and delegates try to bring prepared Candidates to Ready. Main Refinement adds relevant team members when challenge, estimation, or context is needed. It may be skipped when the written Candidate already meets the Definition of Ready.
A later concrete challenge reopens refinement, including one raised during Planning.
3. Execution
After Planning records priority, ownership, and commitment, the owner or owners implement and prove the contract using their chosen workflow. Execution produces a Result that meets DoD; Demo and the product decision then close the Work Item.
Authority follows the decision.
| Participant | Primary responsibility |
|---|---|
| Product Owner | Product intent, value, priority, clarification, and the decision after Demo. |
| Delegate | Early modelling, contracts, seams, published reasoning, and coordination. The role is time-boxed, reviewed, and challengeable. |
| Team | Challenges, estimates, ownership choices, implementation, proof, delivery, and internal workflow. |
| Stakeholder | Specialist input or product feedback when relevant, without mandatory attendance at routine events. |
Ready means the contract can withstand commitment.
A Work Item needs explicit intent, applicable current state and/or inputs, required state and/or outputs, boundaries, constraints, dependencies, acceptance evidence, and visible risks. The Product Owner and a delegate jointly record Readiness.
An escalated challenge is not resolved merely because it was escalated. A named decision owner must resolve or explicitly accept it before the item can be Ready.
Ownership is explicit; collaboration stays fluid.
Planning considers only Ready Work Items, verifies estimates and current priority, records commitment, and names at least one owner. Organisations may allow multiple owners. MoRE does not prescribe travellers, task allocation, or internal team workflow; it requires the contract, seams, and accountability to remain visible.
Record first, then judge materiality together.
Every contract change is recorded and communicated to affected producing and consuming teams. Those teams or delegates jointly assess materiality. The Product Owner joins when intent, scope, value, or priority is affected.
Non-material clarification
Record the decision and continue Execution.
Material change
Return the Work Item to Readiness, update the contract, and realign affected teams before continuing.
DoD ends Execution; Demo closes the Work Item.
DoD establishes that the Result is contract-complete: evidence exists, required delivery work is complete, changes are recorded, and remaining work is separate. The Result is then demonstrated to the Product Owner.
The recorded product decision is a mandatory closure gate. A contract-complete Result may be accepted or closed as product-rejected; changed expectations become a new Work Item rather than silently expanding the original.
Events exist to produce decisions.
| Event | Purpose | Participants |
|---|---|---|
| Discovery | Shape intent and high-level Candidates. | PO, delegates |
| Initial Refinement | Prepare contracts, seams, reasoning, decomposition, and provisional priority. | PO, delegates |
| Main Refinement | When needed, challenge prepared work and estimate it. | Relevant team members and delegates; PO as needed |
| Planning | Verify priority and estimates, name owner(s), and commit. | Teams or delegates; PO for priority |
| Demo | Present the Result and record the product decision. | Owner(s), PO, relevant stakeholders |
| Team Review | Improve the process and review delegate tenure. | Team, at its chosen cadence |
Teams may also use their own syncs and small ad-hoc meetings. MoRE defines purposes, not a universal calendar.
Use MoRE when boundaries need structure.
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 written contracts.
- Delegates cannot be challenged by their teams.