What does 'Gather Data' means for your Agile Retrospectives?

A Retrospective session is a ceremony that has been gaining ground in different teams even if they don’t follow scrum / agile methodologies; the reason is because during this ceremony the team can show their achievements, improvements, and more important failures.

Like the name says, Retrospectives are the time & space to go back and check the activities that were realized during the sprint to determine if the performance is working or is it time to make some changes. All of us have heard about the 5 steps to make a good retrospective from Diana Larsen and Esther Derby, if you don’t remember it those steps are: Set the stage, gather data, generate insights, decide what to do and close the retrospective. But what does gather data means?

We'd like to focus on this point to help you and your team to improve your retrospectives and your team's overall performance.

First of all, why do we need to 'gather data' and why it is important for our retrospective?

Facilitate the conversation:

Retrospectives need to focus on specific topics to find specific solutions. You can’t try to tackle all of them at once. When you focus your retrospectives the conversations become easier and way more productive. Well, if you use the right information that explains, shows, and reflects the performance, your team can be more aware of what points actually hurt the team and be more consensus about what the team needs to do.

Compare information objectively:

Comparing information gives us a better sense of what happened during the sprint. Instead of talking about the problems subjectively (when this is not necessary) and focus the conversation on the problems that the team “thinks” is happening you can be factual and show real problems.

Maybe your team thinks that they are doing bad estimations, but the information shows that maybe that wasn’t the problem. Digging a bit deeper and you may found there were too many bugs, or some other events that slowed or accelerated the work at hand.

The point is that it is always better to focus on the problem that is more relevant for the performance instead of just guessing what the problem is.

So let’s go with the data.


What are the facts? Facts also are known as Hard data.

Facts can be events, metrics, features, stories completed, meetings, decision points, changes in team membership, milestones, celebrations, adopting new technologies. Metrics like charts, velocity, defect counts, amount of code refactored, effort data, and so forth.Source

Other valuable info that you should take into consideration for your Retrospectives are:

Sprint goals: It is necessary to have present where the team thought was going to be and what actually achieve to determine why they didn't and why the goal wasn't achieved

User story: story points and all the points that make a bigger picture of what should be finished and doesn’t happen.

Bugs: sometimes delays are for many bugs, try to keep a record or remember the bugs that appear and show a solution and take more of them into consideration for the next sprint.

Estimation: It is common that some teams have trouble because they make bad estimation; it is totally normal. But notice that they are failing on it can help them to make more accurate the next time

Timeline: A very helpful that can help you to find specific problems is trough a timeline that shows the progress that the team has during the sprint and to figure it about where the team start to have problems or have a slower performance

Why facts: because facts are the objective information that shows the real information that reflects the troubles. It is a more fundamental way to expose that something is going wrong.


Once that your team is focused on hard data and found the principal source of problems, it is necessary that you start talking about the team’s feelings. But why feelings? Because it is time for your team to express their opinions and their approaches to determinate what are the attitudes and behaviors that are delaying the team to achieve their goals.

Many of us didn't like to talk about the way that we feel, even less if it has to be in front of all the team. But you have to figure it out wich is the correct questions to found that information without being aggressive or make the people uncomfortable:

For example on the book Agile Retrospectives: Making Good Teams Great, they show this question to make better questions without being awkward

Past retrospectives info:

Some teams get frustrated with retrospectives due to they feel like the past retrospectives didn’t change anything and they still have the same problems. Have the points that were inspected the last retros is important to compare if the action items are working or if the problem was solved, to determine if its time to look for new solutions. The truth is that so many teams don't have a consideration about their past retrospectives}, they just change the page and that’s all.

Sometimes the reason why the team doesn’t bring the info from their past retros is because they don’t have records and because it is too difficult to collect it. We have an Agile Retrospective tool that will help you and your team to save all that important info and go back to it at any time. Check here.

The truth is that retrospectives need to be very focused to really find a solution, and the best way to do it is through gathering data and expose a big picture for all the team. Find the best ways to expose all that important data that help your team to have a bigger picture of what the team needs to keep improving.

In SoftwareDevTool we always want to help you to keep improving, that’s why we want to share with your our tools to help you and your team to adopt easier agile ceremonies.