Sprint review
Inspect the Sprint outcome with stakeholders and consider future adaptations. Ask: what have we learned about the product and what should come next?
Agile retrospectives
An agile retrospective for a better next cycle.
An agile retrospective gives your team time to examine how work happened and choose what to change. Start with a clear board. Finish with an experiment you can check.
Choose a retrospective templateWhat is an agile retrospective?
An agile retrospective is a recurring team conversation about how work happened and what to improve next. The team examines recent experience, identifies useful patterns, and agrees on a change it can test. Scrum formalizes this as the Sprint Retrospective; teams outside Scrum can use the same learning practice.
The Scrum Guide defines its purpose as improving quality and effectiveness. That gives the conversation a useful test: will this decision help the team do better work, or have we only produced a longer list of complaints?
Read the agile retrospective guide for deeper examples →Sprint retrospective
Inspect how the team worked: interactions, processes, tools, and the Definition of Done. Ask: what should we change to improve quality and effectiveness?
From “reviews take too long” to a useful experiment
Consider an illustrative engineering team whose changes repeatedly wait for review. The first card says “reviews take too long.” Before choosing a solution, the team makes that observation specific.
- Observation
- “Four changes sat ready for review overnight. Two were only picked up when someone asked in chat.” The team checks timestamps rather than treating a memory as proof.
- Working explanation
- Review requests arrive in several channels, and nobody knows which one to pick up first. This is a hypothesis about the system, not a judgment about a teammate.
- Experiment
- For the next cycle, put review requests in one queue and rotate a daily reviewer. Maya owns the setup; the whole team can flag a request that is being missed.
- Evidence and guardrail
- At the next retro, compare ready-for-review to first-review times and ask whether interruptions increased. Keep, adapt, or stop the rotation based on both signals.
A small experiment is easier to evaluate than “communicate more.” If the constraint belongs to another team, name the dependency and the person who will take it forward. Do not promise an improvement the team cannot control.
Turn a discussion into a clear action item →Choose a format for the conversation you need
The format changes the questions, not the purpose. Keep a useful structure long enough to learn from it; change it when the prompts stop revealing something new.
Went Well, To Improve, Action Items
Choose this for a first retro or when the team needs a straightforward conversation about what to keep and change.
Which moment made the work easier? Which moment made it harder?
Went WellTo ImproveAction Items
Open template →Start, Stop, Continue
Choose this when the team already sees a pattern and needs to decide which working habits should change.
What would we stop doing for one cycle, and what would we expect to happen?
StartStopContinue
Open template →4Ls Retrospective
Choose this after unfamiliar work, a new tool, or a release where learning matters as much as delivery.
What did we learn that should change how we approach the next cycle?
LikedLearnedLackedLonged for
Open template →Sailboat Retrospective
Choose this when progress, drag, and risks need to be understood together. Translate the metaphor back into concrete work.
Which anchor can we actually remove, and which risk needs an owner?
Wind (What helped us)Anchors (What held us back)Rocks (Risks ahead)Island (Goals)
Open template →Want a lighter way into the conversation? Explore fun retro formats or the fun retrospective ideas playbook.
A suggested 45-minute retrospective agenda
For a small team with a focused topic, try this sequence. Send the previous experiment and any relevant evidence in advance. Allow more time when the issue is complex; 45 minutes is a facilitation choice, not a Scrum requirement.
- 0–5 min
Check the previous experiment
Bring its evidence. Decide whether to keep, adapt, or stop the change, then agree on the focus for today.
- 5–13 min
Write observations independently
Ask for a specific event from this cycle and its effect. Include what worked so the team can preserve it.
- 13–20 min
Group and choose a theme
Clarify cards, group related observations, and vote to narrow the discussion. A low-vote safety or quality concern still deserves attention.
- 20–35 min
Investigate the conditions
Ask what made the pattern possible: waiting, unclear ownership, tools, capacity, or assumptions. Separate an observed fact from an explanation you still need to test.
- 35–45 min
Agree on one experiment
Write the change, owner, check date, evidence, and a guardrail. Confirm the team can actually try it before the next retrospective.
Give everyone time to write before the most confident voice shapes the discussion. Ask about conditions and consequences rather than who is at fault. Voting narrows a conversation; it does not erase concerns about safety or quality.
Read the full sprint retrospective facilitation guide →Agile retrospective questions
What is an agile retrospective?
An agile retrospective is a recurring team conversation about how work happened and what to improve next. The team examines recent experience, identifies useful patterns, and agrees on a change it can test. Scrum formalizes this as the Sprint Retrospective; teams outside Scrum can use the same learning practice.
Who attends a Sprint Retrospective?
In Scrum, the Scrum Team takes part: Developers, the Product Owner, and the Scrum Master. The retrospective examines the team’s interactions, processes, tools, and Definition of Done. It is not a stakeholder status meeting. Outside Scrum, involve the people whose work and collaboration the team is inspecting.
How long should an agile retrospective last?
Choose a length that fits the work and the discussion. The 45-minute agenda on this page is a suggested starting point, not a Scrum rule. The Scrum Guide sets a maximum of three hours for a one-month Sprint Retrospective; for shorter Sprints, the event is usually shorter.
How is a retrospective different from a sprint review?
A Sprint Review inspects the outcome of the Sprint with stakeholders and considers future adaptations. A Sprint Retrospective focuses on improving the team’s quality and effectiveness. A review may change what the team works on; a retro may change how the team works.
Can we run an agile retrospective online?
Yes. Use a shared board, allow quiet writing before discussion, and make sure everyone can contribute. With Nextretro, you can start from a template and share the board link; participants can join without signing up. Keep the agreed experiment and its evidence visible for the next check-in.
Scrum definitions and timeboxes are based on the November 2020 Scrum Guide. The example, template recommendations, and agenda above are practical suggestions.
One improvement worth checking.
Start a shared retrospective board, hear from the whole team, and agree on what you will try next.