Retrospective: How Teams Learn From Every Sprint

A retrospective is not a blame session. It is a recurring meeting in which a team looks back at a finished stretch of work and answers one question: how do we work better together, starting tomorrow? In Scrum it is called the sprint retrospective and closes every sprint. The word comes from the Latin retrospicere, to look back, but in a team the look back is only half the job. The other half is the one change that follows.

Three things decide whether a retrospective changes anything: a safe setting, a clear structure and no more than two action items with an owner and a date. All of it is shown on one team. Marcus, 41, is an engineering manager at a logistics software company in Columbus, Ohio. He leads six engineers who build a delivery tracking app in two-week sprints. Along the way you get the five phases, seven retrospective examples, a sentence template for action items and the three mistakes that quietly kill team retrospectives.

Retrospective Meaning: More Than a Look Back

As an adjective, retrospective means looking back at or dealing with past events. A retrospective analysis reviews what already happened. A retrospective law applies to events before it was passed, which is why lawyers often say retroactive instead. As a noun, the word has two common meanings. In the art world, a retrospective is an exhibition that surveys an artist's work across a whole career. At work, it is the team meeting this article is about.

Research uses the word in a third way. A retrospective study looks at data that already exists, such as medical records, and works backward from an outcome to earlier exposures. Its opposite is a prospective study, which follows people forward in time. The same pair fits teams well. The retrospective looks back, planning looks forward, and neither works without the other. Anyone who only plans repeats the same mistakes with a new date. Anyone who only looks back collects insights without consequences.

For the record, the adverb is spelled retrospectively, and common synonyms include review, lookback, reflection and hindsight. So why does a single word carry so much weight in agile teams? Because the Agile Manifesto of 2001 made it a principle. Its twelfth principle says that at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. In short: a retrospective is maintenance for the team, not for the product.

Norman Kerth gave the practice its name in his 2001 book Project Retrospectives. Before that, most teams held postmortems, a word borrowed from medicine that implies the project is already dead. Kerth wanted teams to learn while they were still working together. He also wrote down a basic stance that many teams still read aloud at the start of every session. More on that below.

Sprint Review vs. Retrospective: What Each One Is For

Half a dozen terms circle around looking back. None of them is wrong. Each one is built for something different. The only question is whether the format looks at the product or at the way people work together.

The review and the retrospective cause the most confusion. The Scrum Guide by Ken Schwaber and Jeff Sutherland, 2020 edition, separates them clearly. In the sprint review, the team and its stakeholders inspect what was built and decide what comes next. In the sprint retrospective, the team inspects how the last sprint went with regard to individuals, interactions, processes, tools and its definition of done. That means: the review asks what, the retrospective asks how.

The after action review comes from the US Army and runs on four questions: what was supposed to happen, what actually happened, why was there a difference, and what can we learn from it? Those four questions make a good emergency format when there is no time for a full session. For individuals there is a separate habit. If you want to look back at your own week alone, the ten-minute weekly review shows how. This article is about teams.

What Really Happens in Most Team Retrospectives

Most team retrospectives do not fail because of the format. They fail because nothing happens afterward. The team fills a board with sticky notes, has a lively discussion and walks out with a long list. Two weeks later, the same notes are back on the board.

Marcus knows this pattern well. In his first three retrospectives, the team collected 37 notes and agreed on 12 action items. Two got done. One complaint came up every single time: pull requests sat too long before anyone reviewed them. In the last sprint, the average wait was 2.4 days, and three of eleven planned stories rolled over into the next sprint. Everyone knew it. Nobody owned it.

Why do good ideas disappear so reliably? Three reasons show up almost every time:

• Too many action items. Whoever tries to change six things at once ends up changing none. The next sprint is already full of feature work before the retrospective is over.
• No owner, no date. “We should review faster” is a wish. An action item has a name, a date and a number you can check.
• No look back at the last look back. If the next session does not open with the status of the last action items, nobody notices they were dropped.

That means: you do not measure a retrospective by the number of sticky notes. You measure it by the one change that is visible two weeks later. Everything else is a good conversation, and good conversations matter, but they do not change a process.

How to Run an Agile Retrospective in Five Phases

Esther Derby and Diana Larsen described a five-phase structure in their 2006 book Agile Retrospectives, and it has held up in a very wide range of teams. The Scrum Guide sets the time box: at most three hours for a one-month sprint, usually shorter for shorter sprints. Marcus blocks 60 minutes on the second Thursday of every sprint at 2 p.m., right after the sprint review. Here is how he splits the hour:

