Retrospectives

Introduction#

The retrospective is a regular session where the team reflects on what is going well and should be kept, what is not going well and should change, and what the team is actually going to do about it. Its primary focus is to drive continuous improvement, but it is also a chance to step away from the day-to-day work, think in different ways, and enjoy some time together as a team.

This page explains how to run one: holding it every two weeks without fail, keeping it to the team, getting everyone in the same room where possible, making it safe, flat, and enjoyable, using a consistent structure with varied formats, and, most importantly, turning the discussion into change that actually happens.

Scrum calls this the Sprint Retrospective ↗, but the practice is older than Scrum and works just as well for teams that don’t use sprints. This page uses retrospective, or retro for short.

What a retrospective is for#

A retrospective has three jobs:

Celebrate what is going well, so that it is recognised, the people involved are appreciated, and the team deliberately keeps doing it.
Surface what is not going well, while it is still small and cheap to fix.
Do something about it, by agreeing specific changes and following them through.

Done well, it also builds team cohesion. Working through shared problems together, and seeing them get solved, gives a team a sense of collective ownership and autonomy. So does simply spending an hour together in a different mode from usual: sharing what matters to each person and thinking creatively together about how to make things better.

Retrospectives that don’t drive useful change go wrong quickly, becoming venting sessions where the same complaints are aired every fortnight, or a ritual that people attend only because it is in the diary.

Credibility comes from the actions

A team’s willingness to raise real problems in the retrospective depends on whether raising them has led to anything in the past. The quickest way to improve a struggling retro is usually to get one or two previous actions genuinely done.

Every two weeks, without fail#

Hold the retrospective every two weeks, at the same time, as a recurring slot in the diary. For teams working in sprints, this is usually at the end of each sprint, after the sprint review. For teams that don’t use sprints, simply pick a fortnightly slot and stick to it.

It happens without fail. If it lands on a bank holiday or an unavoidable clash, move it, but don’t drop it. In particular, don’t skip it because the team is busy or under pressure: that is exactly when the process is most likely to need support to stop it faltering.

Why?

Issues stay small and fresh. A two-week gap is short enough that people remember the specifics of what happened, and problems are raised before they have grown or hardened into “the way things are.”
Raising problems becomes routine. When there is always a retro coming up soon, people don’t need to decide whether something is serious enough to make a fuss about. They just bring it along.
Change stays incremental. Frequent small adjustments are easier to make, easier to reverse, and easier to evaluate than occasional large overhauls.
Skipping sends a message. Cancelling the retro to make room for “real work” tells the team that improving how it works is optional, and they will treat it that way.

Who attends#

The whole delivery team attends, including the Product Owner and anyone else who works day to day as part of the team. The test is whether they are affected by the team’s ways of working and able to change them.

Nobody from outside the team attends unless the team invites them in, and that should be for a specific reason, such as a focused retrospective on an incident that involved another team, and usually for a specific part of the session rather than the whole thing.

This is stricter than the daily meeting, where others are welcome to listen. The retrospective is closed by default because it only works if people can speak openly, and the presence of a manager, stakeholder, or observer from outside the team restricts what people are willing to say.

In the same room#

Retrospectives work best when everyone is physically together. Discussion flows more naturally, it is easier to read how people are feeling, quieter voices are easier to draw in, and the informal conversation before and after the session is part of what helps a team gel. Sticky notes on a wall and a real whiteboard also bring an energy that a digital board struggles to match.

For hybrid teams, schedule the retrospective on a day when everyone is in the office. It is often worth making it the anchor for that day, perhaps followed by lunch together.

If the whole team can’t be together, make the session remote-friendly. Everyone joins on their own device with cameras on, including those in the room, and the team uses a virtual whiteboard rather than sticky notes. Those who can be together should still sit in the same room.

A safe space#

The retrospective must be a safe space: people need to be able to say what is really going on without worrying about blame or consequences.

Focus on the system, not the people. Problems are almost always the product of process, priorities, tooling, or lack of information, rather than someone’s personal failings. The question is “what made that likely to happen?”, not “who did that?”
Assume good intent. Everyone was doing the best they could with what they knew and the situation they were in at the time.
What is said in the room stays in the room, unless the team agrees to take something further.
The facilitator protects the space. If the discussion turns into blaming an individual, the facilitator steers it back to what the team can change.
Senior people speak later. The team lead or most senior person present should hold back their views until others have had a chance to speak, so they don’t set the direction for everyone else.

Norm Kerth’s Prime Directive, from his book Project Retrospectives, captures the assumption of good intent well. Some teams read it aloud at the start of every retrospective as a reminder of the spirit of the session.

Norm Kerth’s 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.

