Sprint Retrospective — Agile Techniques Library

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.

Time-box: For a two-week sprint, the retrospective is time-boxed to 1.5 hours. Shorter sprints require proportionally less time.

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.

Tip: If a sprint was unusually smooth, use the retrospective to understand why and codify those conditions rather than skipping the session.

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.

Limit actions: The team should commit to no more than one or two action items. Too many actions dilute focus and guarantee none are completed.

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.

Tip: Review last sprint's action items at the start of each retrospective. If actions are consistently incomplete, the team is either choosing too many or actions are not realistic.

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.