Agile delivery develops useful software through feedback and adaptation. Control it through 5 agreements: outcome, ordering, acceptance, quality and change decisions. Iterations should create inspectable progress; they should not make scope, responsibility or unfinished work harder for the business to understand.
How should iterations produce useful evidence?
Start with a product outcome that the business can recognise. A list of requested screens is not always enough to explain what should improve for users. Describe the activity the software will enable and the people who depend on it. Keep the outcome visible when deciding priorities so a convenient technical task does not automatically outrank a more important user need.
Separate agile principles from a particular framework. The Agile Manifesto principles support frequent delivery, collaboration and reflection. The Scrum Guide specifies a particular framework with defined accountabilities, events and artefacts. A team can discuss iterative delivery without claiming to follow Scrum. If a proposal names Scrum, ask how its actual working arrangement corresponds to the guide.
Order the work through an accountable decision. Stakeholders may disagree about priorities, but the team needs a legible route for resolving that disagreement. Scrum gives Product Backlog management and value accountability to the Product Owner. Use the relevant decision structure for your approach and record it clearly. A shared board does not itself establish who can change the order of the work.
Choose an increment that can be inspected as a usable result. For a fictional booking workflow, that might be a coherent path for requesting and confirming an appointment in a test environment. Isolated screens or completed tickets may show activity without proving that the journey works. Ask what a user can do at the end of the iteration and what evidence demonstrates it.
Write acceptance examples before the demonstration. Include a normal case, an invalid request and a relevant exception. The examples should describe expected behaviour in business language. Keep implementation suggestions separate unless they are genuine constraints. A test that merely repeats the code’s structure can miss a misunderstood business rule; the acceptance example should retain the user’s intended result.
How can acceptance and change remain controlled?
Distinguish item acceptance from a shared quality standard. Scrum’s Definition of Done describes the quality state of an increment. A particular backlog item may also need its own behaviour examples. Both matter: a feature can perform its happy path while failing agreed quality checks, or meet technical standards while solving the wrong task. Do not collapse these judgements into a single vague approved label.
Classify feedback before changing the plan. A defect violates an agreed expectation; a new request changes the desired scope; a discovered constraint may require a trade-off. Record which situation applies and who can decide the response. Calling every issue scope change can hide defects, while calling every preference a defect can conceal an expanding brief. The classification should follow the evidence.
Make changed priorities visible. Explain what the new work displaces, what remains unfinished and whether the current goal still makes sense. Scrum describes adaptation around its goals and planned work; it does not mean a team must absorb every new request without consequence. Keep the decision and its reason with the work record so later conversations do not depend on memory.
Use reviews and reflection for different questions. Inspecting the product helps decide what to build next. Examining the team’s working process helps improve how it delivers. A meeting can contain both conversations, but the resulting actions should remain distinct. Retain a product decision and a process improvement with named owners rather than producing general notes that nobody is responsible for applying.
Plan release and handover deliberately. Completing an iteration does not automatically authorise a production change, and a usable increment may still need a controlled release decision. Record required checks, operational ownership and rollback arrangements appropriate to the service. This article provides delivery guidance, not an instruction to bypass an organisation’s release authority or claim that unfinished configuration is ready for customers.
Include an unfinished-item exercise at review. Present a fictional feature that works in the normal case but fails an agreed exception. Ask how it appears in the progress record and what decision follows. Do not count it as complete merely because most of the screen is visible, and do not erase the useful work already demonstrated. Record the remaining gap and its effect on the increment’s usability. Then assess a new request against the same goal. This keeps reporting honest without turning every partial result into a binary judgement about the entire project, and it gives stakeholders a clear basis for deciding the next action.
Decision worksheet
Original contribution: an iteration acceptance-and-change ledger. For a fictional booking journey, list the expected behaviour, the shared quality conditions and the evidence demonstrated at review. Add feedback rows and classify each as a defect, new requirement, constraint or unresolved question. Record the decision-maker and the effect on the ordered work. Keep a release-authority field separate from the review result. This makes a completed demonstration insufficient to imply production approval and gives the business a clear account of what changed and why.
| Checkpoint | Evidence to retain | Decision or corrective action |
|---|---|---|
| Outcome | User activity and product goal | Keep priorities tied to value |
| Ordering | Decision owner and ordered work | Resolve conflicting stakeholder requests |
| Acceptance | Behaviour examples and observed results | Separate defects from preferences |
| Quality | Shared completion standard and evidence | Do not hide incomplete work |
| Change | Reason, consequence and authorised decision | Show what moves or remains open |
Work through a disputed example before adopting the ledger. Suppose the brief requires a confirmation message after a valid booking, but the demonstration only shows a submitted form. That is a gap against the stated behaviour. If the business now wants a new reminder channel, that is a further requirement to assess. The distinction is practical: it determines whether the team corrects existing work or makes a new scope decision. Retain the original acceptance wording so the judgement can be explained without relying on who remembers the meeting best.
See web development for delivery context and mission control for workflow scope. To discuss a project, get started with a fictional journey and the ledger.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.