But safety isn’t created simply by declaring it. It is built over time by how the team, and especially its lead, responds when someone raises something difficult. If trust is low, start by gathering input anonymously, for example using a digital retro board with anonymous cards, and move away from this as confidence grows.

A flat meeting#

The retrospective belongs to the whole team, and should feel like it.

Everyone contributes. The format should make this easy, especially for quieter people. Writing ideas down silently before discussing them is a simple and effective way to ensure everyone’s input is heard, not just that of the people most comfortable speaking up.
Facilitation rotates, in the same way as for the daily meeting, with the next facilitator chosen at random at the end of the previous retro so they have two weeks to prepare.
The team lead is a participant, not the chair. When someone else is facilitating, they follow their lead.

Facilitating a retrospective is a bigger job than facilitating the daily meeting. The facilitator chooses the format, prepares the board, keeps to the timeboxes, keeps the discussion safe and on track, and makes sure the session ends with clear actions. That makes rotation more valuable here, not less: it builds facilitation skills across the team, gives everyone a stake in how the retro goes, and brings a variety of styles and formats that keeps the session fresh.

The facilitator is still a member of the team, so they add their own ideas and votes like everyone else. They should take care not to steer the discussion towards their own topics, though.

Make it enjoyable#

The retrospective has a serious purpose, but it shouldn’t feel like a serious meeting. It is one of the few times in the fortnight when the team steps away from the backlog and thinks about how they work rather than what they are working on. A lighter, more playful session makes that shift easier.

Fun isn’t a distraction from the purpose, it supports it. People who are relaxed and engaged think more creatively, contribute more freely, and are more willing to raise difficult things. A playful metaphor, such as the anchors and rocks of the Sailboat format, often makes it easier to talk about a problem than a direct question would.

Some ways to bring energy to the session:

Start with a quick warm-up, as described in the Warm up.
Get creative with formats. Themed boards, drawings, metaphors, and games all work. Facilitators are encouraged to invent their own.
Bring food. Biscuits, cake, or a team lunch afterwards costs little and changes the feel of the session.
Change the setting occasionally. A different room, or somewhere outside the office, can shake up the usual patterns of discussion.

Read the room, though. After a difficult sprint, a major incident, or bad news for the team, forced jollity will grate. The aim is a session people look forward to, not one where fun is mandatory.

Structure#

An hour is usually about right. Less than that tends to squeeze out the discussion, which is where the value lies. Much more than that is hard to sustain, and usually means the team is trying to cover too much at once.

Use a consistent structure, so that everyone knows the shape of the session even when the format varies. Each part is described in more detail in its own section.

Step	Time	Purpose
Warm up	5 minutes	Switch out of day-to-day mode and get everyone talking.
Review previous actions	5 to 10 minutes	Check what happened with last time’s actions and ways-of-working changes.
Surface ideas	10 minutes	Everyone captures what is going well and what isn’t, in the format chosen for this particular retro.
Dot vote	5 minutes	Democratically prioritise the topics for discussion.
Discuss	25 minutes	Work down the voted list, understanding causes and agreeing actions as you go.
Confirm actions	5 minutes	Read back each action and change, with its owner.

Warm up#

Start with a quick, light activity that gets everyone saying something early. People who have spoken once are much more likely to speak again, and it helps the team shift from thinking about the work itself to thinking about how they work as a team.

Keep it short and low-stakes. For example:

One word. Everyone describes the last fortnight in a single word.
Weather report. Was the fortnight sunny, cloudy, stormy, or something else?
A light question. Something unrelated to work, such as “What’s the best thing you ate this week?”

Review previous actions#

Start by going through the actions and ways-of-working changes agreed last time. For each one: was it done, or is it being followed? Did it help? Does anything need to change? Are we ready to close it?

Keep this brisk. The point is accountability and learning, not a detailed report. An action that hasn’t been done should prompt a short, honest question about why, rather than a round of justifications. Don’t hold onto actions if they are no longer felt to be adding value. The aim is to keep a small list of actions that are genuinely important and will drive change.

Surface ideas#

Memories of the last two weeks are useful but selective. It helps if the facilitator brings a few relevant facts to ground the discussion, such as whether the sprint goal was met, cycle time, how often a stage exceeded its WIP limit, or the number of defects found after release. Keep it brief: a handful of numbers or a single chart is enough to prompt thinking, and this is not a performance review.

Everyone captures their thoughts individually and silently, on sticky notes or a shared digital board, using whatever format the facilitator has chosen (see Varying the format). At the end of the timebox, the facilitator groups similar ones together before voting.

Make sure this includes what is going well. Celebrating successes is one of the three jobs of the retro, and it’s easily crowded out by the more urgent-feeling problems.

Dot vote#

Each person gets a small number of votes, typically three to five, to place on the topics they most want to discuss. They can put their votes on any topic, including ones they raised, and can put more than one vote on a single topic if they feel strongly about it. The facilitator then orders the topics by number of votes.

