This is the second post of my blog post series about the five phases of a Scrum Retrospective. In this post, I cover the most crucial ideas for Stage 2 — Gather Data.

If you haven't read the previous post in this series you can find it here: Stage 1 — Setting the stage.

These five stages are presented in the book Agile Retrospectives — Making Good Teams Great by Esther Derby and Diana Larsen. They are:

1. Set the Stage
2. Gather Data
3. Generate Insights
4. Decide What to Do
5. Close the Retrospective

I use this five-step approach as a guideline in each retrospective meeting, which I lead as a Scrum Master.

Ok, let's get to the meat.

The goal in this phase is to bring the facts of the sprint to the table, so that every participant has the same picture of what happened during the iteration.

I usually split this phase up in two steps. First, I announce the hard facts and statistics based on the data the team generated during the sprint. Secondly, we want to get the insights and personal opinions from each individual to generate a complete picture.

Step 1: Hard Facts

The idea of this step is to make the status quo transparent, based on the facts you already have. This type of data is usually generated during the sprint and does not reflect any personal opinions, but hard facts.

It is the responsibility of the Scrum Master to get this information before the meeting starts. Even though the Scrum Master doesn't have to get the data by himself, he is responsible to make sure the data will be available for the meeting.

This data includes the sprint goal and the amount of planned and delivered story points. Next to that, it also includes any other hard facts, which are measured during the sprint.

Sprint Goal

First of all, I name the sprint goal and we figure out whether we achieved our plans. Most of the time, it is obvious whether or not we made the sprint goal, but sometimes there is a short discussion within the team. This is fine, because I want a collaborative decision if we did or did not make it.

I use this information also to keep track of how the team is doing over time. And you can mention in the retrospective that the team achieved the sprint goal, for instance, 5 times in a row.

Story Points

I mention how many story points we initially planned for the sprint and how many were successfully finished.

Here it is a good idea to have an Excel sheet with historical data prepared and show in a graphical overview how the team is doing over time. Keeping this historical data in a diagram can give you insights easily in how the team grows over time, is more productive, finishes more work, etc.

Other Measured Data

You can mention at this point any other important data, which has been measured during the sprint.

For instance, if your team struggles with too many open bugs and too little of them are solved and closed during the sprints, then this is important data to keep track of. This data is usually available easily by having a look at the bug-tracking tool you are using.

In such a case you can announce the amount of open bugs before and after the sprint.

If your team has constantly problems with the high amount of incidents during the sprint, which prevents the team from making good progress with the planned user stories, then this is also important data to keep track of. This data is also usually available in a bug-tracking tool and you can bring this data to the group here as well.

Basically any interesting data, which is measured and might be important to the team, is welcome at this point to share with everyone. This is because it helps that everybody has the same picture of what happened during the sprint.

Data You Don't Want to Show

But there is also some type of data which you don't want to show to the team. This is any kind of data, which might put a specific person on the spot — unless you specifically intend to do so.

For instance, showing how many story points were delivered by each person brings the lowest-scoring person in an uncomfortable situation and doesn't help the team. Therefore, this should be avoided.

You should also make sure to just bring data which has been measured and therefore is a fact. Don't bring data, which you think is a fact, but actually is just your personal opinion.

For instance, if you know that people didn't do as much pair programming as initially planned, but you didn't measure how often they actually worked together in pairs, then don't mention it at this stage.

At this point it is important to just give the hard facts, which have been measured, to the team so that everyone knows what was going on in the sprint.

Step 2: Personal Opinions from Each Individual

When the hard facts are on the table, the second step in the Gather Data phase is to collect the personal opinions and feelings of each individual.

Here it is important that everyone has a voice. Therefore I always use a format, which gives each individual some time to think on his own and express his or her own opinion.

Silent Writing

In order to achieve this I always use a couple of minutes of silent writing, where each person writes down the items on sticky notes so everyone has to think about his or her own experience, feelings and events during the sprint.

If you don't use sticky notes, but just start a discussion where everyone shares his or her thoughts, then you usually end up with a very unbalanced set of data. Because more confident people will take over the floor and express their opinions while other participants won't be able to contribute their thoughts.

Especially if there are a few introverts in the team, these people are not going to speak up while, for example, the senior developer taking over the floor. Even though the opinion of the introverts might be very valuable, they won't have the chance to contribute them to the discussion.

Therefore, for the gather data step I always use a format, which starts with a few minutes of silent writing followed by a round of explanation, where each person explains his or her stickies to the group.

Formats for the Gather Data Step

There are many different formats for the gather data step out there, which basically all work the same way with just slight differences in asking the questions. For instance, there is the Start Stop Continue format, or the Mad Glad Sad retrospective, or you can use the Sailing Boat.

Some of these formats work better than others in different situations. For instance, if the sprint went really well and there is almost nothing to complain, then the Start Stop Continue retrospective is a good way to generate some ideas for improvements.

If you use the Mad Glad Sad retrospective to gather data when a sprint worked really well, then it will basically work, but in my experience, you will get much better results using the Start Stop Continue format. If you want to know more about that check out my post about the Start Stop Continue retrospective.

Recap

Ok, let's quickly recap the important things of the Gather Data phase.

The goal of this phase is to bring all relevant data to the table so that every participant has the same information about the sprint.

This data consists of the hard facts, which have been measured during the sprint. These are the Sprint goal, the amount of planned and delivered story points and any other relevant facts, which have been measured.

The second step is to get the opinions and feelings from each individual by a few minutes of silent writing. After that each individual presents them to the team and clarifies what he/she means.

At that point you have all the important data ready and can continue with the next phase, which is Phase 3 — Generate Insights.

I cover the details about Phase 3 in my next post of this series, which I am going to publish in about 1 week. So stay tuned and keep an eye on the blog.

Meanwhile, I would be interested in formats you mostly use to Gather Data in your Scrum retrospective. Leave a comment if you have any interesting insights, which formats work well in specific situations!

Ok, that's it for now. See ya in a bit, and HabbediEhre!