Run a Sprint Review that changes the backlog, and facilitate a retrospective that ends in one real improvement.
Why it matters
The last two events of a sprint are where Scrum's learning happens. The Sprint Review inspects the product: did we build the right thing, and what should we do next? The Sprint Retrospective inspects the team: how did we work, and what will we change? Skip them, or run them as box-ticking rituals, and a team can repeat the same mistakes for months.
The Sprint Review
The Sprint Review is a working session with stakeholders, not a presentation. The Scrum Team shows what was done, stakeholders react, and together they decide what to do next. Its main output is an updated Product Backlog.
A practical agenda for a one-hour review of a two-week sprint at Northside Sports Centre:
5 min Product Owner: the Sprint Goal and whether it was met
20 min Developers show the working increment on a real phone
(a member books and cancels a court; the 3-booking limit kicks in)
15 min Stakeholders try it and give feedback
(front-desk staff: "we need to see app bookings on our screen too")
10 min What changed in the world: usage numbers, a competitor's new app, budget
10 min Product Owner updates the backlog order live; agree likely next steps
Tips:
- Show working software, not slides. If it is not done (by the Definition of Done), do not demo it.
- Invite the right people: real users, the sponsor, support staff.
- Ask questions that invite reactions: "What would stop you using this?" beats "Any questions?"
- Record decisions as backlog changes, not just meeting notes.
The Sprint Retrospective
The retrospective is for the Scrum Team only, so people can speak openly. The Scrum Guide says the team inspects how the last sprint went "with regards to individuals, interactions, processes, tools, and their Definition of Done", identifies the most helpful changes and can add them to the next Sprint Backlog.
A widely used five-stage structure (from Esther Derby and Diana Larsen's book Agile Retrospectives):
- Set the stage: welcome, the goal of the retro, and a quick check-in so everyone speaks early.
- Gather data: what happened? Facts, events, feelings.
- Generate insights: why did it happen? Look for patterns and causes.
- Decide what to do: choose one to three concrete actions with owners.
- Close: appreciate each other and check whether the retro itself was useful.
Popular formats for gathering data
| Format | Columns or prompts |
|---|---|
| Start, Stop, Continue | What should we start doing, stop doing, keep doing? |
| Went well / To improve / Ideas | Simple and quick |
| 4Ls | Liked, Learned, Lacked, Longed for |
| Sailboat | Wind (helps), anchors (holds us back), rocks (risks), island (goal) |
| Timeline | Plot events and the team's mood across the sprint |
Changing the format every few sprints keeps people engaged.
A worked retro outcome
Northside's team used Start, Stop, Continue. Three people wrote that stories arrived in the sprint with unclear refund rules. Digging in (insight): the Product Owner had no time with the finance team before refinement. Action:
Action: Before refinement, the PO checks any story touching money with finance.
Owner: Product Owner
Measure: No story in next sprint is blocked waiting for a finance decision.
Review: At the start of the next retro.
One specific action with an owner and a way to check it is worth more than ten vague resolutions like "communicate better".
Facilitation basics
- Psychological safety first. Many teams read out Norman Kerth's Prime Directive at the start: everyone did the best job they could, given what they knew at the time, their skills, the resources available and the situation.
- Everyone writes before anyone talks (silent brainstorming on sticky notes), so quiet people are heard.
- Group and vote (dot voting) to focus on what matters most.
- Focus on the system, not individuals. "Our review process lets big changes wait three days" rather than "Sam is slow at reviews".
- Start the next retro by checking last time's actions.
Common mistakes
- Review as a status meeting with slides and no feedback.
- Demoing unfinished work, which hides the real state of the product.
- Retros with no actions, or the same actions every time.
- Managers in the retro, which makes people guarded.
- Blame. It shuts down honest discussion immediately.
Quick recap
- The Sprint Review inspects the increment with stakeholders and updates the Product Backlog.
- The retrospective inspects how the team works and ends with a few concrete actions.
- Use a structure (set the stage, gather data, generate insights, decide, close) and vary formats.
- One owned, measurable action beats many vague ones; check it next time.
Try it
Open the Do tab and facilitate a short retrospective.