Use one loop from intent to evidence.
What current state and required state matter?
Which smaller transitions are coherent and independently verifiable?
What inputs, outputs, constraints, errors, and proof define each boundary?
Which boxes produce inputs or consume outputs?
What evidence will prove the Result?
What should change in the next model?
Describe observable behaviour, not internal tasks.
Boundary
The box being described and its producers and consumers.
State and flow
Applicable current state and/or inputs, required state and/or outputs, errors, and side effects.
Constraints
Invariants, compatibility, security, reliability, performance, and scope.
Proof and change
Evidence, rollout, migration, rollback, versioning, and notification.
A contract need not be an API. A migration, research decision, refactor, or manual process can define a transition and observable proof.
Split when a smaller boundary reduces shared knowledge.
A useful Candidate has a meaningful outcome, one coherent contract, and independent evidence. It should fit its prospective owners' normal planning horizon. Stop splitting when another cut would expose implementation steps, remove observable value, or create more coordination than it removes.
A Scrum team may use one Sprint as a local sizing heuristic. That is not a universal MoRE limit, and multiple owners remain possible where the organisation allows them.
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 that 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.
Match the proof to the claim.
| Claim | Useful evidence |
|---|---|
| Behaviour is correct | Contract or acceptance tests and examples |
| Migration reached the required state | Pre/post checks, reconciliation, and rollback evidence |
| Reliability or performance holds | Metrics, thresholds, and load or failure tests |
| User workflow creates value | Demo, usability evidence, or product measure |
| Research resolved uncertainty | Decision record and reproducible findings |
| Security boundary holds | Threat analysis, automated checks, and review evidence |
“Implemented” is not evidence. Design evaluation before commitment, perform it during Execution, and present it at Demo.
Make compatibility and operability part of the seam.
- 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.
Work Item
# [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 scope Constraints, errors, side effects, invariants, in scope, and out of scope. ## Seams and dependencies Producing teams, consuming teams, and external dependencies. ## Risks and assumptions What remains uncertain. ## Acceptance evidence How the Result will be proven. ## Ownership Owner or owners responsible for driving the Work Item. ## Decisions and changes Readiness, commitment, contract changes and materiality, product decision.
Apply the canonical Readiness and Execution rules rather than copying separate checklists into the template.
Prepare first; invite only useful voices.
Discovery and Initial Refinement
State intent, model the outer boundary, shape Candidates, 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, align affected delegates, and stop when DoR is met. Skip it when the Product Owner and a delegate can already record Readiness.
Planning
Verify estimates and current priority, name at least one owner, and record commitment. A concrete challenge reopens refinement.
Demo and Team Review
Demo presents the contract-complete Result and records the product decision. Team Review separately improves the process and reviews delegate tenure.
Delegate working agreement
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: