Skip to main content

How we do a retrospective

I consider the retrospective to be the most underrated meeting in the Scrum Flow. Since it is not about the concrete results of the project, there is a certain temptation to ignore it. It is easy to fall in to the trap that "there is always something more important to do."

Still, each Sprint should produce two results: 1) A product or service which is an increment of functionality closer to delivery and 2) a better, happier, more productive team. The retrospective is the primary opportunity for achieving the second result.

There are many ways to do a retrospective. Variety is the spice of life, and few areas are in need of more spice than a retrospective. So feel free to vary your approach, the questions, the focus, the location, the moderation, etc to keep the energy level up. The retrospective format described below takes about 2 to 3 hours, depending on the size of the team and your timeboxing. I like to use this format when getting started. It is also suitable for reflecting on a longer time-frame, e.g. a quarterly release or for reflecting over organizational boundaries.

A retrospective should identify and prioritize actionable suggestions to improve performance. As moderator of a retrospective, my goal is to get everyone to contribute to the discussion. I seek to channel discussion and debate to the proper moment, but also to prevent un-constructive discussions. I usually go through the following steps:
  1. Establish safety
  2. Identify the facts
  3. Identify the team's strengths
  4. Collect ideas for improvement
  5. Consolidate and prioritize the ideas.
Establish safety

Why establish safety? Very simple, so that people can talk freely about what happened and what could be better, without fear of consequence. If people are afraid of the consequences, they will be unwilling to talk about substance.

Sometimes it can be helpful to talk about the retrospective prime directive. I have also asked each team member to introduce him or herself and answer some questions about the story of their lives. And sometimes it is even useful to have a secret vote on how secure people feel about talking about their situation.

For the remainder of the retrospective, the following pattern is an easy way to get everyone to think about the question at hand, communicate their most essential points, and listen to what the other people have to say.
  • individual reflection - each person, thinking for themselves, writes down their points on sticky notes (one idea per sticky note!), then posts them to a common area on the wall. I usually time-box this to 2 or 3 minutes and encourage everyone to write down at least 5 points.
  • presentation - each person presents to the group what they wrote down. (I strictly time box this part to 2 minutes per person). Clarifying questions are allowed. Debate is not. No-one has to defend themselves while presenting their facts or ideas.
  • group discussion/debriefing - after everyone has presented, then I let the group discuss what they have heard. This is also my opportunity to ask illuminating questions about the topic.
So each of the following points goes through the same scheme of reflect - present - discuss.

Identify the facts

Here I ask the team 'what happened?' This is about facts and events, not opinions or judgements. The idea is to build a common understanding of what happened and what was important during the period. If this is a sprint retrospective, then then time frame is simply the sprint. Sometimes a team will want to reflect over a longer time period, say 3 months.

I like to draw a time line on a flip chart in landscape format, then I draw a :-) and a :-( on the y-axis. Just as the people are about to put their stickies on the wall, I ask them to position the sticky horizontally in time and vertically by how it moved them (happy or sad). The resulting distribution paints a surprisingly clear picture of the team's emotional state. (BTW - I discourage the team from thinking about high and low points while they are writing - that's already focusing in, which is contrary to the objective of this step, i.e. is to open up and let the information flow).

On debriefing, I first ask if the team has forgotten anything important. Then I continue with a very open question to start the discussion ('OK guys, what do think?' or 'How do you feel about what you see?') Often different participants will have brought up complementary or even contradictory perspectives on the same event which are worth illuminating in more detail. (My favorite example: Sales: 'I asked development for estimates but, as usual, they didn't have time. So I had to estimate the project myself.' Development: 'We got yet another project from Sales which had been estimated without our knowledge or participation.').

Identify the team's strengths

I do not ask the team what it does badly. I think this gets people focused on the negative which is not helpful to improvement. I much prefer the positive formulation: 'what do we do well'?  I like to ask this question for two reasons. 1) It gives the team a chance to pat itself on the shoulder -- and it may need the opportunity if the results of the previous step were too 'bottom heavy'. 2) I can see how well the team is functioning as a team.

Sometimes, after the team has presented its tickets, I ask the people 'what should be on the list, but is not'. I don't ask them to produce tickets, but just think about the issues.

