Scrum Retrospective 101 (Part 2: Gathering the Data)
The book, “Agile Retrospectives – Making Good Teams Great” divides a Scrum Retrospective into 5 key steps.
In this guide, we’re using the same 5-step process to help you plan, organize, and conduct a successful retrospective.
This is the second part of our 5-step guide: Gathering the Data. To read the first part, “Setting Things Up”, click here. In this part, we dive a bit deeper into how you can collect meaningful data that helps you conduct a fruitful retrospective.
Let’s get started.
Gathering the data
In this phase, your primary goal is to collect meaningful facts and opinions about the sprint and make them public knowledge, so every team member knows what exactly happened during the period.
We recommend further classifying this phase into 2 steps:
- Collecting hard facts
- Taking personal opinions
Step 1: Collecting hard facts
Although the step is called “collecting” data, you don’t really have to collect it yourself. As a scrum master, you can assign this task to someone else in your team.
However, it is your responsibility to have this data available during the meeting.
This data includes facts and numbers, which are collected during the sprint. Be noted that this step is all about hard, cold facts; none of the team members should be able to change them with their personal opinion.
Here’s what this data could include.
1. Sprint goal
This is where you find out whether the team achieved the goal of the sprint, which shouldn’t be hard.
However, it’s perfectly fine to have a short discussion after the hard truth. For instance, if the team has achieved the goal, you could say, “We’ve achieved our Sprint goals 3 times in a row.” — which could help boost morale.
Or, if you haven’t achieved the goal, you can talk a bit about why you failed.
2. Story points
You collect info about the number of planned story points, and how many of them your team managed to complete.
It’s advised to lay out this data in a spreadsheet and a graph, so everyone can understand the performance metrics easily.
3. Miscellaneous data
In this one, you collect other relevant data that might be useful to your team.
For instance, if your team is having problems keeping the number of unresolved bugs down, you could mention it. In this example, you could mention the number of open bugs when the sprint began and when it ended.
All in all, you can take any form of internal data that might bring meaningful insights to your team.
4. Data which you shouldn’t share
Lastly, there’s some data that you want to bring with you, but not share in the meeting.
For example, you could collect information about how many story points each team member completed. But, you shouldn’t share it, as the team member with the lowest number might get uncomfortable.
However, as a scrum master, you can voluntarily decide to share this information if needed.
Plus, make sure this information only includes hard facts and not your personal opinions. For example, if you “think” a certain team member didn’t work on a task as much as they should have, you can’t label it as “hard data”. You’d need numbers for that.
Step 2: Taking personal opinions
This is where you let every team member speak up and let their voice be heard about the hard data.
Be sure to give everyone some time to think before they speak, so they can express their thoughts and feelings in the best way possible.
1. Silent writing
If you don’t give your team members time to think it through and get them talking right away, it might create an imbalance. Seniors, extroverts, and generally more confident people might take over and others may not get the chance to speak up.
A working strategy is to ask everyone to jot down their thoughts on a note in a few minutes.
This would allow everyone, even introverts and shy individuals, to figure out what they want to say in the upcoming discussion.
2. Formats you could use
There are quite a few viable formats you could use to ask questions and gather data, like Sailing Boat, Mad Glad Sad, and Start Stop Continue.
As the scrum master, it’s up to you to decide which model will work the best in your specific scenario. For instance, if the last sprint has been really successful, the Start Stop Continue format could be the way to go.
What’s next?
After you’ve got hard facts, as well as valuable personal opinions, the next step is to generate meaningful insights from that information.
We discuss that in the next part of this guide, Part 3: Generating Insights.
Before we let you go, we’d like to hear which data-gathering formats have worked well for you. Be sure to tell us in the comments section below.
