The first time I looked at scrumban metrics for my team, I felt a sense of relief…
I knew something felt off with my team.
My team had so much talent. And yet, we struggled to hit our deadlines. Everyone knew what to work on, but we failed to communicate timelines. Sprints sometimes had too little work, which led to extra planning meetings. Or we had too much work in a sprint, which led to feeling like we accomplished nothing.
After reviewing three core scrumban metrics, a ton of ideas came to mind. We weren’t breaking down work small enough. Everyone prioritized writing new code instead of testing completed work. We had no idea how much time we lost to thrashing on different tasks!
There are a ton of scrumban metrics that you could review. In this post, I’ll show you the three metrics I use to understand the efficiency of a software team.
Disclosure: This article includes affiliate links to any books I reference. I may receive compensation when you click on links to these products.
Scrumban Metrics: Velocity Measures Capacity
Velocity measures how many units of work the team completed in a time range. Scrumban teams use “story points” – a unit representing the size and complexity of a task. Kanban teams count the number of tickets they completed. The specific unit you choose doesn’t matter too much. What matters is consistently using one unit.
You should know that Velocity is NOT a measure of a team’s productivity. Velocity is best used to understand a team’s capacity for work. When viewed through this lens, Velocity is perfect for data-driven time estimates! You can calculate how long a project will take by using the total project size and dividing it by the team’s velocity. For example, a project with 24 tickets and a team velocity of 8 tickets per week will take about 3 weeks to complete. Data-driven estimates help a ton when you need to plan around a deadline.
Scrumban Metrics: Cycle Time and Breaking Down Work
Cycle time measures the time it takes for a unit of work to flow through a team’s process. For example, a cycle time of 5 days means a piece of work takes an average of 5 days to move from start to finish. Cycle time highlights areas for to improve efficiency and help inform estimates.
Understanding a team’s Cycle Time requires a lot of contextual information. The team may be writing too many tests or the current sprint has a lot of large tasks that take a while to complete. There’s no single cause for a team’s cycle time. Use Cycle Time as a signal – when it starts trending up, look at other team metrics and ask what’s happening.
Cycle Time is a great tool to show teams the impact of having large tasks. For example, an engineer may try to solve three different bugs in a single code change. ally thought the bugs would take an afternoon to complete. In reality, that third bug is taking days to debug. In this situation, one ticket has a large Cycle Time and holding back two valuable fixes for end users. By breaking the ticket into three bug tickets, the cycle time would be lower and users would get fixes a lot sooner!
Scrumban Metrics: Keep the Work in Progress (WIP) Low
Work in progress (WIP) tracks the number of concurrent tasks the team is working on once. Use WIP to highlight bottlenecks in a team’s process. When your team has too much WIP, it can lead to delays, missed deadlines, and reduced quality.
Tracking WIP is simple. You can visualize this on a single board in a project management system like Jira. All you need to do is have the team keep their ticket statuses up to date. With that in place, you can see which process stage a project is getting hung up on.
For example, say you have development stages named “To Do,” “Coding,” “Testing,” and “Done.” One day, you look at your board and see ten tickets in Coding and only two in Testing. This situation signals that something is going awry at the testing stage. I would then direct the team during standup to help test existing tickets to reduce the WIP.
Conclusion
Over my career, I’ve learned that you need multiple metrics to understand a software team. Software engineering is a complex discipline ot skills. You need a few different metrics help you understand the full picture.
Velocity, Cycle Time, and WIP are the three scrumban metrics I use to understand a team’s effectiveness. These metrics show how well the team is planning, estimating, and find improvements for their processes.
But remember – data is where we start to understand a team. The team’s context and environment will tell you the rest of the story.
How about you? What metrics do you monitor to understand your teams? Let me know on LinkedIn.
Further Reading
- Agile Project Management with Kanban (Amazon)
- How the Xbox Team uses Kanban (video)
Before you go
Build the Stage is about teaching YOU how to be a successful leader.
If you learned something new from this essay, I’d appreciate it if you’d complete one of the following actions:
- Share this essay: By sharing, you help others grow their skills. Save a click with the buttons below.
- Tip a Coffee: Your support shows I’m helping you grow as a leader.
- Give Feedback: Candid feedback is the most effective way to develop one’s skills. Send me an email to let me know how to improve Build the Stage.
- Subscribe! If you’re not a part of the Build the Stage community, it’s never too late.