Voting keeps the discussion focused on what matters most to the team as a whole, rather than what matters most to whoever speaks first or loudest.

Discuss#

Work through the topics in vote order, in the style of Lean Coffee ↗:

Take the top topic and discuss it for a fixed slot, typically five to eight minutes.
When the timer goes, the person speaking finishes their sentence and stops speaking. Everyone votes with a thumb: up to keep discussing this topic, sideways for neutral, down to move on to the next topic.
If the majority want to continue, add a shorter extension, usually once. Otherwise, move on to the next topic.

The aim of each discussion is to reach an action or a change to the way the team works, or a conscious decision that no change is needed. Before agreeing a fix, check that you understand why the problem happened, so that the action addresses the cause rather than a symptom. Don’t expect to cover every topic. Anything not reached can be raised again next time if it still matters.

Confirm actions#

Finish by reading back every agreed action and ways-of-working change, with its owner, so that everyone leaves with the same understanding of what will happen. Then spin a wheel to choose the next facilitator, for example using Wheel of Names ↗.

Varying the format#

The structure stays the same, but vary the format used to surface ideas. Asking the same question every fortnight produces the same kind of answers, and the retro goes stale. A different prompt encourages people to think about the last two weeks from a different angle.

Choosing the format is part of the facilitator’s role, and one of the more enjoyable parts of it. Facilitators are free to adapt existing formats or invent their own, and a bit of creativity here helps to keep the session lively.

Some popular formats

Start, Stop, Continue. What should we start doing, stop doing, and keep doing? Simple and action-oriented, and a good default.
Mad, Sad, Glad. What frustrated us, what disappointed us, and what pleased us? Good for surfacing how people feel, not just what happened.
Sailboat. The team is a boat sailing towards an island (its goal). What is the wind pushing us along, what are the anchors holding us back, and what are the rocks ahead that might sink us? Good for looking at risks as well as recent events.
4Ls. What did we like, learn, lack, and long for? Good for encouraging reflection on learning.
Starfish. What should we keep doing, do more of, do less of, start, and stop? A more nuanced version of Start, Stop, Continue.
Timeline. The team builds a timeline of the period together, then marks the high and low points. Good for focused retrospectives on a longer piece of work.

Many more can be found on sites such as Retromat ↗, which also suggests activities for other parts of the session.

Scope#

The focus is primarily on what has happened since the last retrospective. This keeps the discussion concrete and grounded in specific events that everyone remembers.

That doesn’t mean older issues are off limits. Some problems build up gradually, or only become worth raising once they have happened several times. Long-standing issues are fair game, and can be the most valuable ones to tackle.