If the team is performing at a high level, I would expect to hear them talk about craftsmanship, conflict and attention to results:
  1. Craftsmanship. A software team should be good a building software and master many of the modern engineering practices. So I would like to hear about their continuous integration server, their test processes, their pairing, their source code control, etc. If they are doing good engineering, they should be able to talk about it.
  2. Conflict. A well functioning team should be able to argue passionately about the subject matter, make decisions, commit and move forward. I like to hear evidence that the team is able to work effectively as a team. For instance: 'It is the power of the argument, not the positional power which determines the winning argument.'
  3. Attention to Results - The team should be producing something which  a customer wants. So I would expect to hear about releases, communication with the customer or feedback from the user. In particular, the quality of requirements being presented to the team for implementation.
Obviously, if anything is missing, I will ask the team about the current situation: "I would have expected a top team to be proud of the their approach to testing. I don't see anything about testing. How do you handle testing....?'

Collect ideas for improvement

The last question for the team is, 'What could we do better?' The objective is identify concrete improvement potential which the team could start working on tomorrow. Ideally the team has been well primed based on the previous discussion to come up with good ideas.

Consolidate and prioritize the ideas.

This approach produces many ideas. Too many, to implement all of them. Many will be duplicates or multiple suggestions to address a more fundamental problem. So after all the ideas have been presented, you need to create some order from the chaos. The team has to decide what it will really do.

As moderator, I go through the tickets one by one and ask two questions:
  1. Who can fix this issue, the team (people in the room)? Or is help from someone else necessary (e.g. management, another department)?
  2. Does this tickets belong together with some other ticket, or is it a new issue? For instance, there might be three different suggestions related to testing, and these might get grouped together on the common theme.
I usually group the tickets in two columns, one for own jurisdiction (the team can address the issue itself) or one for foreign or shared jurisdiction.
If there is some doubt as to who has jurisdiction over a particular problem, it is helpful to trim the scope of the ticket so that them team can take responsibility. Otherwise, negotiation is required with a third party, say management or another department. This will at least take time and may even call into question whether the idea can be implemented. A team can move much faster on issues for which it has jurisdiction. (Non-Scrum teams are often totally dependent on their management to get any improvements done at all! - No wonder Scrum teams are faster!!)

Once the tickets are grouped and consolidated, the team can prioritize the improvements, e.g. using dot-voting. Depending on the number of tickets in each column, the team might vote on each column separately or both columns together.

At this point the team has a prioritized list of improvements it can make to improve its performance and/or make it a happier team. Usually I suggest that the team stop at this point. The next day, just after the daily Scrum, the team should decide how many of the items it wishes to take on for this sprint and how to tackle those items.

It is better to commit to and succeed at implementing just one improvement rather than to commit to too many ideas and not get any of them accomplished.

I suggest taking a picture of the results and posting them to project wiki. I do not suggest keeping track of suggestions you decided not to implement. This list would become heavy baggage to carry around. If the issues are important, they will resurface in a future retrospective. It can however be quite satisfying to keep track of the improvements that you have actually implemented, both for you and your management.


Unknown said…
Hi Peter,
thanks for the detailed description of your way doing retrospectives. It helped to find some more things I can try in our retros - e.g. I did not use the grouping + who can solve it before the voting, which topic to consider in detail.

As you mentioned in the beginning its really important to energize the retrospective again and again, keep it vital and fresh as the tendency to a boring meeting is there if no variations occur.

To address this top I tried to list various ways for variations at Evolving retrospectives - variations to avoid boredom - energize it - maybe you can share your opinion on it and maybe you have more variations to add?
Peter said…
Hi Sebastian,

I agree wholeheartedly on the importance of keeping retrospectives energized.

Your article has many good suggestions: A couple thoughts I would add to your article:

1. Always commit to 1 point, and really do it! Nothing demotivates more than doing the exercise and not doing anything with the results.

2. Limit the number of points you seek to address in a sprint to 1 or 2. Better to get 1 or 2 finished than have 5 "in progress".

3. Put the selected items into the sprint backlog. Improving the team's performance is usually more important than getting the last few story points in the teams performance each sprint.

4. Apply creative amnesia: Nothing weighs you down more than a list of things you haven't done, so don't keep a list of the things you didn't address. If they're important, they'll resurface in the next retrospective. If not, who cares about them?!

Unknown said…
Hi Peter,
thanks a lot for the nice additions. I added them already :-)

We still note down the things we found - at least to remember later what we had as topics during the year. Sometimes this creates new ideas (e.g. when discussed with other teams) and it's management is not that time consuming.

For points we found but did not address during the retrospective we apply what you call - creative amnesia. I completely agree with you - if they are important they will make it to the next retrospective.


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…