Iteration Review
The iteration review, which the Agile Extension to the BABOK Guide calls "Reviews", is the session where the team shows stakeholders a working increment of the solution and gathers their feedback. It is held at the end of each iteration and bears on finished work only. Alongside the team, the session brings in the people best placed to say whether the increment meets the need, among them customers, users and business representatives. The feedback goes to the product owner, who draws the backlog priorities from it. In Scrum, the sprint review is this session: it runs to at most four hours for a one-month sprint and the Guide gives it no authorisation role.
Goal
The iteration review is the session in which a team demonstrates and inspects a completed increment of the solution with stakeholders in order to obtain feedback, the purpose the Agile Extension to the BABOK Guide sets for it. The team that did the work runs the session. It comes round at the end of each iteration; it brings together the whole team and the stakeholders the product owner or the customer representative invites for the increment at hand.
The output of the session is feedback that can be acted on. The product owner or the customer representative consolidates it and decides what enters the backlog. The Agile Extension states why the cadence exists: soliciting feedback early and often raises the chances that a solution meets the need on the day it reaches customers. The session is more useful when it ties the work completed back to the vision and the objectives of the organisation and of the initiative.
The Agile Extension places the technique at the Delivery horizon, where it counts regular contact with stakeholders among the strengths. Table 7.0.1 lists it among the communication techniques that work with stakeholders outside the team. The retrospective, in the same family, appears on the internal-team side.
The boundary with work product reviews
The BABOK Guide treats reviews as the evaluation of the content of a work product by people other than its author: a document, a specification or a model, examined on the page. The Agile Extension builds on that chapter and departs from it on the object: the iteration review bears on a working solution, handled during the session. A reviewer looks for the gap between a written requirement and its intent; a stakeholder put in front of the increment discovers what the written requirement did not say.
The boundary with the retrospective
The retrospective examines, among team members alone, how the team worked. The iteration review shows, in front of the team and outside stakeholders, what the team built. Both sessions close the same iteration and often follow one another the same day; confusing them means handling an internal subject in front of customers or leaving customer feedback with no one to receive it.
Usage
When to use it
- End of an iteration with completed work: show the increment and settle what comes next in the backlog with the people who will use it.
- Stakeholders outside the team: customers, users and sponsors react to a product they handle themselves.
- Doubt about the fit with the need: the running increment surfaces the gaps a document lets through.
- A Delivery horizon running over several months: the cadence keeps stakeholders engaged.
- A team with no direct contact with its users: the session restores a conversation.
When not to use it
- The team's way of working is what needs examining: hold the retrospective.
- A document or a specification is what needs evaluating: nothing is running yet, so go through a work product review.
Description
Three stages
The team demonstrates the completed increment in operation. The people present ask their questions and discuss what has changed in their environment. The product owner takes up that feedback and adjusts the backlog for the next iteration.
The first stage determines what the other two are worth. The Agile Extension restricts the demonstration to completed work: in front of a half-integrated increment, the feedback bears on a solution that does not exist. The Scrum Guide makes a rule of it: a backlog item that does not meet the Definition of Done, the quality criteria an increment must satisfy to count as finished, cannot be presented at the sprint review and goes back to the backlog.
The elements
The Agile Extension describes the technique through two elements, the delivered solution and the stakeholders, the latter split across three roles.
| Element / role | What it covers |
|---|---|
| The delivered increment | A completed part of the solution, shown in operation, which the stakeholders react to. |
| The key stakeholders | The people best placed to say whether the increment meets the need. |
| The team | Every member working on the initiative attends the session, leads the discussion and gathers the feedback first-hand. |
| The product owner or the customer representative | The decision-maker who leads the initiative. This person sees to it that the session produces feedback on the solution, consolidates it and settles what enters the backlog. |
The sprint review in Scrum
The Scrum Guide gives the sprint review a purpose: to inspect the outcome of the sprint and determine the adaptations that follow. The Scrum Team presents its work to the key stakeholders and discusses with them the progress towards the Product Goal, the product objective that successive sprints move the team towards. The people present examine what was accomplished during the sprint and what has changed in their environment, then decide together what comes next. The Product Backlog may be adjusted to seize new opportunities.
The Guide calls the event a working session and asks the team not to reduce it to a presentation. It places it second to last in the sprint, just before the retrospective. Its length is capped at four hours for a one-month sprint; for a shorter sprint, the session is usually shorter. The sprint review is not a precondition for releasing: an increment may be delivered to stakeholders before the end of the sprint.
What makes an iteration review fail
The task-by-task demonstration
The team goes through each completed item, in backlog order, explaining what it did. Stefan Wolpers lists this pattern among the common defects, under the name "sprint accounting": the session accounts for the work done when it should be showing what the solution now makes possible. The feedback then bears on screen details. After a few iterations the stakeholders stop coming and the team concludes that they have lost interest in the product. The counter is to show one complete path through the product, from a person's need to the result they obtain.
The review turned into a gate
The session becomes the forum where a stakeholder approves or refuses the release. The agenda shifts towards the sign-off. The team shows what will pass and stays quiet about what is still fragile; the feedback disappears. The Scrum Guide is explicit: the sprint review does not authorise a release. An authorisation decision exists in most organisations; it belongs to product governance and is taken outside this session.
Feedback spread too thin
The Agile Extension names the first limitation: when the review brings together a broad range of stakeholders, the feedback becomes too varied for the team to analyse and act on. Twenty people produce twenty opinions and none of them settles anything. The key stakeholders are the ones who can say whether the increment meets the need: a question put to three people who will use the product is worth more than a round table of twenty.
Rank counting for more than use
The Agile Extension names the second limitation: in an organisation where hierarchy counts, the feedback of a senior stakeholder weighs more than everyone else's, with no regard for that person's interaction with the product or their understanding of the objectives. A remark from the director becomes a backlog item within the hour; a remark from an employee who handles thirty files a day stays a note. The facilitator answers this by attributing each piece of feedback to its author and to that author's use of the product.
AI considerations
A language model prepares the session from the iteration's completed items: it proposes a running order for the demonstration that traces one user's path through the solution, ties each item to the objective it serves and drafts the questions to put to each group present. After the session it transcribes the discussion and attaches each piece of feedback to the backlog item concerned.
The demonstration bears on the actual increment: a generated mock-up shows a solution that does not exist. Weighing contradictory feedback amounts to deciding what the team will do with the next iteration's time; that decision belongs to the product owner, whom the Agile Extension names for this consolidation. An automatic summary smooths over the isolated objection, often the one from the person who will use the product every day.
The session brings in people from outside the organisation, customers included. A recording, a transcript or notes naming individuals sent to an external service amount to processing of personal data within the meaning of the revised Federal Act on Data Protection (revFADP): the intended use is announced before the session and stays within what was announced.
Examples
A team at a cantonal bank delivers the online mortgage calculator in two-week sprints. The sprint 12 review brings together the team, the product owner, two branch advisers, the credit compliance specialist and three customers recruited from those who had requested a calculation the month before. The team shows one complete path on the demonstration environment: a household enters an income of CHF 168'000 and a property at CHF 900'000, obtains the CHF 180'000 of equity required and a theoretical cost of CHF 53'000 a year at the imputed rate of 5%, that is 31.5% of income, below the one-third limit. The result then reaches them by email. The three customers take the controls in turn and enter their own situation; it is by handling the calculator that two of them stumble on the rate displayed, which a demonstration run by the team alone would not have surfaced.
| What was shown | Feedback gathered and its author | Decision carried into the backlog |
|---|---|---|
| The theoretical cost calculated at the imputed interest rate of 5% | "The customer sees a rate of 5% when the offer they hold is at 1.4%, and they call the branch" (branch adviser, confirmed by two customers) | Display the reason for the imputed rate next to the result. High priority. |
| Sending the calculation result by email | Two customers looked for the document in their spam folder; the third expected it in e-banking (customers) | Post the result to the client portal and flag it by email. Logged, to be scoped. |
| The legal notice at the foot of the summary | "The calculation does not bind the bank: the current wording does not say so clearly enough" (compliance specialist) | Rework the wording with the legal department before the release. High priority. |
| The printable summary | No reaction | None. The item stays as it is. |
The most useful row of the table is the last: a delivered item that draws no reaction points to a feature nobody asked for, a question the product owner reopens outside the session. The three other rows entered the backlog during the session, in front of their authors; the one still to be scoped will go through backlog refinement before it is taken into an iteration. No release decision was taken: the calculator ships once the reworked legal notice is approved.
Visualisations
The main visualisation of an iteration review is the increment itself, shown running on an environment where the people present can handle it. A screenshot or a slide deck does not produce the same feedback.
The output of the session fits a three-column table: what was shown, the feedback gathered with its author, the decision carried into the backlog. Kept from one review to the next, this register brings out the feedback that comes back a second time without having been handled, as well as the delivered items nobody talks about.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Low | The Agile Extension counts light facilitation among the strengths of the technique: pick the path to show, invite the right people, check that the increment runs on the demonstration environment. |
| Execution | Medium | The session mobilises the whole team and people from outside, up to four hours for a one-month sprint according to the Scrum Guide, and the outlay comes round at every iteration. |
| Documentation | Low | The output is a set of attributed items of feedback carried into the backlog, captured during the session. |
Tooling
The demonstration environment carries the session. An integration or pre-production environment, refreshed with the iteration's increment and filled with plausible data, allows the product to be shown running. Empty or absurd test data move the discussion onto the data set. An environment loaded with a copy of production exposes personal data to outsiders and calls for anonymisation beforehand.
The backlog management tools (Jira, Azure DevOps, GitLab and their equivalents) take the feedback during the session. An item created in front of the room, with the author of the feedback in its description, avoids reconstructing it from memory the next day and shows stakeholders that their remark was captured.
The video conference with screen sharing (Teams, Zoom, Webex and their equivalents) holds the session remotely; the Agile Extension prefers a conversation in person. Remotely, hands-on use by the stakeholders is lost: handing control to a customer on the demonstration environment or sending them access before the session restores that contact.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.15 Reviews: the purpose of the technique, the demonstration of a working solution, the session run by the team that did the work, the restriction to completed work, the tie back to the vision and the objectives, the consolidation of feedback by the product owner, the elements, along with the strengths and limitations stated there, among them regular stakeholder engagement at the Delivery horizon, feedback that is too varied and the weight of hierarchical rank.
- IIBA, Agile Extension to the BABOK Guide, §7.0, table 7.0.1 Selecting the Right Technique: the review listed among the communication techniques that work with stakeholders outside the team.
- Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020), "Sprint Review" and "Increment" sections: the purpose of the event, the presentation to key stakeholders, the discussion of progress towards the Product Goal and of what has changed in the environment, the possible adjustment of the Product Backlog, the working session that is not reduced to a presentation, the place as second-to-last event of the sprint and the four-hour cap for a one-month sprint; then, for the increment, the exclusion of any role as a gate and the rule forbidding the presentation of an item that fails the Definition of Done.
- Stefan Wolpers, 15 Sprint Review Anti-Patterns, Scrum.org, 2019: a practitioner's catalogue, not normative; the walk through every completed item that he names "sprint accounting" and the review turned into a gate.