Shared language.
Work and lifecycle
| Term | Meaning |
|---|---|
| Work Item | A deliberately generic conceptual unit, independent of ticket type, tool, or team workflow. |
| Candidate Item | The first Work Item state: modelled intent not yet ready for commitment. |
| Ready Work Item | A Work Item whose Contract supports informed commitment, with uncertainty visible and bounded, and whose readiness decision is 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. |
Roles
| Term | Meaning |
|---|---|
| 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. |
| Delegate | A temporary role granted by a Team for early coordination and shared Seams—not a separate manager or authority layer. |
| 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. |
Boundaries and proof
| Term | Meaning |
|---|---|
| Contract | The living, versioned record of a Work Item's current shared understanding and change history. |
| 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 its implementation remains under its Owners' control. |
| Evidence | Agreed observations used to judge an acceptable outcome; they may show Contract fulfilment, intended product effect, or both. |
| Definition of Ready (DoR) | The conditions a Candidate Item must meet before the Product Owner and at least one Delegate record that it supports informed commitment (with Delegates of all affected Teams aligned before commitment). |
| Definition of Done (DoD) | The conditions that complete Execution: agreed Evidence exists, implementation and delivery are complete, change history is current, and remaining work is visible. |
| 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. |
Events and decisions
| Term | Meaning |
|---|---|
| Challenge | A concrete concern that calls the Contract, readiness, or continued Execution into question. |
| 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 commitment to pursue the intended outcome within current constraints, not a separate 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. |
Reasoning
| Term | Meaning |
|---|---|
| Decomposition | Breaking complexity into coherent, independently verifiable transitions. |
| Composition | Connecting Black Boxes through explicit Seams to explain a larger system. |
Decisions that commonly need clarification.
Can Main Refinement be skipped?
Yes. The Product Owner and at least one delegate may record the readiness decision 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 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 and continue. Return when a change exceeds an agreed risk, cost, or time boundary, or makes the 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 PO reject a Result that meets its Contract?
Yes, on product grounds. Relevant parties may amend and continue if the intended outcome remains coherent, or 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 supply a local sizing heuristic, but owners choose their internal workflow.