Sprint Retrospective
A dedicated session after the Sprint Review where the Scrum Team inspects its own process, identifies improvements, and creates a plan to implement them in the next sprint.
What it is
The Sprint Retrospective closes the sprint loop by focusing on the team's process, interactions, and tools rather than the product itself. The entire Scrum Team participates in a safe environment. The session examines what went well, what could be improved, and what specific actions the team will take going forward. The output should be one to two concrete, actionable improvements that the team commits to addressing in the next sprint.
When to use it
Hold the Sprint Retrospective after every Sprint Review and before the next Sprint Planning. This timing ensures the sprint is fresh in everyone's mind while leaving room to act on improvements immediately.
- Continuous improvement: Regular inspection prevents small issues from compounding into systemic problems.
- Psychological safety: A blameless forum builds trust and encourages honest feedback.
- Team ownership: The team controls its own process, reinforcing autonomy and accountability.
- Compounding efficiency: Each small improvement stacks, leading to significantly faster delivery over time.
Key concepts
Formats
Varying the format keeps retrospectives engaging and surfaces different types of insights:
- Start-Stop-Continue: Three columns for things to start doing, stop doing, and keep doing. Simple, fast, and effective for newer teams.
- Sailboat: Visual metaphor where wind propels the team forward, anchors hold it back, and rocks represent risks ahead. Good for identifying obstacles and future threats.
- Timeline: The team plots events across the sprint chronologically. Excellent for sprints with complex or emotional highs and lows.
Action Items
Every retrospective must produce concrete, trackable action items. Each action should have a single owner and a clear definition of done. Vague commitments like "communicate better" fail; specific tasks like "update the staging environment checklist before each deploy" succeed.
Psychological Safety
Retrospectives only work when people feel safe to speak honestly. The Scrum Master protects this environment by redirecting blame, ensuring equal airtime, and modelling vulnerability. What is said in the retrospective stays in the retrospective unless the team agrees otherwise.
The Prime Directive
Norm Kerth's Prime Directive states: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." Starting with this framing prevents blame and keeps the focus on systemic improvement.
Common pitfalls
- Canceling when "too busy": Skipping the retrospective signals that improvement is not a priority. This accelerates burnout and process decay.
- Complaint sessions without action: Venting feels good but adds no value. Every concern raised should lead to an experiment or action item.
- Scrum Master dominating: The Scrum Master facilitates; the team owns the content. If the Scrum Master is doing all the talking, the team is not inspecting its own process.
- Too many action items: Overloading the team with improvements guarantees follow-through failure and erodes trust in the ritual.
- Blaming individuals: Retrospectives inspect the system, not the person. Individual blame destroys psychological safety and guarantees silence next time.
NZ context
In New Zealand's smaller technology markets, team continuity tends to be high and relationships run deep. Retrospectives in this context build cumulative team intelligence that compounds over years, not months. The trust established in these sessions often carries across projects and organisations.
Failing to act on retrospective items is particularly damaging in NZ because word travels fast. Teams that ignore their own improvement plans develop reputations for being all talk, which makes recruitment and retention harder in tight talent markets. Conversely, teams known for genuine continuous improvement become employers of choice.
Career level guidance
| Level | Role during Sprint Retrospective |
|---|---|
| Junior | Participate openly, share what helped or hindered your work, and volunteer to own small, specific action items. |
| Senior | Model constructive feedback, challenge systemic issues rather than symptoms, and mentor juniors on how to frame improvement ideas effectively. |
| Test Lead | Facilitate or co-facilitate, ensure quality and testing concerns have airtime, and track action items through to completion in the next sprint. |
Industry Reality
- Most teams hold retrospectives inconsistently — they disappear when deadlines tighten, then get reinstated after a painful sprint. Senior practitioners protect the ritual precisely because skipping it during crunch is when you need it most.
- The format rarely matters as much as facilitation quality. Teams often rotate through Sailboat, Start-Stop-Continue, and timeline exercises without seeing improvement because the real skill is converting conversation into committed action items — not which sticky-note format you use.
- Action items are the most common failure point. Many teams produce a list, then open next retro to find nothing was done. Experienced practitioners limit retro actions to one or two, assign a single owner per item, and spend the first five minutes of every retro reviewing last sprint's commitments explicitly.
- Psychological safety is frequently assumed rather than built. In practice, junior team members stay quiet while seniors speak, and the Scrum Master mistakes absence of conflict for honest engagement. Real safety requires active effort: anonymous voting tools, round-robins, and a facilitator who calls out unequal airtime.
- In NZ tech teams, where org charts are flat and people wear many hats, retrospectives often blur into stakeholder venting sessions. Skilled facilitators keep external concerns in a parking lot and redirect the conversation to what the team itself can control within the next sprint.
Context guide
How the right level of Sprint Retrospective effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| Government agency digital transformation (e.g. CoverNZ, Benefits NZ, TransitNZ) with multi-year delivery programmes and high political visibility | Essential | Complex procurement and approval chains mean process friction compounds quickly; retrospectives are the only forum where delivery teams can surface and escalate blockers before they derail a quarter of work. |
| NZ fintech or insurtech team under tight Privacy Act 2020 and RBNZ compliance obligations with frequent regulatory change | Essential | Regulatory requirements change mid-sprint; retrospectives catch the testing and documentation process gaps before the next compliance audit rather than after. |
| Cross-functional product team at TeleNZ or Pacific Air integrating legacy mainframe systems with modern APIs | High | Integration failures often stem from unclear handoff protocols between old and new system teams; retrospectives surface these boundary issues while the sprint is still fresh. |
| Small Wellington or Auckland software consultancy (fewer than 20 staff) running multiple client engagements simultaneously | High | Staff context-switch between clients frequently; retrospectives keep each team's process coherent and prevent bad habits from one engagement contaminating another. |
| Stable internal product team with a well-established process, low staff turnover, and no significant changes to tooling or scope | Medium | Process is mature but complacency is a risk; a lighter retrospective format every second sprint may suffice, with a full session scheduled when a change event occurs. |
| Solo QA contractor embedded in a client team where you have no authority over process changes | Low | Participate constructively but invest energy in documenting your own observations privately; you cannot own action items in a team where you have no authority to drive follow-through. |
Trade-offs
What you gain and what you give up when you adopt Sprint Retrospective.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Creates a protected, recurring forum where the team can surface process problems without blame — building cumulative psychological safety over months. | Takes 60–90 minutes of the whole team's time every sprint, regardless of whether there is much to discuss — opportunity cost is real on small, constrained NZ teams. | A critical production incident demands an immediate post-mortem rather than waiting for the sprint cadence — run a targeted blameless incident review within 48 hours instead. |
| Generates team-owned process improvements that stick — because the team diagnosed the problem and chose the fix, adoption is far higher than top-down mandates from a programme manager. | Action items routinely fail if the team over-commits; a badly run retrospective can feel performative after a few sprints, breeding cynicism that is hard to reverse. | The team is in a genuine crisis (data breach, major outage) and needs immediate incident command, not a facilitated reflection — switch to incident management protocol and schedule the retrospective for after stabilisation. |
| Makes systemic issues visible before they escalate — a team retrospecting on test environment instability is far cheaper than discovering the same instability via an escaped defect in production. | Requires skilled facilitation to be effective; without it, sessions devolve into the loudest voices dominating or the same topics cycling without resolution. | The team has no authority to fix the problems they identify (e.g. a locked-down infrastructure controlled by a separate government department) — focus on escalation paths rather than retrospective action items the team cannot deliver. |
| Establishes a shared team history and vocabulary around improvement — over six months, a well-maintained retrospective log is the most accurate record of how the team's process evolved and why. | Highly dependent on team stability; high turnover (common in NZ contractor markets) means continuity is lost and retrospective value resets frequently with each new hire. | The project is a one-off engagement shorter than four sprints — a lightweight end-of-project review may be more appropriate than establishing a full retrospective cadence that the team won't sustain. |
Enterprise reality
How Sprint Retrospectives change when you have 200–300 developers across 10+ squads in a NZ enterprise.
- Action item tracking is automated via Jira or Azure DevOps — retrospective outcomes are linked directly to sprint backlog items and dashboarded at programme level, so programme managers can see completion rates across all squads without attending individual retros. At KiwiFirst Bank's digital transformation, squads that consistently closed fewer than 50% of retrospective actions were flagged for Agile coaching intervention rather than left to self-correct.
- Governance and compliance obligations shape what can be surfaced in a retro. Under the Privacy Act 2020 and NZISM (New Zealand Information Security Manual), security and data-handling deficiencies identified in retrospectives must be assessed to determine whether they constitute reportable incidents — a team cannot simply log "we accidentally exposed test data" as a retro action item and move on without notifying the privacy officer.
- Tooling at volume shifts from whiteboards and sticky notes to persistent async platforms — Confluence retrospective templates, Parabol, or custom Jira dashboards — because a facilitator cannot manage 12 simultaneous squads in the same tool without losing traceability. Cross-squad retrospective themes (shared CI/CD instability, environment contention, definition-of-done gaps) are surfaced in a monthly "retrospective of retrospectives" run at the release train level.
- Squad coordination becomes the dominant challenge. When 15 squads share a release branch, a retrospective action item like "improve our branching strategy" cannot be implemented by one squad alone — it requires an Architecture Decision Record, sign-off from the platform team, and a migration window that does not conflict with other squads' sprint cycles. Test leads at this scale need to distinguish between squad-owned actions (resolvable within one sprint) and platform-level changes (require a separate working group and a 6–8 week lead time).
◆ What I would do
Professional judgement — when to adopt Sprint Retrospective, when to adapt it, and what to watch for.
The bottom line: A Sprint Retrospective that consistently produces one completed action item per sprint — owned, time-boxed, and reviewed at the next retro — is worth more than ten sessions that generate elaborate improvement lists nobody acts on.
Best Practices
- ✓ Open every retrospective by reading last sprint's action items aloud and confirming done/not-done status before surfacing new topics.
- ✓ Set a clear time-box at the start (90 minutes for a two-week sprint) and visibly track remaining time — let the team decide whether to go over, not the facilitator.
- ✓ Use dot voting or thumbs to converge on the two or three themes worth discussing, rather than attempting to process every sticky note raised.
- ✓ Frame every action item with an owner, a clear definition of done, and a check-in point (typically mid-sprint) rather than leaving it until the next retro.
- ✓ Rotate facilitators every few sprints so the Scrum Master is not the only person who can run a healthy retrospective — this also develops facilitation skills across the team.
- ✓ Use anonymous input tools (FunRetro, Miro, EasyRetro) when trust is still being established or when the team has a vocal dominant member who influences others.
- ✓ Distinguish between complaints about things outside the team's control (escalate or park) and systemic issues the team can experiment on (act immediately).
- ✓ Keep a retrospective log — a simple shared doc tracking themes, decisions, and action items over time. Patterns across multiple sprints reveal deeper systemic issues that one-off retros miss.
Common Misconceptions
❌ Myth: The retrospective is the Scrum Master's meeting to run however they see fit.
Reality: The retrospective belongs to the team. The Scrum Master's role is to facilitate a safe environment, not to drive content, assign actions, or present their own agenda. A retrospective where the Scrum Master does most of the talking is a retrospective that is not working.
❌ Myth: If nothing major went wrong, you can skip the retrospective or keep it to 15 minutes.
Reality: Smooth sprints often contain the most valuable learning — understanding why things went well helps you replicate those conditions. Shortening or cancelling the retro when everything is "fine" teaches the team that the ritual is only for crisis management, not continuous improvement.
❌ Myth: Producing a long list of action items means a productive retrospective.
Reality: A long action list is a sign of an unfocused retrospective. Teams that commit to six or eight items typically complete zero. The most effective retrospectives produce one or two specific, owned, time-boxed improvements that are actually implemented before the next sprint ends.
Senior engineer insight
Teams that do retrospectives well treat the action items as first-class sprint work — they go on the board, get estimated, and are reviewed at stand-up just like any other task. What separates these teams from the ones who struggle is a single habit: opening every retro by reading last sprint's commitments aloud before a single new topic is raised. The pattern that reliably works is cutting the action list to one item, assigning it to a named person, and making "did we do the thing?" the first question next fortnight — not the last.
The most common mistake teams make: treating retrospective action items as aspirational notes-to-self rather than accountable commitments with an owner, a definition of done, and a check-in point.
From the field
A Wellington fintech team running two-week sprints assumed their retrospectives were working because the sessions felt productive — good conversation, plenty of sticky notes, everyone engaged. What they discovered after a quarter was that their retrospective log contained 34 action items, of which 3 had been completed. The team had conflated a good discussion with a good outcome. They reset by adopting a single rule: no new items until the previous sprint's item was closed, and each item had to be specific enough that anyone on the team could objectively say whether it was done. Within two sprints, their staging environment checklist — the one that had been causing missed defects for months — was finally updated and owned. The lesson that travels beyond that team: psychological safety gets you honest conversation; disciplined follow-through is what turns that conversation into improvement.
Why teams fail here
- Action items accumulate unfinished sprint after sprint because they are too vague, have no single owner, and are never reviewed until the next retro — by which point they feel stale and get silently dropped.
- The Scrum Master confuses absence of conflict with psychological safety — juniors stay quiet, one or two voices dominate, and the team never surfaces the real systemic issues.
- Retrospectives get cancelled during high-pressure sprints precisely when they are most needed — this teaches the team that continuous improvement is optional and erodes the habit permanently.
- Teams conflate identifying problems (easy) with running experiments that change how they work (hard) — sessions become a rotating cast of the same complaints with no causal investigation or time-boxed experiment to resolve them.
Key takeaway
A well-run Sprint Retrospective is not a feelings check-in or a complaints forum — it is the team's only structured mechanism to inspect and upgrade the system they work inside, and skipping it is the surest way to stay stuck in the same problems sprint after sprint.
How this has changed
The field moved. Here is how Sprint Retrospective evolved from its origins to current practice.
Scrum's Sprint Retrospective is present in early Scrum but often neglected. Teams under deadline pressure skip it or treat it as a formality.
Norm Kerth publishes "Project Retrospectives." Practices focusing on systemic improvements rather than blame become the foundation for effective retrospectives.
Esther Derby and Diana Larsen publish "Agile Retrospectives: Making Good Teams Great." The five-stage structure (Set the Stage, Gather Data, Generate Insights, Decide What to Do, Close) becomes the standard format.
Retrospective anti-patterns are documented — same action items repeated every sprint, team members afraid to speak candidly, focus on tooling rather than team dynamics. The facilitation discipline matures.
Async retrospective tools (Parabol, EasyRetro) enable distributed teams to contribute before and during the event. AI sentiment analysis identifies patterns across multiple retros. Human facilitation skill remains irreplaceable.
Self-Check
Click each question to reveal the answer.
Q: What is the primary purpose of the Sprint Retrospective, and how does it differ from the Sprint Review?
A: The Sprint Retrospective focuses on the team's process, tools, and interactions — how the team works. The Sprint Review focuses on the product — what was built and whether it meets stakeholder needs. Both happen at the end of a sprint, but the retrospective is internal to the Scrum Team whereas the review involves external stakeholders.
Q: What does Norm Kerth's Prime Directive say, and why is it read at the start of a retrospective?
A: The Prime Directive states that everyone did the best job they could given what they knew at the time. It is read at the start to establish a blameless mindset, preventing the session from becoming a blame exercise and keeping the focus on systemic improvement rather than individual fault.
Q: How many action items should a retrospective produce, and what must each one include?
A: One to two action items at most. Each must have a single named owner, a clear definition of done, and a check-in point — typically mid-sprint. Vague commitments like "communicate better" are insufficient; a specific task with an owner and a done-state is required.
Q: Name two retrospective formats and describe a situation where each would be appropriate.
A: Start-Stop-Continue works well for newer teams because it is fast and straightforward. The Sailboat format suits teams that want to surface risks and obstacles ahead, using the metaphor of wind (positives), anchors (blockers), and rocks (future risks). The Timeline format suits sprints with significant emotional or logistical highs and lows.
Q: What happens to team trust and process quality when retrospectives are consistently skipped during busy periods?
A: Skipping retrospectives when the team is under pressure signals that improvement is optional — exactly backwards, since crunch periods are when process breakdowns are most costly. Small issues compound unchecked, burnout accelerates, and the team loses the habit of continuous improvement. In tight NZ talent markets, this reputation makes retention and recruitment harder.
Q: Your team is midway through a six-month Benefits NZ benefits portal redevelopment. Three sprints in a row have produced retrospective action items that nobody completed. As test lead, what do you do?
A: Stop adding new action items until the backlog of incomplete ones is resolved. At the next retrospective, open by reviewing each outstanding item and asking honestly whether it is still worth doing — some may be stale. For the items that matter, investigate why completion failed: were items too vague, did no one feel accountable, or did sprint commitments leave no capacity? Reduce the commitment to one tightly scoped action with a single named owner and a mid-sprint check-in. In government delivery contexts like Benefits NZ, actions that require environment access or approval chains can stall; flag these for escalation rather than letting them quietly fail sprint after sprint.
Q: What is the key difference between a Sprint Retrospective and a post-incident review (also called a blameless post-mortem)?
A: A Sprint Retrospective is a regular, time-boxed ritual that inspects the team's process across the entire sprint — it covers both positive and negative observations and runs every sprint regardless of incidents. A post-incident review (post-mortem) is triggered by a specific production failure or outage and focuses deeply on the causal chain of that single event. Both share the blameless mindset and systemic focus, but retrospectives are proactive and periodic while post-mortems are reactive and event-driven.
Q: A developer on your team says, "We had a great sprint with no blockers, so I told the Scrum Master we can skip the retro this time." What is wrong with this reasoning and how do you respond?
A: Smooth sprints are the most valuable learning opportunity — they reveal what conditions enabled success so the team can replicate and protect them. Cancelling the retrospective teaches the team that the ritual is only for crisis management, not continuous improvement, and erodes the habit over time. The right response is to attend and spend the session codifying what went well: which practices, communication patterns, or tooling choices contributed to the outcome, and how to make those the default rather than the exception.
Q: An Revenue NZ tax-filing system team holds retrospectives but the same three complaints come up every sprint with no action taken. A senior developer argues retrospectives are pointless for them. How do you diagnose and fix the underlying problem?
A: Recurring complaints without action indicate one of three failure modes: items are outside the team's control (escalation needed, not retro action), items are too vague to act on (reframe as experiments), or the team has stopped believing action will follow (trust deficit). Start by categorising the recurring themes — government system constraints like Revenue NZ's integration dependencies may genuinely require escalation to product ownership. For systemic issues the team can influence, rewrite them as small, time-boxed experiments owned by one person. Track completion explicitly for two sprints. If the format has gone stale, rotate to a structured format like the Timeline to surface fresh angles. The developer's conclusion — that retrospectives are pointless — is a symptom of poorly run retrospectives, not an indictment of the practice itself.