Retrospective Generator

Where the retrospective came from

Teams looked back on their work long before software teams named it. The U.S. Army has used the after-action review, a structured look back at a task to reflect, discuss and set goals, for decades, and hospitals and airlines use the same idea under the name debrief¹.

The word "retrospective" comes from Norman Kerth's 2001 book Project Retrospectives: A Handbook for Team Reviews². Kerth also wrote the line that opens many retros today, known as the Prime Directive: "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"². It is often read as "no one is ever at fault." It says something narrower: judge past choices by what people knew then, not by what the team knows now.

The Agile Manifesto, also from 2001, made reflection a standing habit: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly"³. The Scrum Guide sets the purpose of the sprint retrospective as planning "ways to increase quality and effectiveness"⁴. Note the word plan. A retro is meant to end in a change, not a list of feelings.

How to run a retrospective well

Most templates online offer three columns: what went well, what to improve, and action items. Esther Derby and Diana Larsen, in Agile Retrospectives (2006), describe five stages instead⁵. The extra stages are where the value hides.

• Set the stage. State the goal of this retro and the time period it covers. Remind people of the Prime Directive.
• Gather data. Collect what happened before anyone explains it: dates, numbers, the timeline, how people felt at each point.
• Generate insights. Ask why. Look for the pattern behind two or three items, not a fix for each one.
• Decide what to do. Pick one to three changes, each with an owner and a way to tell whether it worked.
• Close. Agree when the team will check the changes, and ask how the retro itself could be better.

The three-column format skips the gathering and the "why." That is how the same complaint shows up sprint after sprint. The second edition, written with David Horowitz in 2024, keeps the five stages and adds advice for remote and hybrid teams⁶.

Bring evidence, not just memories. A 2021 review in the Journal of Applied Psychology by Nina Keiser and Winfred Arthur pooled 61 studies of after-action reviews. Reviews that used objective records of what happened, such as recordings or logs, worked better⁷. For a sprint, that means the board, the dates, and the bug counts, open on the screen.

A weak retro and a stronger one

This is the sprint example shown above, rewritten. The team and its numbers are invented for illustration.

The weak version names a symptom. The stronger version finds the cause, so the action fixes that cause instead of asking QA to work faster.

Common mistakes

• Too many actions. Eight action items means none get done. Keep one to three, and drop the rest on purpose.
• Actions with no owner or check. "Communicate better" cannot fail, so it cannot succeed either. Name who does it and what you will look at next time.
• Never looking back. Start each retro by checking last time's actions. If they keep slipping, that is the first thing to talk about.
• The loudest voice sets the story. Have people write their own notes in silence before anyone speaks.
• Blame, or the fear of it. In a 1999 study of 51 work teams in Administrative Science Quarterly, Amy Edmondson found that teams who felt safe to take interpersonal risks did more of the learning behavior, such as asking for help and talking about errors, that led to better performance⁸. If people hold back in the room, the retro only sees the safe problems.
• Same format every time. The questions can get stale. Change the data-gathering activity now and then; keep the five stages.

What a retro does and does not answer

The evidence that looking back pays off is strong. Scott Tannenbaum and Christopher Cerasoli, in a 2013 meta-analysis in Human Factors, combined 46 samples and found that debriefs improved performance by about 20 to 25 percent over groups that did not debrief¹. They also found that how a debrief is run matters: it works best when the people, the focus and the measure all line up, and facilitation and structure may help¹.

But a retro is built to improve how a team works. It is weaker at other questions:

• Whether the work was worth doing. A retro can make a sprint smoother without asking if the goal was right. That is a strategy question for a planning session, such as a leadership offsite.
• Problems outside the team. If the cause sits with another team or a budget, write it down as a request to the person who owns it, not as the team's own action.
• Choosing between big options. When the retro surfaces several possible changes that compete, a decision matrix helps weigh them.
• A serious failure. An outage or a lost customer deserves its own review with a fuller timeline, not ten minutes at the end of a sprint.

After the retro

Put the one to three actions where the team already tracks work, with the owner and the date next to each. The meeting action items tool can turn raw notes into that list. Then open the next retro by reading them out: done, not done, and what was learned. That habit is what turns a retro from a meeting into a loop.