Three critical data points to review during every retrospective will anchor your decisions to change the system in stats, not opinion. Transforming your subjective retro into an efficient, smart meeting based on facts, figures, and quantifiable improvements.
Ask any successful team that has been using Agile practices for at least a few months and you’re likely to get a consensus on the importance of retros.
Retrospective meetings are the not-so-secret ingredient to a healthy and effective team process.
They bring the team together, focus group efforts on making incremental improvements and give us a chance to resolve issues before they become crushing to our productivity.
Yet, these powerful opportunities for team reflection often get booted out of our calendars to make way for other meetings.
One of the main reasons retros don’t always get the love they deserve is closely linked to one of the common pitfalls of this meeting format: that it’s not driven by data.
There are three crucial metrics that you can address during your retrospectives to ensure that this recurring meeting and its takeaways are anchored by data, instead of subjective opinions. Cycle time, work in progress and throughput are simple, easy-to-track data points that are helpful for the core internal team and external stakeholders equally.
Read on to start measuring these team stats today! You’ll quickly notice your retrospective meetings becoming smarter and more data-driven, so you can make confident decisions about how to improve your processes.
No matter the team you’re working within, you’ve at some point been backed into a corner by a stakeholder who wants an answer to the question: “If you start working on this today, how long is it going to take you to finish?”
In this case, stakeholders are asking about your cycle time.
Simply put, cycle time is how long a work item takes to pass through the process, from the moment the team starts working on it, to the moment it is delivered. It can be helpful to imagine cycle time as a clock that starts ticking the moment a new task moves from the backlog (unstarted work) to the first stage of in progress (work begins).
When the work item is considered Done or Complete, meaning it is ready to be delivered to an internal or external customer, the clock stops ticking and spits out a task cycle time (ex. 1 day, 3 days, 10 days). This contributes to the team’s average cycle time for all tasks.
Often, stakeholders are interested in cycle time to determine how long it will take for their projects to get completed. However, teams also stand to reap significant benefits from tracking cycle time within their process.
Tracking cycle time, per work item as well as on average, helps teams:
The retrospective meeting is a wonderful recurring opportunity to revisit the team’s cycle time and use this vital data point to generate takeaways about the state of the team process.
For example, if average cycle time is going up, this is an indicator that the team process is slowing down and dealing with delays. The team can investigate where work is getting stalled out and dig into the deeper reasons about this shift.
If cycle time is going down, this indicates an optimization is working, resources have been added to the team or a new factor in the process is resulting in faster pace of delivery. Similarly, the team can investigate the reason behind the faster pace and capitalize on it.
WIP stands for work in progress and is, arguably, one of the most important quantifiable indicators of team focus and performance.
Only 2% of the general population can actually multitask effectively.
For the rest of us, attempting to work on too many things at once takes a huge toll. A high WIP measurement inside any given team or organization can indicate a high risk of wasted time, team productivity getting slashed by almost 40% and unnecessary costs accruing at the expense of the team.
Your stakeholders may not necessarily care about your team’s WIP as much as they do about your cycle time and throughput. However, this may just be the metric that most affects how quickly your team can deliver.
Depending on a few different factors such as team size, familiarity with the type of work, and other team resources, an optimal number of items in progress at the same time will vary between teams.
For a team of 5 dedicated members, working on familiar work, having 4 items in progress at one time might translate into faster cycle times and increased throughput.
However, if this same team of 5 dedicated members loses track of their work in progress and ends up with 25 different work items in flight at the same time, they risk:
Tracking the number of work items in flight at the same time is as easy as tallying up the number of work items in progress at the end of each week. You can also track WIP daily to generate a weekly range with minimum and maximum (ex. Work in progress for this week was 2-10, meaning at the lowest point we had 2 work items in progress, but there was a day/s during which we were juggling 10 work items).
Discussing work in progress stats during your retrospective will ensure that you don’t lose sight of the volume of work you are taking on inside your team. The effects of high or low WIP can also influence decisions about process structure and, in some cases, enforcing limits on the number of work items we can have in flight at the same time to discourage multi-tasking.
Throughput calculates the number of work items that a team completes in a set period of time (usually one or two weeks). Like cycle time, throughput is a metric that can easily be applied to any type of work, as long as items are sized similarly in the workflow.
To determine their throughput, teams set time aside at the end of the period to tally up all of the work items that were completed up until that point.
Coupled with a prioritized backlog of unstarted work, this metric can become a powerful influencer of team estimates and a source of peace of mind for stakeholders.
Imagine Team A has a weekly throughput of 8 work items on average. Meaning, every week, they complete an average of 8 work items and deliver them to stakeholders.
If I’m stakeholder X and my request is currently #15 on the prioritized to-do list for this team, when can I expect this team to deliver my completed request back to me? With a high level of certainty, based on historical throughput data, this team can deliver my request in a little under two weeks.
In preparation for a weekly or biweekly retrospective, teams are encouraged to tally up their delivered work to arrive at a weekly throughput for their team. By comparing it with previous weeks, the team can determine whether their throughput is below the team’s average or above the team average.
In both cases, this powerful metric can catalyze important conversations about process health or lack thereof inside the team.
Success and high performance await any team that is prepared to weave these three powerful process metrics into their retrospective meetings.
By tracking the pace of the team’s delivery, cycle time measurements can provide a significant indicator of process health, indicate the presence of bottlenecks or highlight problematic areas of the process.
Throughput, the best entry point to process measurement, requires a simple recurring tally to help the team generate more accurate estimates for stakeholders and keep a finger on the pulse of their team’s ability to deliver work.
To avoid the bad habit of multi-tasking, Agile teams on the road to success keep a close eye on the number of work items they are trying to process simultaneously. This helps the unit avoid spreading themselves too thin and maintains focus on a few priority work items at a single time.
Bringing up these data points during your recurring process improvement meeting, anchors your decisions to change the system in stats, not opinion. Thereby, transforming your subjective retro into an efficient, smart meeting based on facts, figures, and quantifiable improvements.
Want to accelerate your teams ability to gather and interpret data? Sometimes the hardest part is getting the data out of the tools that you already use. A great place to start is with Dan Vacanti's online, self-paced course Agile Metrics for Predictability.
Join the ranks of data-driven companies seamlessly acting on feedback and driving substantial improvement with less effort.
ScatterSpoke helps you eliminate waste in your dev process.