Move from model to practice.
Shared language.
| Term | Meaning |
|---|---|
| Candidate | The first Work Item state: modelled intent not yet ready for commitment. |
| Ready Work Item | A Work Item with a recorded Readiness decision. |
| Result | The contract-complete outcome produced by Execution and ready for Demo. |
| Contract | The explicit boundary: applicable state and inputs, required state and outputs, constraints, and proof. |
| Seam | A shared contract boundary between producing and consuming teams or boxes. |
| Delegate | A temporary, team-selected representative for early coordination and shared seams. |
| Challenge | A concrete concern that blocks or reopens Readiness until resolved or explicitly accepted. |
| Commitment | A recorded event or status after Readiness, not a separate lifecycle state. |
| Product decision | The Product Owner's recorded acceptance or rejection after Demo and before closure. |
| Black box | A viewpoint where consumers reason from observable contract rather than internals. |
| Decomposition | Breaking complexity into coherent, independently verifiable transitions. |
| Composition | Connecting boxes through explicit seams to explain a larger system. |
Decisions that commonly need clarification.
Can Main Refinement be skipped?
Yes. The Product Owner and a delegate may record Readiness when the written Candidate already meets DoR. A later concrete team challenge still reopens refinement.
Can a Work Item have multiple owners?
Yes, if the organisation allows it. At least one owner is required before commitment; owners decide how to collaborate while contracts and seams remain explicit.
Does every contract change return to Readiness?
No. Record every change and let affected teams assess materiality together. Include the Product Owner for product concerns. Material changes return; non-material clarifications may continue in Execution.
Can the PO reject a Result that meets its contract?
Yes, on product grounds. Close the original as contract-complete but product-rejected, then model changed expectations as a new Work Item.
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 supply a local sizing heuristic, but owners choose their internal workflow.
Can you apply the rules?
Answer before opening each explanation.
1. A Candidate has no observable proof. Can it enter Planning?
No. Planning commits only Ready Work Items, and proof is part of the contract.
2. Main Refinement was skipped, but a team raises a compatibility risk during Planning. Continue?
No. The concrete challenge reopens Readiness until resolved or explicitly accepted.
3. Execution reveals an output clarification. What happens first?
Record it and notify affected teams. They assess materiality together; the PO joins if product concerns are affected.
4. A Result meets DoD. Is the Work Item closed?
Not yet. Demo and the recorded product decision are mandatory closure gates after DoD.
5. Two teams want to deliver one Ready Work Item together. Is that valid?
Yes. Multiple owners are allowed when the organisation permits them and the seams remain explicit.
6. A delegate's review period ends. Must the team replace them?
No. The team must review the arrangement and may retain, rotate, or replace the delegate.