The retrospective is also where issues flagged elsewhere in the team’s process are brought for discussion, such as ad-hoc work quietly consuming the team’s capacity (see Daily meeting](./daily-meeting.md#the-work-must-be-visible)), frequent large discrepancies between estimates and reality (see Story points), or a stage that is persistently over its WIP limit.

It can be valuable to occasionally run a retrospective with a specific focus rather than a general catch-all. Good candidates include a major release, a significant incident, a big customer event, or the end of a larger piece of work. A focused retro uses the same structure, but the prompt for surfacing ideas is about that one thing.

Example: focused retrospective on a release

The team has just shipped a major release that involved a two-week code freeze, a late-night deployment, and a rollback of one component. Rather than a general retro, the facilitator builds a timeline of the release on the board, from the start of the freeze to the day after deployment, and asks everyone to add the events they remember and mark how they felt at each point.

The dot vote picks out the rollback and the length of the freeze as the topics to discuss. The team agrees two actions: add an automated smoke test for the component that was rolled back, and try shortening the freeze to one week for the next release, reviewing the result in the retrospective that follows it.

Turning discussion into change#

Retrospectives prove their value through the improvements they drive.

Two types of improvement#

The retro produces two different kinds of change, and they are handled differently.

Changes to the way the team works. For example: “We will prioritise reviewing pull requests over working on items in development.” These are ongoing agreements rather than tasks, and are usually owned by the whole team. Record them somewhere visible, such as the team’s working agreement, and check them during the working week, for example as part of walking the board in the daily meeting.

Distinct actions. For example: “Add a pull request template with a checklist for the definition of done.” These are one-off pieces of work. Each one goes on the board, like any other work item, with an owner and an estimate, and is prioritised alongside the team’s other work so that it actually gets capacity.

Both types are reviewed at the start of the next retrospective.

Make actions specific enough that everyone would agree whether they have been done:

Avoid	Better
Improve communication with the support team.	Post a summary of each production deployment in the support team’s channel.
Do more pairing.	Use pairing for any item estimated at 5 points or more.
Better testing.	Add automated contract tests for the payments API.

Shared responsibility#

The retrospective is not a way of creating a to-do list for the team lead. Everyone contributes to making improvements happen, and actions should be spread across the team. Taking ownership of an improvement is one of the best ways for team members to develop, and a team that improves its own process is more committed to the result.

But some changes are outside the team’s authority, such as a change to another team’s process, a budget decision, or an organisational policy. These are usually best owned by the team lead, who is typically better placed to negotiate with the people who can make the change. The lead reports back on progress at the next retrospective, like any other owner.

Don’t let actions accumulate#

Keep the number of new actions small, typically five or fewer per retrospective. A few actions that get done are worth far more than a long list that doesn’t.

If actions from previous retros are still outstanding, focus on getting those done before adding more, or decide to bin some of the older ones in favour of new ones. Don’t just let the list keep getting longer. A growing backlog of retro actions is a sign that the team is either taking on too much, or not making time for improvement work, or agreeing actions that nobody really believes in.

Keep a record#

Keep the output of each retrospective somewhere only the team can see it: the digital board, a restricted page on the team’s wiki, or simply photos of the wall. It doesn’t need to be sanitised: it’s a record of what happened as it happened.

Looking back over a few months of retros shows which issues keep coming back despite the actions taken. A recurring theme is a sign that the actions so far have treated symptoms rather than causes, and it is a good candidate for a focused retrospective.

Starting out#

A team’s first few retrospectives set expectations for all the ones that follow, so it is worth taking care over them. The same applies to a team whose previous retros have lost credibility.

Keep the format simple. Start, Stop, Continue is a good choice. Save the more creative formats until the team is comfortable with the structure.
Put extra emphasis on safety. Gather input anonymously, and consider reading the Prime Directive aloud.
Have an experienced facilitator for the first few sessions. This could be the team lead, a coach, or someone from another team. Start rotating once the team has seen a few retrospectives run well.
Get an early win. Agree one or two small, achievable actions, and make sure they are done by the next retro. Nothing builds confidence in the process faster.

Checking the retrospective is worth it#

From time to time, ask the team to rate how valuable the retrospective was, using a quick “fist of five” show of fingers from one (“not worth the time”) to five (“well worth the time”). Anyone who gives a low score is invited, but not obliged, to say what would have made it better.

Don’t do this every time. Asked every fortnight, it becomes a reflex and the answers stop meaning anything. It is most useful occasionally, when the facilitator wants feedback on a new format, or when the retro feels like it may be losing its energy.

Key points#

The retrospective’s purpose is to celebrate what is going well, surface what is not, and do something about it.
Hold it every two weeks without fail, especially when the team is busy.
The whole delivery team attends, including the Product Owner. Others attend only when invited, for a specific reason.
It must be a safe space, focused on the system rather than individuals.
Get together in person where possible. If anyone is remote, everyone joins on their own device and uses a shared virtual board.
Make it enjoyable. Fun supports the purpose by helping people relax, think creatively, and speak openly.
It is a flat meeting: everyone contributes, facilitation rotates, and the team lead is a participant.
An hour is usually right, with a consistent structure: warm up, review previous actions, surface ideas, dot vote, discuss in Lean Coffee style, and confirm actions.
Ground the discussion with a few relevant facts, and understand why a problem happened before agreeing how to fix it.
Keep a record of each retrospective, and treat recurring themes as a sign that the root cause hasn’t been addressed.
Vary the format used to surface ideas, to keep the session fresh.
Focus mainly on the last two weeks, but raise long-standing issues too, and use focused retrospectives where that is more useful.
Changes to ways of working are owned by the whole team and checked during the week. Distinct actions go on the board with an owner and an estimate.
Everyone owns improvement actions. The team lead takes on the ones outside the team’s authority.
Keep actions few and get them done. A retrospective that doesn’t lead to change quickly loses its value.

Mistakes to avoid

Skipping it when the team is busy. That is when it is most needed.
Actions that never get done. Nothing undermines a retrospective faster than raising the same issue fortnight after fortnight with nothing changing.
A to-do list for the team lead. If every action lands on one person, the team has handed over ownership of its process.
Vague actions. “Improve communication” can’t be done, so it won’t be.
Inviting observers by default. People say less when someone from outside the team is listening.
Blaming individuals. Focus on what made the problem likely, not on who was involved.
The same format every time. The session goes stale and the answers become predictable.
Only discussing problems. Leaving out what is going well makes the retro a chore and misses the chance to reinforce good practice.
Discussion without decisions. Every topic discussed should end with an action, a change, or a conscious decision to leave things as they are.
A solemn ritual. If the retro feels like a chore, people disengage and contribute the minimum.
Leaving remote participants on the sidelines. People dialling in to a group gathered round one laptop become observers. Put everyone on their own device and use a shared virtual board.