Flow Metrics @ tb.lx series: Meet the throughput
Welcome to the Flow Metrics series by tb.lx! This is our second article on the topic, and the first where we deep dive into a specific metric. Meet the Throughput!
(Read the first article here to learn more about what flow metrics are and to meet our Agile Specialist, Breno Campos)
Fun fact: Our FUSO Trucks Europe plant in Tramagal (in the center of Portugal), manufactures up to 15,000 trucks a year. Why did I start with this information? Because it’s the yearly throughput of FUSO Trucks Europe, and it’s a good way to start thinking about delivery pace. Throughput is a measure of how many things we can build or deliver in a given amount of time. We can measure outputs such as how many trucks are produced per year, how many cars crossed a toll station per minute, or even how passengers traveled per day in an airport.
How many items can we finish within a defined period? That’s the answer that the throughput metric gives us in the context of software development. This metric can be very powerful when we try to predict delivery, and can also be used to monitor a development team’s health.
We recommend using the metric of the Weekly Throughput, which means that each week you count the work items that the team has moved to “Done” during that week. In our case, work items are stories or tasks in Jira (our daily tracking tool), as they have the same granularity levels in Jira. This means, we do not count Epics in our throughput chart. Also, sub-tasks are not counted since they may be used by someone to manage their daily work, and tracking this through the Throughput is not our goal. The goal is to understand the team cadence. Work items are product backlog increments, which also exclude bugs, because bugs are not considered increments.
To get a better overview of the weekly trend, get a sample of the values for each week and you will have a chart that would look something like this.
“Take care of the trend and run away from accuracy.” Here is a rule you should always keep in mind when looking at metrics. It points out that you should not lose yourself in analyzing every little detail, but instead try to understand the overall picture you are gaining of a team by using the metrics.
Let’s look at a practical example. In the chart above, we have a sample of one of our teams. What we can see, is that the team usually delivers 5 items a week (in a mode of 12 occurrences), while we also have a small variability between 4 to 7 items. Some fluctuations are normal and show that the team is working naturally and is not manipulating the metric. However, regarding the trend, W49 of 2022 and W02 of 2023 deserve our attention because of the great variability of Throughput. We can check that in the beginning of the sample, the team delivered 2 items instead of the 5 that it normally does. The main takeaway we get from this, is that we need to understand what happened. There’s no problem that the metric changed, as long as we know why. There would, however, be a problem if we did not know what caused the change. In this specific case, there was a holiday where some people took extra time off, so we had a shorter week. We also have another outlier we should look closer into. This is the upper one, where the team delivered 9 items, which is almost double the usual delivery pace. We may think that’s a good thing, right? Not exactly, because several things could have happened to cause this. For example, someone could have forced the team to work more, or pressured them to deliver more. In this case, the metrics may fool us. If we ask for more delivery, the team can simply split one item into two and “magically” double the throughput. If we pressure them to work more, the first thing that will suffer is quality, which is the opposite of what we want to happen. The point in looking closer here, is to always understand the reasons for the bottom and upper outlier. In the case of the upper one, we had some smaller items that were tackled by the team, which impacted our throughput.
This leads us to a widespread mistake that can be made when using the Throughput. The team may feel uncomfortable with having a lower Throughput, given that there is the common assumption that more is always better. Remember that the Throughput is just measuring the quantity, not the quality or value you deliver to the customer. Since the delivered value depends on the characteristics of each item, you can even deliver more value with a lower Throughput. The other way round is also possible. To benefit from using the Throughput, we need to ensure that we have a standardized definition of each item. That means that the value you are delivering and the estimated workload for this item, should be roughly the same for each item. Run away from accuracy and do not lose yourself trying to slice the work into equal pieces perfectly. But always keep this in mind when passing through the refinement process.
If you have this standardized item, you can monitor the team’s health and understand the impacts of the changing environmental conditions. If you do not have this standard, you will never know if the team is delivering more (a higher Throughput) due to a higher efficiency or decreasing sizes of each item, which could lead to making the wrong assumptions. In the example above, you can see smaller items and, because of that, expect a peak in the Throughput, as well as a decreasing Throughput, when the team returns to development.
Throughput is highly attached to the context or period and highly individual for each team. Therefore, an absolute no-go, is to using the Throughput to compare teams or to set up business goals and reward teamsbased on their Throughput. Why? Because the first thing they will do when you tell them you need a higher Throughput, is slicing their work into smaller pieces. This would result in the Throughput increasing to infinity. To reward teams, use business-related metrics, such as revenue increase. The most important things to make sure of when managing your teams, are that work items are standardized, and that the Throughput is stable. If these two things happen in your teams, you will be highly predictable and that is what you should aim for.
The key takeaway for Throughput is: Do not be afraid of the variability of the delivery. Be afraid if you do not know how to explain why it is fluctuating.
This series of articles were written with the support of Breno Campos, our Agile Coach, and Benedikt Heinz, a dual industrial engineering student at Daimler Truck and on an international assignment at tb.lx.
