What a sprint review is for when agents shipped the work
Stefan-Iulian Tesoi · · 5 min read
Outcomes and decisions, not a tour of every change. When coding agents shipped most of a sprint, nobody in the room can absorb forty small items in an hour. A sprint review should show the three changes that move the product goal, the evidence that each one works, and the decisions the team needs from its stakeholders.
The event keeps its slot at the end of the sprint. What changes is volume. A team of five with agents doing most of the building can close forty items in a one-week sprint, most of them small and invisible outside engineering. The old format, where each developer demos what they built, was designed for eight items.
What is a sprint review for now?
The same thing it was always for: inspecting the outcome of the sprint and deciding what to adapt. The Scrum Guide calls the event a working session that should not be limited to a presentation, and describes the increment as "a concrete stepping stone toward the Product Goal".
What coding agents change is the ratio. When building was slow, showing the increment took most of the hour and deciding took the last few minutes. When building is cheap, the increment is large and mostly unremarkable, and the scarce resource is the stakeholder's judgement about what to build next. The hour should be spent on the scarce thing.
Why does demoing every item stop working?
Because a sprint demo of forty items is a status report, and the room stops listening long before the end. Three things go wrong in that format:
- Nobody can tell which changes matter. A renamed setting and a new billing flow get two minutes each.
- Questions arrive too late. A decision a stakeholder could have made in minute five comes up in minute fifty, and gets deferred.
- The presenter did not build it. A developer narrating an agent's pull request reads its description aloud, which anyone could have read.
An agent-built increment also hides its gaps in plain sight. A feature that demos well on the happy path was accepted against criteria nobody in the room has read. The complete reconciliation of what shipped belongs in an engineering audit of what your agents actually shipped, not in front of stakeholders.
How do you choose the three changes worth showing?
Show a change when it moves the product goal, when a stakeholder can observe it, or when it needs a decision. Everything that meets none of the three goes on a list.
| Change | Moves the goal? | Observable? | Needs a decision? | In the review |
|---|---|---|---|---|
| Onboarding step reordered | Yes | Yes | Yes: keep the old flow for existing users? | Shown first |
| New invoice export | Yes | Yes | No | Shown |
| Retry logic on the webhook queue | Indirectly | No | No | On the list |
| Twelve dependency upgrades | No | No | No | One line |
The list is shared before the meeting, grouped by area, with a link to every item. A stakeholder who cares about webhook retries will read it; nobody else should sit through it.
Each change that is shown comes with its evidence: the acceptance criteria it was accepted against and how they were checked. In Laimonade the Done column records who closed each item, a person or Laimon, the product owner agent, together with the criteria it was checked against, so the list of what shipped is read off the board rather than reassembled from chat.
Which decisions should the room make?
The ones only stakeholders can make: whether a change reaches every customer, what to build next given what now exists, and which trade-off to accept where the team found one. Write each as a question with its options before the meeting.
- Release. Ship to everyone, to a subset, or hold.
- Order. What moves up the backlog now that this exists.
- Trade-off. The faster export drops two rarely used columns; which matters more.
- Stop. What to drop because the increment already answers it.
A review that ends with three answered questions has done its job. One that ends with forty items shown and nothing decided was a status meeting with a longer agenda.
The answers feed the next planning session directly. Sprint planning with AI agents starts from what is ready to build, and a decision made in the review is often what makes an item ready.
How do you prepare the review in under an hour?
Spend about forty minutes, and only if the board is current: fifteen to pick the three changes, fifteen to write the questions, and ten to check that each piece of evidence opens. How items reach Done is set out in the sprint workflow; when that is kept honest during the week, preparation is selection rather than archaeology.
A sprint review agenda that fits in forty-five minutes:
- Five minutes: the product goal. Where the increment leaves it.
- Twenty minutes: three changes. About seven minutes each: what changed, the evidence, the question.
- Ten minutes: decisions. One answer per question, recorded with a name against it.
- Five minutes: the full list. Questions only, no walkthrough.
- Five minutes: the outside world. What changed among customers or the market that should reorder the backlog.
Frequently asked questions
Should agent-built work be demoed live?
Only when a stakeholder needs to see the behaviour to decide something. A live demo runs the happy path the agent was tested on, which proves little. A short recording made the day before, shown next to the criteria the change was accepted against, shows the same thing without the room watching a login screen time out.
Who presents when an agent built the feature?
Whoever owns the decision the change raises, usually the product owner or the person who wrote the item. They know why it was built and what is being asked of the room. The engineer who reviewed the pull request answers technical questions; nobody narrates a coding agent's work on its behalf.
How is the review different from the retrospective?
The review inspects the product; the retrospective inspects the process. For sprint review vs retrospective, the clearest line is the audience: stakeholders attend the review to decide what to build next, and the team holds the retrospective alone to change how it specifies and accepts work. A retrospective with coding agents runs on a rework ledger, not on the demo.