1. 01

   Set the stage, 5 minutes

   Welcome the team, name the goal and the agenda, and read the Prime Directive. Then run a quick check-in where everyone describes the sprint in one word. Marcus heard “slow,” “noisy” and two times “fine.” Those four words already show where the conversation is headed.

2. 02

   Gather data, 15 minutes

   Start with last time's action items: done, partly done or not done? Then everyone writes events and observations on notes in silence. Numbers help. Marcus brings a chart of review wait times per pull request. The average was 2.4 days, and the longest wait was five.

3. 03

   Generate insights, 20 minutes

   The team clusters the notes and uses dot voting to pick the two topics that matter most. Then it asks about causes, not culprits. For Marcus's team, the finding was simple. Reviews were slow not because people were lazy, but because nobody had time set aside for them, so every review interrupted something else.

4. 04

   Decide what to do, 15 minutes

   Turn the insights into two action items at most, each with an owner, a date and a measure. Marcus's team chose only one: every pull request gets a reviewer within 24 hours, and the team holds a 30-minute review slot at 11 a.m. every day. Tomás owns it, and the measure is the average review wait in the next sprint.

5. 05

   Close the retrospective, 5 minutes

   Repeat the action item and ask what would make the retrospective itself better. A short round is enough: what are you taking with you, and what would you change about the format? Whoever closes this way improves two things at once, the team and the meeting.

The Prime Directive: why nobody is on trial

Norman Kerth wrote a short statement for retrospectives that became known as the Prime Directive. In essence, it says: whatever we discover, we 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 sounds like politeness. It is actually a working method.

Anyone who looks for someone to blame gets defensiveness instead of information. Anyone who looks for conditions finds out what really happened. In a 1999 study of 51 work teams at a manufacturing company, Amy Edmondson showed that teams learn more from mistakes when members feel safe to speak up about problems. She called this psychological safety. For a retrospective, that means two rules: what is said in the room stays in the room, and the manager speaks last.

How long and how often

The Scrum Guide time box leads to a common rule of thumb: about 45 minutes of retrospective per week of sprint. For two weeks that is 60 to 90 minutes, for a month up to three hours. Teams without sprints pick a fixed rhythm, such as every other week or once a month. Regularity matters more than length. A retrospective that gets canceled whenever things are busy disappears exactly when it would help most.

Ad

Prosp

Prosp · LinkedIn outreach

LinkedIn outreach that gets repliesPersonal messages plus AI voice notes in your own voiceEvery reply in one inbox

Try for free→

New reply

Hi Anna, your post on remote sales got me curious.

Sounds interesting. Does Thursday work?

Retrospective Examples: Seven Formats and When to Use Them

The format is the tool for phases two and three. It gives structure to gathering data and keeps every session from sounding the same. Switching formats every two or three sprints keeps the conversation fresh, while the five phases stay the same. These seven retrospective examples cover most situations:

There is no single best format. Whoever is just starting does well with Start, Stop, Continue, because the three questions need no explanation. A team with ten retrospectives behind it usually needs finer grids. Two of them deserve a closer look.

The Starfish retrospective: five areas instead of three

The Starfish retrospective is usually credited to Patrick Kua. It divides a board into five areas like the arms of a starfish: more of, less of, start doing, stop doing and keep doing. The gain over Start, Stop, Continue lies in the areas in between. Not everything has to go away or be brand new. Much of it just needs a different dose.

Marcus tried the Starfish in the fifth sprint. Under “more of,” the team put short pairing sessions on tricky code. Under “less of,” the Monday status meeting that had grown to 45 minutes. Under “stop doing,” the team wrote pull requests over 400 lines, which nobody could review in one sitting. That note produced the sprint's only action item, because it explained why some reviews still took two days.

The Sailboat: when the team has a goal

In the Sailboat, the team draws a boat heading for an island. The island is the team's goal. The wind stands for what pushes the team forward, the anchors for what holds it back and the rocks for risks ahead. The idea goes back to the Speed Boat game in Luke Hohmann's 2006 book Innovation Games, which was originally designed for conversations with customers. The format is strongest when the team shares a quarterly goal. Then the island becomes a number, and every discussion has a yardstick.

Action Items That Stick: From Sticky Note to Next Sprint

A good action item is small enough for the next sprint and specific enough that someone can start on Monday. One sentence template with four parts is all you need: Starting [date], [person or team] will [behavior], checked at the next retrospective by [measure]. Here is what typical results look like before and after:

Whoever writes action items this way notices right away when one is too big. If the measure cannot be observed within two weeks, the item is a project and belongs in planning. That is not a flaw in the template. It is a sign the topic needs a different level.

For Marcus, the review slot worked. In sprint six, the average review wait dropped from 2.4 days to 0.9, and only one story rolled over. At the next retrospective, the team looked at that number first, for two minutes, and then moved on. In short: an action item is only done once its effect has been checked at the next session.

Team Retrospectives Outside Software

The agile retrospective comes from software development, but it does not need sprints. Any team that works together on a recurring basis can use it. Whoever has no sprint simply picks a fixed period and looks back at the end of it. Four examples show how different that can look:

• Customer support. A team of five looks once a month at the three tickets that took longest to resolve. One question is enough: what would have saved a day on each of them?
• Event or project wrap-up. A week after a trade show, the team meets for 90 minutes with a timeline from the first planning call to teardown. The result is a checklist for the next show.
• Nonprofit board. A youth soccer league board spends 60 minutes on Start, Stop, Continue after each season. The one action item goes on the agenda of the next board meeting.
• Family. A couple with two kids spends ten minutes on Sunday night on the week: what went well, what was too much, what do we change? It is a retrospective in miniature, even if nobody calls it that.

The form adapts, the logic stays the same: a fixed date, a safe setting, one change. Is agile just a label, then? Not at all. It shows up exactly here, in the willingness to check your own way of working on a regular schedule. A team that does this without Scrum is often more agile than one that ticks off every Scrum event out of duty.

The Three Mistakes Nobody Notices

Team retrospectives rarely end with a bang. They slowly turn into a chore. Three patterns are especially common, and none of them stands out in day-to-day work.

Mistake 1: The manager speaks first

A manager who shares their view first sets the frame for everyone else. After that, hardly anyone disagrees. Marcus changed this. He writes his notes in silence like everyone else and reads them out last. When things are tense, an outside facilitator helps, for example a manager from another team.

Mistake 2: It is about people, not process

“Sam forgot to review my pull request” leads to a defense. “Reviews have no time set aside” leads to a solution. The retrospective is built for processes. If the issue really is one person's behavior, the conversation belongs in a private meeting. The guide on how to give feedback to employees shows how to run it.

Mistake 3: Every retrospective starts from zero

Without a look at the last action items, every session is a fresh start. The team discusses the same topics, agrees on similar things and forgets them again. The fix takes two minutes: the first slide of every retrospective shows the last action items and their status. Whoever introduces this sees within three sprints whether the format works.

Retrospectives in the Goal Chain: From Year to Day

A retrospective improves how a team works. Goals decide what it works on. The two belong together, because an action item is only as good as the goal it serves. That is why Marcus hangs the results of his retrospectives on the same chain his team uses for planning: from the year to the quarter, the month, the week and the day. How a team sets shared goals in the first place is covered in team goals.

Every level has its own look back, and the time grows with the period. This is what Marcus's chain looked like in the second quarter:

• Year 2027: ship 90 percent of planned stories within their sprint, up from 72 percent.
• Quarter 2: review wait under one day for every pull request, plus a three-hour quarterly retrospective with the whole team.
• Month of May: no more than one carried-over story per sprint, with a 30-minute monthly look back.
• Week: sprint retrospective every other week, 60 minutes, one action item.
• Day: Tomás reviews two open pull requests in the 11 a.m. slot on Tuesday.

The quarterly retrospective matters most. It looks at six sprints, not one. It asks whether all the small action items moved the quarterly goal, and it feeds directly into quarterly planning. That means: the sprint retrospective corrects the course, the quarterly retrospective checks whether the course is right.

Your Self-Audit Before the Next Retrospective

Before you schedule the next retrospective, answer five questions. Every question that makes you hesitate points to a gap in the format:

1. 01Do you know what happened to the action items from the last retrospective?
2. 02Does every open action item have an owner, a date and a measure?
3. 03Would the quietest person on your team say what really bothers them?
4. 04Are the next three retrospectives already on the calendar?
5. 05Can you name one change that would not exist without your team retrospectives?

After the sixth sprint, Marcus could answer yes to all five. After the third, it was two. The difference was not a new format. It was two rules: two action items at most, and a look at the last ones right at the start. In short: a retrospective is not a ritual for looking back. It is the smallest tool a team has for changing itself.

Frequently Asked Questions About Retrospectives