Normative reference

MoRE Rules

The minimum rules that distinguish MoRE from general advice. Guides and examples may vary; these rules define the framework.

How to read the rules

Three levels of prescription.

MUST — requiredSHOULD — recommended defaultMAY — contextual choice

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

  1. Every Work Item MUST move through the Modelling, Readiness, and Execution phases.
  2. Phases MUST apply per Work Item; the organisation need not enter them together.
  3. Modelling MUST produce a Candidate, the first lifecycle state of a Work Item, before detailed team refinement.
  4. A Candidate that cannot be described, verified, or owned through one coherent contract SHOULD be decomposed into smaller black boxes.
  5. Each resulting Candidate SHOULD be a coherent, independently verifiable state transition—not merely an implementation task—and fit its prospective owners' normal planning horizon.
  6. Readiness MUST produce a Ready Work Item and a recorded readiness decision before commitment.
  7. At least one owner 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 contract-complete Result and agreed evidence.

Contract rules

  1. Every Work Item MUST define its 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. Observable proof MUST be agreed before commitment.
  4. A contract SHOULD hide implementation details that consumers do not need.
  5. When boxes are composed, every shared input/output boundary SHOULD remain explicit and independently evaluable.
  6. Recurring patterns MAY inform shared templates or capabilities, but MUST NOT replace the context-specific contract.
  7. Teams MAY use their own contract template.

Readiness rules

  1. Candidates MAY be provisionally ordered at any time, but commitment planning MUST consider only Ready Work Items.
  2. The Product Owner and a delegate MUST jointly record the readiness decision.
  3. Main Refinement MAY be skipped when the Product Owner and delegate determine that the Candidate meets the Definition of Ready without it.
  4. A later concrete team challenge MUST reopen refinement, including a challenge raised during Planning.
  5. An escalated challenge MUST be resolved or explicitly accepted by a named decision owner before the Work Item can be Ready.
  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. Any team with the required domain capability, technical access, and capacity SHOULD be able to assess the Work Item from its written contract.
  9. Teams MAY add context-specific Definition of Ready criteria.

Execution rules

  1. The owner or owners MUST control their implementation approach and internal workflow.
  2. Every contract change discovered during Execution MUST be recorded and communicated to affected producing and consuming teams.
  3. Affected teams or delegates MUST jointly assess whether a contract change is material; the Product Owner MUST join when product intent, scope, value, or priority is affected.
  4. A material contract change MUST return the Work Item to Readiness; a recorded non-material clarification MAY be applied during Execution.
  5. The Result MUST satisfy the agreed Definition of Done before Demo.
  6. Required implementation and delivery work MUST both be complete.
  7. Remaining work MUST NOT be hidden inside a completed Work Item.

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.

Cross-team rules

  1. Producing and consuming teams MUST be identified for a shared contract.
  2. Delegates of every affected team MUST agree before commitment.
  3. The contract and decision MUST remain visible to affected teams.
  4. The Product Owner MUST be informed of shared-contract changes.
  5. Ad-hoc coordination SHOULD involve only people needed to resolve the boundary.

Product-decision rules

  1. Every Result MUST satisfy the Definition of Done before Demo.
  2. Every Result MUST then be demonstrated to the Product Owner.
  3. The Product Owner's acceptance or rejection MUST be recorded before the Work Item closes.
  4. A contract-compliant Result rejected on new product grounds MUST close as contract-complete but product-rejected.
  5. Changed or previously unstated expectations MUST enter Modelling as a new Work Item.

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.

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 readiness.