In their book Agile Retrospectives, Esther Derby and Diana Larsen popularized the idea that a Sprint Retrospect comprises five stages. The second stage refers to gathering data so that the Scrum Team can have data-informed Retrospectives.
As I have observed in practice, many Scrum Teams either limit the data gathering part of the Retrospective, thus lacking vital information. Or they invest too much time doing so, leaving little capacity to analyze the data and come to conclusions on how to best improve as a team.
Read on and learn how you can avoid falling victim to both scenarios by gathering data continuously and asynchronously.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 31,000-plus other subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
Join more than 150 peers from May 27-29, 2021, for the Virtual Agile Camp Berlin 2021, a live virtual Barcamp using open space technology principles and practices.
Let us start our excursion by revisiting the purpose of the Sprint Retrospective according to the Scrum Guide:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness in the process.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
Source: Scrum Guide 2020.
For our purpose, we need to understand that there are two primary sources of data that the Scrum Team can analyze:
Cannot see the form?
Please click here
Generally speaking, metrics help to understand the current situation better and allow us to gain insight on change over time. Without metrics, assessing any effort or development will be open to gut feeling and bias-based interpretation.
A metric should, therefore, be a leading indicator for a pattern change, providing an opportunity to analyze the cause in time. The following three general rules for agile metrics have proven to be useful:
For example, if the (average) sentiment on the technical debt metric (see below) is slowly but steadily decreasing, it may indicate that:
While the latter probably is a good thing, the first interpretation is worrying.
While you probably have quantitative data readily available somewhere in your project management system, or at least you could configure it so that the application delivers the desired information, you will need to gather the qualitative data differently. Let’s have a look at a few proven techniques:
What occurrences influenced the Scrum Team’s progress towards achieving the Sprint Goal? Keeping a team diary effectively collects information on events or meetings, communication threads, incidents, problems, or wins and fails. Based on this information, creating a timeline of a Sprint becomes simple.
Timelines are very helpful when you want to visualize the flow of events and how those have influenced each other. For example, using a timeline allows you to connect management pressure on the Scrum team to meet a delivery date with a subsequent decrease in the perceived quality of the tech stack as the Developers had to cut corners to meet the deadline, increasing technical debt.
Keeping a team diary also allows voting on the importance of occurrences, as individual team members may have a different take on what happened. Also, timelines provide the groundwork for overall retrospectives with stakeholders and customers, which a Scrum Team should consider running in regular intervals.
My tool of choice to collect qualitative data is anonymous surveys. There are plenty of tools available for this purpose, from Typeform to Google Forms to SurveyMonkey, to name a few. Please ensure before running them, though, that anonymous surveys are in line with the governance rules of your organization. (I once worked for a large automotive supplier in Germany where every survey among workers needed to be approved by the work council—four weeks in advance—which rendered the tool practically obsolete for Sprint-based surveys.)
My preferred set of questions for every Sprint is:
Of course, I visualize the results over several Sprints to identify patterns as early as possible. Again, the survey results complement the data from the team diary.
The anonymous survey is also well-suited to gather data on the Scrum Team’s fluency in Scrum Values. In this application, you use the five Scrum Values of commitment, courage, focus, openness, and respect as questions:
On a scale from 0 (= not at all) to X (= always), how would you rate the team’s appreciation of the Scrum Value “Commitment?”
Often, Scrum Teams excel at identifying problems only to drop the baton once it comes to apply a remedy to the challenges at hand. Here, two simple practices help the team to move forward:
The data from this exercise, for example, the lead and cycle time of action items, or the ratio of open to delivered improvement items, also proves to be helpful for a data-informed Retrospective.
Should you provide a Sprint mailbox for grievances? The idea is that the mailbox is permanently accessible by comparison to the Sprint survey, which is typically answered at the end of the Sprint. Please note that having to provide a Sprint mailbox points to severe communication and collaboration issues at the team level. Team members do not seem to live Scrum Values like openness, respect, and courage, and there appears to be a lack of psychological safety. Hence I would consider providing a Sprint mailbox only as a temporary means until the communication issues within the team have been solved.
Without data, there is no information; without information, there is no insight; without insight, there is no way to understand where you are heading as a Scrum Team. If you take ‘continuous improvement’ as a concept seriously, you will enjoy identifying the right set of metrics for your Scrum Team, embracing the idea of data-informed Retrospectives.
What data are you tracking to understand the progress of your Scrum Teams better? Please share with us your lessons learned and tips & tricks.
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
Agile Metrics — The Good, the Bad, and the Ugly
21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams
The Overall Retrospective for Team and Stakeholders
Faking Agile Metrics or Cooking the Agile Books
Download the Scrum Anti-Patterns Guide for free.
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
TL; DR: System-Level Scrum Stakeholder Anti-Patterns Learn how outdated organizational structures manifest themselves in system-level…
TL; DR: Scrum Master Tasks: Let's Bust Some Myths! Rumor says that a great Scrum…
TL; DR: Scrum Master Interview Questions on Creating Value with Scrum If you are looking…