# MoRE: Modelling, Refinement, Execution > A consolidated reference to the MoRE framework, its normative rules, adoption guidance, practical tools, and shared vocabulary. MoRE is a multi-team product-development framework built around explicit, living Work Item contracts, prepared refinement, visible readiness, time-boxed delegates, focused participation, and team-controlled execution. It is a deliberate alternative to coordination models that depend on large meetings or unrecorded shared context. The central principle is simple: **scale clarity, not the meeting**. MoRE aims to answer three guiding challenges: 1. **How can teams maintain alignment while reducing unnecessary meetings and participation?** 2. **How can cross-team boundaries and dependencies evolve without surprises or excessive control, while teams retain implementation autonomy and shared accountability?** 3. **How can shared understanding survive beyond the people and meetings that produced it?** This document combines the knowledge published on [workwithmore.org](https://workwithmore.org/). The [normative rules](#normative-rules) distinguish requirements from guidance: - **MUST** means required. - **SHOULD** means the recommended default. An alternative is acceptable when it remains explicit and supports the same principle. - **MAY** means a contextual choice. A team is not using MoRE if it routinely ignores MUST rules. Explanations, templates, and examples may be adapted; the normative rules define the framework. --- ## 0. MoRE at a glance (the 80/20 core) Eighty per cent of the MoRE method reduces to four connected rules of thumb: 1. **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. 2. **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. 3. **Move each item through 3 phases and 2 gates:** **Modelling** produces a **Candidate Item**. **Refinement** produces a **Ready Work Item** (recorded by the Product Owner 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 Product Owner's product decision. 4. **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 Product Owner only when intent, scope, value, or priority is affected), or return to Refinement when commitment is invalidated. --- ## 1. Why MoRE exists Shared understanding does not scale by itself. Coordination becomes unreliable when: - scope lives mainly in conversations; - decisions depend on meeting attendance; - implementation starts before teams agree on their boundaries; - handoffs depend on assumptions that are not visible to producers and consumers; - every participant is invited to every early discussion; - delegates acquire permanent, unchallengeable authority. MoRE addresses these problems in three ways: 1. **Replace vague handoffs with contracts.** State the transition, constraints, ownership, and evidence before commitment. 2. **Prepare before involving more people.** Product Owners and delegates shape work so broader Refinement starts from something written and challengeable. 3. **Coordinate at boundaries.** Keep decisions durable and let owners choose their internal workflow. Important product intent, assumptions, boundaries, decisions, and evidence become a shared record rather than context that disappears after a meeting. Explicit boundaries make the effects of new learning visible, allowing realistic planning and credible commitment without pretending that requirements will remain unchanged. MoRE follows the Agile Manifesto's preference for customer collaboration and responding to change. Structure exists to make learning and change safe and visible, not to defend an obsolete plan. ### Characteristic behaviours - **Prepared refinement:** start with written context. - **Explicit readiness:** commit with bounded uncertainty, not guesses. - **Living contracts:** preserve shared understanding and change history without freezing scope. - **Reviewed delegates:** use representation without permanent authority. - **Fluid execution:** owners choose how to collaborate and deliver. --- ## 2. Conceptual foundations ### 2.1 Computational thinking Decompose a complex outcome into understandable state transitions. For each transition, make the following explicit when applicable: - current state and/or inputs; - required state and/or outputs; - constraints and invariants; - errors and side effects; - acceptable Evidence. This permits precise reasoning without requiring every participant to understand every implementation detail. ### 2.2 Seams, Contracts, and Black Boxes These three concepts describe one boundary from complementary perspectives: - A **Black Box** is a unit viewed through its observable behaviour, hiding implementation details that consumers do not need. - A **Contract** records what others can rely on: applicable inputs, outputs, constraints, Evidence, decisions, and change history. - A **Seam** is where a Black Box interacts with people, teams, or other Black Boxes and where the Contract must be understood. Explicit Seams expose: - producers and consumers; - inputs, outputs, and shared Contracts; - assumptions and dependencies; - ownership and handoffs; - compatibility and integration risks; - Evidence required at the boundary. A Seam and a Contract are not interchangeable. A **Seam** is the actual boundary where interaction and dependency occur; a **Contract** is the recorded agreement describing what participants can rely on at that boundary. One Work Item Contract may cover several Seams as well as scope, Evidence, and decisions that are not themselves Seams. A Seam can exist without a clear Contract, but that ambiguity is precisely the risk MoRE asks teams to remove. MoRE concentrates shared coordination at Seams while leaving the internals of each Black Box under its owners' control. Important reasoning, challenges, decisions, Contract changes, and Evidence are recorded in or alongside the Work Item so understanding survives the meeting. A Ready Work Item must not rely on private context held only by those who modelled it. ### 2.3 Agile Manifesto MoRE adopts the Agile Manifesto's preference for individuals and interactions, working results, customer collaboration, and responding to change. Processes, tools, documentation, Contracts, and plans remain useful, but they support collaboration and learning rather than becoming goals in themselves. MoRE's structure exists to make autonomy, feedback, and change safe and visible—not to defend an obsolete plan. ### 2.4 Adaptive Requirements Requirements are learned and refined through conversation, implementation, feedback, and use. A Contract records the best current shared understanding; it is not a promise that discovery has ended. Readiness means that the next responsible step can begin with bounded uncertainty. Discovery continues during Execution, and teams keep the Contract and its history aligned with what they learn. --- ## 3. Shared vocabulary ### Work Item A coherent, independently verifiable state transition that moves through Modelling, Refinement, and Execution. It is not merely an implementation task. The term is deliberately generic: it defines a conceptual unit rather than a prescribed ticket type, tool, or team workflow. Teams may track it in Jira or another system and organise its internal tasks as they choose, provided the MoRE lifecycle, Contract, and shared boundaries remain visible. ### Candidate Item The first Work Item lifecycle state: modelled intent that is not yet ready for commitment. ### Ready Work Item A Work Item whose Contract is sufficient for informed commitment, with bounded uncertainty made visible, and for which a readiness decision has been recorded. ### Result The outcome produced by Execution, completed against the current Contract, and ready for the final Demo. ### Modelling The phase that turns product intent into a prepared, bounded Candidate Item. ### Refinement The phase that challenges and strengthens a Candidate Item until it supports informed commitment. ### Execution The phase in which Owners deliver, learn, maintain the Contract, and produce a Result with Evidence. ### Product Owner The participant responsible for product intent, value, priority, ongoing feedback, readiness participation, and the product decision after Demo. ### Stakeholder A person who provides customer, business, operational, or specialist context when relevant, without mandatory attendance at routine events. ### Team The group responsible for challenges, estimates, Delegate selection, ownership choices, implementation, Evidence, delivery, and internal workflow. ### Teammate A Team member who contributes directly where useful and may serve as, support, or challenge a Delegate or Owner. ### Owner Preferably a Team or collaborating Teams (or a named person acting as driver when required) responsible for driving a committed Work Item through implementation, Evidence, and delivery. ### Producer A Team, person, or Black Box that supplies an input or behaviour through a Seam. ### Consumer A Team, person, or Black Box that relies on an output or behaviour exposed through a Seam. ### Contract The living, versioned record of a Work Item's current shared understanding: applicable current state and inputs, required state and outputs, scope, constraints, errors, side effects, invariants, dependencies, evidence, and change history. It guides collaboration without making scope immutable. ### Seam The boundary where a Black Box interacts with people, teams, or other Black Boxes and where its Contract is exposed. ### Black Box A unit viewed through its observable behaviour and Contract while implementation details remain under its owners' control. ### Delegate A temporary role granted by a Team to a selected representative, commonly a Teammate. A Delegate participates in early modelling, Contract design, challenges, and coordination at shared Seams. It is not a separate management layer and cannot override the Team. ### Challenge A concrete concern that calls the Contract, readiness, or continued Execution into question and must be made visible to the relevant participants. ### Planning The event that verifies priority and estimates (or sizing), confirms affected-Delegate alignment, addresses challenges, names at least one Owner, and records commitment. ### Commitment A recorded event or status after Refinement. It is a commitment to pursue the intended outcome within the current constraints, while keeping learning and Contract changes visible. Commitment is not a fourth lifecycle state. ### Demo The final presentation of a completed Result to the Product Owner before the product decision and closure. ### Product decision The Product Owner's recorded acceptance or rejection after Demo and before closure. ### Team Review A Team's chosen event for improving its process and reviewing its Delegate arrangement. ### Decomposition Breaking complexity into coherent, independently verifiable transitions. ### Composition Connecting Black Boxes through explicit Seams to explain a larger system. ### Definition of Ready (DoR) The conditions that establish that a Work Item's Contract is strong enough for informed commitment (recorded by the Product Owner and at least one Delegate, with all affected Teams' Delegates aligned before commitment) and that remaining uncertainty is visible and bounded. ### Definition of Done (DoD) The conditions that establish that a Result is complete against the current Contract and ready for Demo. DoD completes Execution; the recorded product decision closes the Work Item. ### Change boundary An agreed risk, cost, or time limit used to decide whether a Contract change may continue in Execution or must return to Refinement. ### Evidence Agreed observations used to judge an acceptable outcome for a Work Item. Depending on the Work Item, Evidence may demonstrate fulfilment of the Contract, an intended product effect, or both. The relevant teams agree what Evidence is acceptable and when it can reasonably be observed. --- ## 4. Work Item lifecycle A Work Item is MoRE's unit of shared intent: a coherent, independently verifiable state transition that advances a product outcome. It is not merely an implementation task. It carries the product intent, living Contract, Seams, ownership, decisions, and Evidence needed to understand and evaluate the work. Work Items are a pillar of MoRE because they make coordination durable and give change a visible home. Each Work Item can move independently, while teams retain control over implementation and collaborate through explicit boundaries rather than relying on meeting attendance or private context. MoRE has three phases and three lifecycle states: | Phase | Resulting state | Purpose | |---|---|---| | Modelling | Candidate Item | Turn product intent into a prepared, bounded proposal. | | Refinement | Ready Work Item | Strengthen and challenge the Contract until informed commitment is possible. | | Execution | Result | Deliver, learn, and produce the agreed Evidence against the current Contract. | The phases apply **per Work Item**. An organisation does not enter a phase as a whole, and different Work Items may be in different phases at the same time. Communication continues between events. During Modelling and Refinement, Delegates regularly share the evolving Work Item with their Teams and gather feedback, concerns, and challenges. They record relevant outcomes in the Work Item so later decisions do not depend on private conversations. Commitment (between Refinement and Execution) and Closure (accepted or product-rejected after Demo) are recorded decisions or statuses, not additional phases or states. ### 4.1 End-to-end flow 1. Product intent enters **Modelling**. 2. Modelling produces a **Candidate Item**. 3. The Candidate Item enters **Refinement** and is refined as needed. 4. If it does not meet DoR, Refinement continues. 5. If it meets DoR, the Product Owner and at least one delegate record readiness (and align delegates of any other affected teams before commitment). 6. **Planning** verifies current priority and estimate (or sizing), confirms affected-delegate alignment, names at least one owner, and records commitment. 7. Owners perform **Execution** using their chosen internal workflow, seeking Product Owner or stakeholder feedback whenever it is useful. 8. New learning and Contract changes are recorded in the change history and shared with affected producing and consuming teams (involving the Product Owner when product intent, scope, value, or priority is affected). 9. Relevant parties may agree to amend the living Contract and continue Execution. A change returns to Refinement when it exceeds an agreed risk, cost, or time boundary, or makes the existing ownership or Evidence unsuitable. 10. If DoD is not met, Execution continues. 11. When DoD is met, the Result is presented at the final **Demo**. 12. The Product Owner records acceptance or rejection. The Work Item then closes, is amended, or returns to an earlier phase as agreed. ### 4.2 Modelling The Product Owner and delegates turn a problem or opportunity into high-level Candidate Items. **Discovery** defines product intent, desired outcome, and the outer boundary. **Initial Refinement** adds context, reasoning, Contracts, Seams, decomposition, risks, Evidence, and provisional priority. Discovery and Initial Refinement may be combined when participants agree that enough intent already exists. When they are separate, the interval creates time for rest, research, and ideation. A Candidate Item should be decomposed when it cannot be described, verified, or owned through one coherent Contract. Each resulting Candidate Item should: - represent a meaningful state transition; - have a coherent contract; - be independently verifiable; - fit its prospective owners' normal planning horizon; - avoid exposing internal implementation tasks unnecessarily. ### 4.3 Refinement Refinement makes the Contract strong enough for informed commitment without requiring every detail to be known. The Product Owner and delegates begin from the prepared Candidate Item. Relevant team members join Main Refinement only when challenge, estimation, or additional context is useful. Main Refinement may be skipped when the written Candidate Item already meets DoR and the Product Owner and at least one delegate can record the readiness decision (aligning delegates of any other affected teams before commitment). A later concrete team challenge calls readiness into question, including a challenge raised during Planning. Relevant participants address it before commitment and choose how to reach agreement; MoRE does not prescribe a universal resolution or escalation mechanism. ### 4.4 Definition of Ready A Ready Work Item includes, as applicable: - explicit product intent and value; - current state and/or inputs; - required state and/or outputs; - boundaries and current scope; - constraints, errors, side effects, and invariants; - dependencies and affected teams; - producing and consuming teams at shared Seams; - agreed Evidence; - visible and bounded risks, assumptions, and unknowns; - agreed risk, cost, or time boundaries for change; - a recorded readiness decision by the Product Owner and at least one delegate (with delegates of all affected teams aligned before commitment). Any team with the required domain capability, technical access, and capacity should be able to assess the Work Item from its written contract. ### 4.5 Planning and commitment Planning considers only Ready Work Items. It: - verifies estimates (or sizing); - verifies current priority; - confirms that delegates of all affected teams agree on shared Contracts; - addresses concrete challenges; - names at least one owner (preferably a Team or collaborating Teams); - records commitment to the intended outcome and current constraints. An organisation may allow multiple owners. MoRE does not prescribe travellers, task assignment, or an internal team workflow. Owners choose how to collaborate while keeping Contracts, Seams, and accountability visible. An Owner may be a named person when the context or delivery tool requires one, but the preferred default is for the whole Team—or collaborating Teams—to own the Work Item. A named person may act as driver or contact without making delivery depend on individual capacity or transferring accountability away from the Team. ### 4.6 Execution Owners pursue the intended outcome and produce the agreed Evidence using their chosen workflow. Their implementation approach remains under their control. Discovery continues through implementation and feedback, and the living Contract is updated when shared understanding changes. Execution produces a Result that meets DoD. Required implementation **and delivery** work must be complete. Remaining work may not be hidden in a completed Work Item. Prototypes or other partial results should be shown to the Product Owner or relevant stakeholders whenever feedback would reduce uncertainty; the final Demo remains the North Star. ### 4.7 Contract changes during Execution A Contract is expected to evolve as participants learn. Every change is recorded in its history and communicated to affected producing and consuming teams. Relevant parties agree whether the Work Item remains coherent and can continue. The Product Owner joins when product intent, scope, value, or priority is affected. - **Within agreed boundaries:** amend the Contract and continue Execution when relevant parties agree and the existing ownership and Evidence remain suitable. - **Commitment invalidated:** return the Work Item to Refinement when a change exceeds an agreed risk, cost, or time boundary, or makes the existing ownership or Evidence unsuitable. A changed Contract may remain the same Work Item when its intended outcome remains coherent and relevant parties agree. A distinct outcome should be represented by a separate Work Item. ### 4.8 Done, Demo, and closure DoD establishes that the Result is complete against the current Contract: - agreed Evidence exists or has been observed at the time specified in the Contract; - implementation and delivery work are complete; - the Contract change history is current; - remaining work is visible. The Result is then demonstrated to the Product Owner at the final Demo. The recorded product decision is a mandatory closure gate. If the Product Owner rejects a Result because expectations changed, relevant parties may amend and continue the Work Item when its intended outcome remains coherent. They may instead close it as **contract-complete but product-rejected** and create a separate Work Item. A distinct outcome is always modelled separately. --- ## 5. Roles and decision authority A Delegate connects product direction and stakeholder context with Team knowledge without becoming another management layer. The Product Owner and Stakeholders may still work directly with Teams. Delegates focus early participation, publish reasoning, carry challenges, and coordinate shared Seams; they do not stand between Teammates and the people whose input they need. Delegation is a contextual role rather than a separate kind of person. A Teammate may be both Delegate and Work Item owner, but each responsibility retains its own boundaries. Authority follows the decision. | Participant | How they relate to Delegates | Authority that remains with them | |---|---|---| | Product Owner | Works with Delegates during Discovery, Initial Refinement, readiness, and product clarification. | Product intent, value, priority, and the product decision after Demo. | | Stakeholder | Provides customer, business, operational, or specialist context when relevant. A Delegate helps focus participation but does not replace direct conversation. | Domain expertise and feedback; routine attendance is not required. | | Team | Selects, reviews, challenges, retains, rotates, or replaces its Delegate or Delegates. | Estimates, ownership choices, implementation, Evidence, delivery, and internal workflow. | | Teammate | May serve as a Delegate for a reviewed period, contribute directly when useful, and raise a challenge through or alongside the Delegate. | The ability to challenge decisions and participate where their context is needed. | | Owner or owners | Drive a committed Work Item through Execution. An Owner and Delegate may be the same person, but the responsibilities remain distinct. | Day-to-day delivery decisions within the Contract; a Delegate cannot assign ownership unilaterally. | | Other Delegates | Coordinate shared Seams and seek agreement across affected Teams. | Each represented Team retains its authority and chooses how disagreement is handled. | ### Delegate boundaries Each Team selects its own Delegate or Delegates. The Team may challenge a Delegate's decision. Delegation never grants permanent authority over the Team, product authority, unilateral assignment authority, or authority to dictate implementation. A Delegate helps focus participation but does not replace direct conversation with the Product Owner or relevant Stakeholders. During Modelling and Refinement, Delegates share the evolving Work Item with their Teams, gather feedback, concerns, and challenges, and record relevant outcomes. Delegate tenure should be time-boxed and reviewed. At review, the team may retain, rotate, or replace the delegate. Rotation is encouraged for context sharing but is not mandatory. --- ## 6. Events Events exist to produce decisions, not to satisfy a universal calendar. They 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 team members and delegates; Product Owner as needed. | | Planning | Verify priority and estimate/sizing, confirm affected-delegate alignment, name owner or owners, and record commitment. | Teams (or delegates conveying Team agreement); Product Owner for priority. | | Feedback | Review prototypes or partial results whenever useful to reduce uncertainty and adapt the Contract. | Owners, Product Owner, and relevant stakeholders as needed. | | Demo | Present the completed Result and record the product decision. | Owners, Product Owner, and relevant stakeholders. | | Team Review | Improve the team's process and review the delegate arrangement. | The team, at its chosen cadence. | Teams may also use their own syncs and small ad-hoc meetings. Ad-hoc coordination should involve only the people needed to resolve the boundary. --- ## 7. Normative rules ### 7.1 Work Item rules 1. Every Work Item **MUST** move through the Modelling, Refinement, and Execution phases. 2. Phases **MUST** apply per Work Item; the organisation need not enter them together. 3. Modelling **MUST** produce a Candidate Item, the first lifecycle state of a Work Item, before detailed team refinement. 4. A Candidate Item that cannot be described, verified, or owned through one coherent Contract **SHOULD** be decomposed into smaller Black Boxes with explicit Seams. 5. 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. 6. Refinement **MUST** produce a Ready Work Item and a recorded readiness decision before commitment. 7. At least one owner—preferably a Team or collaborating Teams—**MUST** be recorded before commitment; organisations **MAY** allow multiple owners. 8. Owners **MAY** organise collaboration and divide implementation work as they choose while preserving the contract and explicit Seams. 9. Commitment **MUST** be treated as a recorded event or status, not a fourth lifecycle state. 10. Execution **MUST** produce a Result that is complete against the current Contract and supported by the agreed Evidence. ### 7.2 Contract rules 1. Every Work Item **MUST** define its product intent, current state and/or inputs, and required state and/or outputs, as applicable. 2. Relevant constraints, errors, side effects, and invariants **MUST** be explicit. 3. 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. 4. A Contract **MUST** remain a living record with a visible change history. 5. A Contract **SHOULD** hide implementation details that consumers do not need. 6. When Black Boxes are composed, every shared input/output Seam **SHOULD** remain explicit and independently evaluable. 7. Recurring patterns **MAY** inform shared templates or capabilities, but **MUST NOT** replace the context-specific Contract. 8. Teams **MAY** use their own Contract template. ### 7.3 Refinement rules 1. Candidate Items **MAY** be provisionally ordered at any time, but commitment planning **MUST** consider only Ready Work Items. 2. 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. 3. 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. 4. A later concrete team challenge **MUST** call readiness back into question, including a challenge raised during Planning. 5. Relevant participants **MUST** address a concrete challenge before commitment and **MAY** choose how they reach agreement or handle unresolved disagreement. 6. Dependencies and affected teams **MUST** be visible. 7. A Ready Work Item **MUST NOT** depend on unrecorded context held only by the people who modelled it. 8. A Ready Work Item **MAY** retain bounded uncertainty when its assumptions, unknowns, and agreed risk, cost, or time boundaries are visible. 9. Any team with the required domain capability, technical access, and capacity **SHOULD** be able to assess the Work Item from its written Contract. 10. Teams **MAY** add context-specific Definition of Ready criteria. ### 7.4 Execution rules 1. The owner or owners **MUST** control their implementation approach and internal workflow. 2. Every Contract change discovered during Execution **MUST** be added to its history and communicated to affected producing and consuming teams. 3. Relevant parties **MUST** agree whether the Work Item remains coherent; the Product Owner **MUST** join when product intent, scope, value, or priority is affected. 4. Relevant parties **MAY** amend the Contract and continue Execution when the change remains within agreed boundaries and the existing ownership and Evidence remain suitable. 5. 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. 6. Owners **SHOULD** seek Product Owner or stakeholder feedback on prototypes or partial results whenever it would reduce uncertainty. 7. The Result **MUST** satisfy the agreed Definition of Done before the final Demo. 8. Required implementation and delivery work **MUST** both be complete. 9. Remaining work **MUST** remain visible and **MAY** stay in an amended Work Item when its intended outcome remains coherent and relevant parties agree. ### 7.5 Delegate rules 1. Each team **MUST** select its own delegate or delegates. 2. A team **MUST** be able to challenge its delegate's decision. 3. Delegation **MUST NOT** grant permanent authority over the team. 4. Delegate tenure **SHOULD** be time-boxed and reviewed. 5. At each review, a team **MAY** retain, rotate, or replace its delegate; rotation is encouraged for context sharing but is not required. ### 7.6 Cross-team rules 1. Producing and consuming teams **MUST** be identified for a shared Contract. 2. While the Product Owner and at least one delegate may record readiness, delegates of every affected team **MUST** agree before commitment. 3. Affected teams **MAY** decide how agreement is reached and how unresolved disagreement is handled; MoRE does not prescribe a universal decision mechanism. 4. The Contract, its history, and decisions **MUST** remain visible to affected teams. 5. 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. 6. Ad-hoc coordination **SHOULD** involve only people needed to resolve the boundary. ### 7.7 Product-decision rules 1. Every Result that satisfies the Definition of Done **MUST** be demonstrated to the Product Owner at the final Demo. 2. The Product Owner's acceptance or rejection **MUST** be recorded before the Work Item closes. 3. When expectations change, relevant parties **MAY** amend and continue the Work Item if its intended outcome remains coherent. 4. Relevant parties **MAY** instead close a compliant Result as contract-complete but product-rejected and create a separate Work Item. 5. A distinct outcome **MUST** enter Modelling as a separate Work Item. ### 7.8 Team Review rules 1. Team Review **SHOULD** remain distinct from Demo and focus on improving the team's process and delegate arrangement. 2. Teams **MAY** run Team Review at their chosen cadence and map it to an existing retrospective or service-delivery review. ### 7.9 Urgent-work rules 1. Urgent work **MUST** use the same phase gates. 2. The contract **MAY** be the minimum adequate record for safe action. 3. Participants **SHOULD** convene immediately rather than bypass Refinement. --- ## 8. Practical guidance ### 8.1 Reasoning loop Use one loop from intent to Evidence: 1. **Frame state:** What current state and required state matter? 2. **Decompose:** Which smaller transitions are coherent and independently verifiable? 3. **Specify:** What inputs, outputs, constraints, errors, and Evidence define each boundary? 4. **Compose:** Which Black Boxes produce inputs or consume outputs through each Seam? 5. **Evaluate:** What Evidence will establish an acceptable outcome for this Work Item? 6. **Learn:** What should change in the current or next model? Pattern recognition is Evidence, not permission to generalise early. Reuse a template or shared capability only after the boundary has genuinely repeated. ### 8.2 Contract-first design Describe observable behaviour rather than internal tasks. A useful Contract covers: - **Boundary:** the Seam being described and its producers and consumers. - **State and flow:** 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 does not need to 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 a proposed solution, and what feedback could improve them. This reflects the discussion of the “requirements pit” in *The Pragmatic Programmer* by David Thomas and Andrew Hunt; it is guidance rather than a strict MoRE definition of a requirement. ### 8.3 Decomposition Split when a smaller boundary reduces shared knowledge. A useful Candidate Item has a meaningful outcome, one coherent Contract, and independently observable Evidence. Stop splitting when another cut would: - expose internal implementation steps; - remove observable value; - create more coordination than it removes. The Work Item should fit its prospective owners' normal planning horizon. A Scrum team may use one Sprint as a local sizing heuristic, but this is not a universal MoRE limit. Multiple owners remain possible where the organisation allows them. ### 8.4 Architecture neutrality 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 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. ### 8.5 Evidence Evidence is one term for the observations participants agree are acceptable for a particular Work Item. It may show that the Contract has been fulfilled, that the intended product effect occurred, or both. Teams choose the appropriate balance and record when the Evidence can reasonably be observed. Match Evidence to the claim. | Claim | Useful Evidence | |---|---| | Behaviour is correct | Contract or acceptance tests and examples. | | A migration reached the required state | Pre/post checks, reconciliation, and rollback evidence. | | Reliability or performance holds | Metrics, thresholds, and load or failure tests. | | A user workflow creates value | Demo, usability Evidence, or a product measure. | | Research resolved uncertainty | A decision record and reproducible findings. | | A security boundary holds | Threat analysis, automated checks, and review Evidence. | “Implemented” is not Evidence. Agree before commitment what an acceptable outcome means for this Work Item, evaluate it during Execution, and present the available Evidence at the final Demo. ### 8.6 Integration and operations - 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. ### 8.7 Work Item template ```markdown # [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 rule checklists into every Work Item. The [worked checkout example](practice.html#worked-example) shows complete snapshots after Discovery, Initial Refinement, Main Refinement, readiness, Planning, early feedback, a Contract change, DoD, and the final Demo. It illustrates how one Work Item accumulates clarity and history without prescribing how a team must represent it in Jira or another tool. ### 8.8 Working sessions #### 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 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 to the Product Owner or relevant stakeholders whenever feedback would reduce uncertainty. These feedback points may adapt the living Contract but do not replace the final Demo. Demo presents the Result completed against the current Contract and records the product decision. Team Review separately improves the process and reviews delegate tenure. ### 8.9 Delegate working-agreement template ```text 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: ``` --- ## 9. Adoption and scaling ### 9.1 Start with a focused pilot Pilot MoRE around one product, a few teams, and a boundary that already causes friction. Do not begin with a paper transformation. A useful starting size is two to four teams around one product goal. 1. **Choose a boundary:** select one product area with recurring cross-team ambiguity. 2. **Select delegates:** each team chooses one or two people for a time-boxed, reviewed period. 3. **Adopt the defaults:** begin with the MoRE contract, DoR, DoD, and challenge path. 4. **Run real work:** use actual Candidate Items and Results rather than workshop examples. 5. **Inspect Evidence:** look for clearer handoffs, earlier challenges, and smaller meetings. 6. **Expand carefully:** add teams only after the pilot reduces coordination load. ### 9.2 First cycle | Step | What to establish | |---|---| | Discovery | 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 intent is already clear. | | Main Refinement | Use only when team challenge, estimation, or additional context is needed. | | Planning | Verify estimate and priority, record owners, and 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. | Practise the standard flow before customising it. ### 9.3 Existing delivery methods MoRE structures the path from product intent to commitment-quality work. It does not replace team-level delivery mechanics. | MoRE concern | Scrum | Kanban / flow | |---|---|---| | Commitment | Sprint Planning | Pull or replenishment | | Team coordination | Daily Scrum | Flow review or team sync | | Demo | Sprint Review or 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 | ### 9.4 Moving from LeSS Keep, where useful: - one product focus; - 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 living Contract's change history visible. Travellers and other collaboration patterns remain organisational choices. MoRE requires explicit ownership and boundaries, not a prescribed staffing model. ### 9.5 Pilot health check Look for observable improvement: - Ready Work Items make sense without private meeting context. - Planning verifies priority, estimates, 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. ### 9.6 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 small, temporary alignment can carry the dependency. ### 9.7 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. ### 9.8 When to split a coordination group Warning signals: - most Work 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 splitting: - name the shared boundary; - identify producers and consumers; - publish contract decisions to both groups; - use temporary delegates for boundary changes. ### 9.9 Known limits No process fixes missing authority or discipline. MoRE struggles when: - product decisions are unavailable; - architecture makes every boundary unstable; - written records are neglected; - delegates become unchallengeable gatekeepers. Address those conditions before adding another coordination layer. --- ## 10. When MoRE fits MoRE is a good fit when: - one product spans several teams; - dependencies and shared Seams need explicit ownership; - early coordination meetings have become too large; - teams use different delivery cadences. MoRE is probably unnecessary when: - 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. --- ## 11. Frequently asked questions ### Can Main Refinement be skipped? Yes. The Product Owner and at least one delegate may record readiness when the written Candidate Item already meets DoR, and align delegates of any other affected teams before commitment. A later concrete team challenge still calls readiness back into question and must be addressed before commitment. ### Can a Work Item have multiple owners? Yes, if the organisation allows it. At least one owner—preferably a Team or collaborating Teams—is required before commitment. Owners decide how to collaborate while contracts and Seams remain explicit. ### Does every Contract change return to Refinement? No. Add every change to the Contract history and involve affected producing and consuming teams (involving the Product Owner when product intent, scope, value, or priority is affected). Relevant parties may agree to amend the Contract and continue Execution. Return to Refinement when the change exceeds an agreed risk, cost, or time boundary, or makes the existing ownership or Evidence unsuitable. ### Can an amended Contract remain in the same Work Item? Yes, when its intended outcome remains coherent and relevant parties agree. A distinct outcome needs a separate Work Item. ### Can the Product Owner reject a Result that meets its Contract? Yes, on product grounds. Relevant parties may amend and continue the Work Item if its intended outcome remains coherent. They may instead close it as contract-complete but product-rejected and model the changed expectation separately. ### Must delegates rotate? No. Tenure should be time-boxed and reviewed; the team may retain, rotate, or replace a delegate. ### Does MoRE require Sprints or a particular team workflow? No. It supports iterations and continuous flow. Sprints may provide a local sizing heuristic, but owners choose their internal workflow. ### Is a Work Item closed when it meets DoD? Not yet. DoD completes Execution. The final Demo and recorded product decision are mandatory closure gates. Earlier feedback on prototypes or partial results is encouraged when useful, but does not replace the final Demo. ### Can two teams deliver one Ready Work Item together? Yes. Multiple owners are allowed when the organisation permits them and the contract, accountability, and shared Seams remain explicit. --- ## 12. Compact assessment Use these scenarios to check understanding: 1. **A Candidate Item has no agreed Evidence. Can it enter Planning?**
No. Planning considers only Ready Work Items, and the participants must agree what an acceptable outcome means and when it can be observed. 2. **Main Refinement was skipped, but a team raises a compatibility risk during Planning. Continue?** Readiness is back in question. Relevant participants address the challenge and decide how to reach agreement before commitment. 3. **Execution reveals a Contract change. What happens first?** Add it to the change history and notify affected teams. Relevant parties decide whether to amend and continue or return to Refinement under the agreed change boundaries. 4. **A Result meets DoD. Is the Work Item closed?** Not yet. The final Demo and recorded product decision remain mandatory. 5. **Two teams want to deliver one Ready Work Item together. Is that valid?** Yes, when the organisation permits multiple owners and the Seams remain explicit. 6. **A delegate's review period ends. Must the team replace the delegate?** No. The team must review the arrangement and may retain, rotate, or replace the delegate. --- ## 13. Summary MoRE coordinates multi-team work through explicit living Contracts, prepared Refinement, visible readiness, focused participation, and owner-controlled Execution. - Model product intent into a coherent Candidate Item. - Refine its Contract until informed commitment is responsible, with uncertainty visible and bounded. - Record readiness jointly through the Product Owner and at least one delegate, and align delegates of any other affected teams before commitment. - Name owners (preferably a Team or collaborating Teams) and commit to the intended outcome within current constraints. - Let owners control implementation while keeping Seams visible and seeking feedback when useful. - Keep every Contract change and agreement in a visible history. - Amend and continue when relevant parties agree; return to Refinement when change invalidates commitment. - Produce the agreed Evidence and satisfy DoD. - Present the final Demo and record the Product Owner's decision before closure. - Review delegates so representation never becomes permanent authority. **Modelling · Refinement · Execution**