What are flow metrics and why should you care?
In short
Flow metrics will change how you think about productivity, predictability, and effectiveness. They provide insight into how your processes are operating and help you identify issues and bottlenecks. They tell you whether your process is predictable, which supports effective planning and forecasting. They suggest actions you can take to improve and they tell you if your process changes are having the desired effect. Since they are framework-agnostic, they can be applied to all types of knowledge work.
This article describes the four core flow metrics that are essential for understanding your processes:
Cycle Time: the elapsed time between when a work item was started and when it was finished
Work in Progress (WIP): the count of work items that have been started but not yet finished
Throughput: the count of work items that are finished per unit of time (days, weeks, months, etc.)
Work Item Age: for work items that are in progress, Work Item Age is the elapsed time between when the work item was started and the current time
It also covers one additional flow metric that you may find useful:
Lead Time: the elapsed time between when a work item was requested and when it was finished
And one that you may come across (but probably shouldn’t use):
Flow Efficiency: the ratio of time that a work item was actively worked on to its Cycle Time
Overview
If you’ve worked in a team for any amount of time, you’ve almost certainly had to answer questions from stakeholders like:
How long will this take?
Can you do it by <insert unrealistic date>? and
Why can’t you go faster?
These questions are universal. They are not unique to any profession or industry. They are also completely understandable because your stakeholders face the same pressures that you do. They are accountable to their own stakeholders: customers; board members; shareholders; executives; etc. They want to deliver on their commitments. Ideally, they want to exceed expectations by delivering more value, faster and cheaper. So we should be able to give data-informed answers to the above questions.
The unfortunate reality for many teams is that they are not set up for success when it comes to questions like these. They work with new technologies. They have dependencies on other teams and companies. They work in an environment with changing priorities and too much work in progress. Their work is inherently complex and uncertain.
The traditional approach to solving this problem is planning and estimation. Teams have lengthy meetings to create plans and estimate work with the belief that this will drive out uncertainty. Unfortunately, this kind of upfront planning and estimation is done when we know the least about the nature of the work. It gives the illusion of certainty and risk reduction, but a lot of it is based on gut feeling and wishful thinking. We can’t escape Hofstadter's law (it always takes longer than you expect, even when you take into account Hofstadter's Law).
Sure, frameworks like Scrum advocate for regular revision of plans via short sprints and daily scrums, but they don’t provide the tools that teams need to measure productivity, predictability and effectiveness (in Scrum’s defence, it does not purport to do this and it’s quite clear on that point).
This is where flow metrics come in. Flow metrics give you insight into how your process is operating. They tell you whether your process is predictable, which helps with planning and forecasting. They help you to identify issues and bottlenecks. They suggest actions you can take to improve and they can be used to measure if your process changes are having the desired effect. They are framework-agnostic and can be applied to all types of knowledge work. They will change the way that you think about productivity, predictability and effectiveness.
In this article I’m going to cover what I consider to be the four core flow metrics: Cycle Time; Work In Progress (WIP); Throughput; and Item Age. I will also detail two additional flow metrics that you should be aware of: Lead Time; and Flow Efficiency.
A few notes before I proceed. Firstly, there is an unfortunate lack of consistency in the definition of flow metrics, so you may find authors elsewhere who use different terminology or give different definitions. The metrics and definitions that I have outlined here are the ones that I have personally found useful with the teams that I have worked with.
Secondly, while these metrics are often associated with Kanban, they can be applied to any system of work.
What is flow?
Flow is the movement of potential value through a system1. The system in question could be your team’s workflow of user stories/tasks/etc. Or it could be at a higher level, including things like Epics and Features. Or at an even higher level - a company wide portfolio of initiatives. Part of the beauty of flow metrics is that they can be applied to any system that delivers value to customers or stakeholders.
Whatever level of work you’re interested in can be modelled as a series of statuses or stages that each item of potential value goes through from start to finish. The value is "potential" because you don't know whether something is truly valuable until you've validated with your customers or stakeholders (i.e. at the end of your workflow).
In this article, I'm using the term work item to describe these items of potential value. This is not a universal term, but it is reasonably common and Jira is currently in the process of updating to use this terminology2. So when you see "work item", you can substitute the term that is appropriate for your system (Initiative, Epic, User Story, etc).
Before you get started using flow metrics, you need to define 2 points in your workflow. There are no rules for where in your workflow these should be. It's up to you to define them. However, it is important that they are agreed with your team and stakeholders, so I'd recommend defining them collaboratively. And note that they may change over time as your process evolves.
These points are:
Work item started: What does it mean to start on a work item? Usually this will be when a work item transitions into a certain status in your workflow.
Work item finished: What does it mean for a work item to be finished? To put it another way, when is value delivered? For software teams it might be when testing is complete, when a work item is deployed to production or even when you have customer feedback confirming whether or not it was valuable.
Figure 1: Define 2 points in your workflow - Work item started and Work item finished
Core flow metrics
The definitions in this section draw from Daniel Vacanti’s book Actionable Agile Metrics for Predictability3, the Kanban Guide and my own experience teaching and implementing these metrics.
Cycle Time
Cycle Time is the elapsed time between when a work item was started and when it was finished.
Cycle Time is a measure of how quickly you can deliver (potential) value. It correlates reasonably well with cost (higher cycle time generally equals higher cost). It measures how long it takes to validate whether a work item is truly valuable (by getting customer / stakeholder feedback). And once your process is stable, you can use historical Cycle Time data to forecast how long it is likely to take to complete individual work items (more on this in a future post).
Cycle Time is often measured in days, though it could also be measured in months, weeks, hours or minutes if your system is delivering work items on those timescales.
The formula to calculate Cycle Time is:
Cycle Time = (Date work item finished) - (Date work item started) + 1
So if a work item was started on 20 Jan 2025 and finished on 30 Jan 2025, then:
Cycle Time = (30 Jan 2025) - (20 Jan 2025) + 1 = 10 days
I'm following guidance from Dan Vacanti here and adding 1 to the result3. The rationale is that if you complete a work item on the same date that it was requested, the Cycle Time will be 1 day, not 0 days.
Also note that I have included weekends and public holidays in the calculation. There’s a whole argument on the pros and cons of this that I’m not going to go into here. What really matters in my opinion is that you are consistent in your approach. If you want to exclude weekends and public holidays from your calculations, go right ahead. Just know that things can get complicated when you’re working across multiple timezones and/or teams work weekends to hit deadlines (don’t do that to your teams please).
Work in Progress (WIP)
WIP is the count of work items that have been started but not yet finished.
A central tenet of Kanban is that you should control your WIP. There’s a very good reason for this. The higher your WIP, the longer individual work items take to complete, the fewer things you get done and the less predictable your process will be.
Measuring WIP is simple. Simply count the number of work items that have started but not yet finished.
Remember that just because something is Work in Progress does not necessarily mean that it is being actively worked on. A work item can be in progress, but waiting for a person or team to become available or the item may be blocked by an unresolved dependency.
Throughput
Throughput is the count of work items that are finished per unit of time (days, weeks, months, etc).
Throughput is a measure of productivity. It tells you how many things you get done per time period. At a team level it’s common to use days or weeks as the unit of time.
Throughput helps to identify bottlenecks in your process. Understanding throughput at different stages in your workflow can give you an early warning when there are issues. And once your process is stable, you can use historical Throughput data as input to a Monte Carlo simulation to forecast how long it is likely to take to complete an epic / project / etc (more on this in a future post).
Throughput is different to Velocity. To calculate Velocity (often done for Scrum teams), you add up the total of all Story Points completed in a Sprint. Throughput, on the other hand, is simply the count of work items completed. There is no need to add up Story Points, Ideal Days or similar. Many people find this idea uncomfortable at first (I know I did). In my experience, the best cure for this discomfort is working with these metrics and seeing how they perform.
Work Item Age
For work items that are in progress, Work Item Age is the elapsed time between when the work item was started and the current time.
Work Item Age is possibly one of the most important and most underutilised metrics available to teams and organisations. It is an early warning indicator when work items are slow or stuck. It can be used to focus conversations at daily standups and as an input to priority decisions.
Focusing on Work Item Age is the single most impactful thing that you can do to reduce Cycle Times and increase productivity and predictability. In my opinion it is even more important than reducing WIP (though that is certainly important too!).
Similar to Cycle Time, Work Item Age is often measured in days, though it could also be measured in months, weeks, hours or minutes. I recommend using the same units for both Cycle Time and Work Item Age.
The formula to calculate Work Item Age is:
Work Item Age = (Current Date) - (Date work item started) + 1
So if a work item was started on 30 Jan 2025 and the current date is 7 Feb 2025, then:
Work Item Age = (7 Feb 2025) - (30 Jan 2025) + 1 = 9
See the comment under Cycle Time for the rationale behind adding 1 to the difference between dates and the treatment of weekends and holidays.
It may be stating the obvious, but Cycle Time can also be thought of as the Work Item Age of the work item when it was finished.
Additional flow metrics
You can achieve a lot using the core flow metrics described above. The additional metrics in this section are two of the most common that you are likely to come across. In my opinion, Lead Time can be useful because it measures time from a stakeholder perspective. Flow Efficiency, on the other hand, is problematic for the reasons given below.
Lead Time
Lead Time is the elapsed time between when a work item was requested and when it was finished.
In order to measure Lead Time you need to define another point in your workflow:
Work item requested: This is particularly relevant for teams who deal with requests from one or more stakeholder groups. Think carefully about what it means for work to be requested. Is it when it is first raised at a meeting? When you receive an email about it? When it’s first logged in your work tracking system?
Figure 2: In order to measure Lead Time, define a 3rd point in your workflow - Work item requested
Lead Time is often the key measure that stakeholders care about. It’s the answer to the question of how long they’ll have to wait between making a request and receiving the finished item.
Unfortunately Lead Time is problematic for a lot of teams because in many cases requests are “pushed” onto the team without an understanding of the team's Work In Progress or backlog of other requests. This is one of the reasons that you need to be careful in defining what “Work item requested” means for your team.
It is often beneficial for teams new to flow metrics to omit Lead Time measures initially.
As for Cycle Time and Work Item Age, Lead Time is often measured in days, though it could equally be measured in hours or minutes. My advice would be to use the same units for Cycle Time, Work Item Age and Lead Time.
The formula to calculate Lead Time is:
Lead Time = (Date work item finished) - (Date work item requested) + 1
So if a work item was requested on 14 Jan 2025 and finished on 30 Jan 2025, then:
Lead Time = (30 Jan 2025) - (14 Jan 2025) + 1 = 17 days
See the comment under Cycle Time for the rationale behind adding 1 to the difference between dates and the treatment of weekends and holidays.
Flow Efficiency (a problematic metric)
Flow Efficiency is the ratio of time that a work item was actively worked on to its Cycle Time.
In other words
Flow Efficiency = [(Active Time) / (Cycle Time)] x 100
For example, if a work item has Cycle Time of 10 days and it was actively worked on for 2 of those days, then:
Flow Efficiency = (2 / 10) x 100 = 20%
Figure 3: Example of a work item with Cycle Time of 10 days and Active Time of 2 days (20% Flow Efficiency)
The theory goes that by aggregating flow efficiency across multiple work items you gain insight into how efficiently value is flowing through your system. However, there are multiple problems with this:
It is impractical to track: it requires waiting states in your workflow; an agreed and consistent process for marking blocked items; and accurate and consistent updates of your work tracking system
It is usually reported as an average value which obscures the variation in the underlying process and makes it difficult to gain useful insights
It doesn’t give any indication of what actions you should take to improve
The good news is that you can get some of the purported benefits of Flow Efficiency without actually measuring it. You just need to switch perspectives. Instead of looking where the work is happening, look where it isn’t happening. Take action to reduce wait times, remove blockers and break dependencies. This can significantly reduce Cycle Times without major changes to process or investment in additional staff or technology.
Nick Brown wrote a good article detailing the many flaws of Flow Efficiency and another analysing Flow Efficiency data for teams at ASOS.
Tips for getting the most out of flow metrics
Remember Goodhart’s Law
Goodhart’s Law states that “when a measure becomes a target, it ceases to be a good measure”. Flow metrics are great for understanding your process and improving your productivity, predictability and effectiveness. But please don’t use them as KPIs or compare flow metrics across teams or departments.
I once worked with a company that tried using Lead Time as a KPI for their teams. They set targets and reported against them on a monthly basis. They recorded the date the work item was requested based on the date that it was entered into their work tracking system. There were even awards for the teams with the best performance against the target. As a result of that, teams deferred entering requests into the work tracking system until the last possible moment, maintaining a separate spreadsheet of requests. This kept their reported Lead Times low but they failed to realise the benefits they wanted and the missing data made their work tracking system less useful.
Get buy in by communicating the benefits
In order for these metrics to be useful, you need alignment on what they are and how they will be used. You also need a way of collecting, analysing and communicating the data.
This means that team members need to update work tracking systems regularly and ideally someone needs to track the metrics at a portfolio level. This requires collaboration at all levels of the organisation and may be seen as an imposition. If team members and stakeholders don’t see the benefits, they may feel that you’re adding undue administrative burden.
In my experience the best way to address this is to communicate the benefits early and often. For team members, flow metrics lead to better ways of working, improved collaboration and increased trust with stakeholders (which in turn leads to increased autonomy). For stakeholders and leaders, benefits include increased productivity, faster delivery, better predictability and increased effectiveness.
Use Work Item Age at your Daily Stand-up
Staying on top of Work Item Age is the single most important factor in reducing Cycle Times and increasing productivity and predictability. So why not use it to drive conversations at your daily standups?
Focus on the oldest items in your workflow first. As they age, discuss strategies for completing them. Can you pair or swarm to complete the work item faster? Do team members need help resolving a dependency or blocker? If the item is larger than you initially thought, can you split it to deliver some value sooner?
Where to from here?
This article is intended as an introduction to flow metrics but there is a lot more to cover. In subsequent articles I plan to cover how to get flow metrics out of Jira, how to visualise the data, how to forecast and how understand process stability.
References
Kanban Guide, accessed 8 Feb 2025
Work is the new collective term for items tracked in Jira, accessed 8 Feb 2025
D. Vacanti, Actionable Agile Metrics for Predictability, Leanpub, 2016
