As per the English Oxford Living Dictionary metrics are “A method of measuring something, or the results obtained from this”. And why do we need metrics? The answer to this question is to make the process predictable. Once we can predict the process, we can improve it.
Scrum.org introduced 4 basic key flow metrics in “The Kanban Guide for Scrum Team” named “Work in progress”, “Cycle time”, “Work item age” and “Throughput”. Teams may use or introduce new metrics if needed, but at minimum, these 4 metrics can reflect the current health of the overall process. With the help of these metrics, the Scrum team can take appropriate action to improve their process and increase the value.
The four key flow metrics
| Metric | Type | What it measures | Where it helps most |
|---|---|---|---|
| Work in progress (WIP) | Current count | Items started and not finished | Daily scrum, retrospective |
| Cycle time | Lagging | Time from start to finish of an item | Retrospective, Service Level Expectation |
| Work item age | Leading | Time since an unfinished item started | Daily scrum, sprint planning |
| Throughput | Output | Items completed per unit of time | Sprint planning, forecasting |
Kanban Metrics
Let us go in-depth and learn what Kanban metrics are:
Work in Progress
The first thing to remember is that “Work in Progress” and “Work in Progress limit” are not the same thing. “Work in Progress limit” is a Scrum team policy they decided to put on individual phases. Different phases, usually represented in the form of columns on the Kanban board, may have different “Work in Progress limit”. In typical situations, “Work in Progress” is less than or equal to “Work in Progress Limit”. Although in general reducing the “Work in Progress” increases overall efficiency, it is not guaranteed and not always be the case.
Calculating Work in Progress items is very easy and “Work Item Age” gives important information about the process to discuss in the daily stand-up meeting. Since all the incomplete items are put back into the Product backlog at the end of the Sprint, therefore this metric is not helpful in Sprint review. However, how many items are in progress can be used to improve the work process, because a lower number of “Work in Progress” items on average means we will have a potentially better workflow and on average reduce cycle time, therefore this metric is important in Sprint retrospective discussion. All the key flow metrics have some importance in Sprint Retrospective.
Cycle Time
“Cycle Time” is a lagging indicator. A lagging indicator, also called an output measure, can recorded after the event happens. Cycle time is the time elapsed between the items started and completed. In other words, we can say that cycle time is the time how long the work item is in a “Work in Progress” state. If cycle time is high, then reducing “Work in Progress” potentially reduces cycle time.
This can be usually referring as “Lead time” or “Flow time”. Service Level Expectation (SLE), which forecasts when an item will be completed probabilistically, is calculated from the Cycle time. However, if the project is new and there is no historical cycle time data available, then it can be guessed.
One more important of cycle time is to get feedback from the customer. “Cycle Time” gives us an idea of how soon we can get customer feedback. Increasing cycle time reduces our customer interaction and feedback.
Sporadically team starts working on the items, which clicks the cycle time, and stops working on it due to any reason such as some external dependencies. In that case, although cycle time keeps increasing, the team is not working on that item. If we need to find out such a problem, then we can keep information about when the team is actively working on an item and get a ratio on it with a cycle time to get the efficiency of the flow.
Work Item Age
“Work Item Age” is the time elapsed from when the item was started till now. In contrast to the cycle time, this is a leading indicator. It is calculated for only those items who is still in progress and not completed yet. Once the item is completed, then the cycle time metric comes into the picture. There is a possibility that an item may be in a progress state for a long time, therefore it is also an important metric to discuss in the daily stand-up meeting to know if it can be improved. If there are some items not completed during the Sprint, then we can potentially use this metric in the Sprint planning meeting.
Throughput
“Velocity” is closest to the throughput and like velocity can be estimated as the likely delivery date. It is the number of completed items per unit of time. In the case of velocity, it is the number of completed story points per Sprint. However, unlike the velocity and user stories, the throughput doesn’t distinguish between the size of the items, larger items and smaller items both have the same weight when calculating the throughput. If the average cycle time decreases, then it potentially increases the average throughput of the process.
Throughput can tell us how fast the team can complete the item and what will be the likely completion date. It is also used to estimate the capacity of the scrum team for the upcoming sprints therefore this is a very important metric in Sprint planning. Throughput can also be calculated at different phases of the process to acquire an idea of how fast items are entering and leaving different phases. The team can use more advanced techniques, such as Monti-Carlo simulation on throughput data to get more insight into the items.
To learn more and upskill yourself check out our Kanban certifications.
How the metrics work together
| What you see | What it often means | What to try |
|---|---|---|
| Work item age climbing on a few items | Those items are stuck or blocked | Discuss them first at the daily scrum |
| Cycle time rising and WIP rising | Too much started at once | Lower WIP so items finish sooner |
| Throughput unstable between sprints | Uneven item sizes or interruptions | Split items; protect focus time |
| Cycle time spread widening | Mix of very different work types | Track work types separately |
Definitions vary between sources: some people use cycle time, lead time and flow time loosely. Choose the start and stop points once and use them every time. Our guides to cycle time, lead time, flow time and Little’s Law go into each one. To learn to apply them, see the Team Kanban Practitioner (TKP) course (8 hours, $550) and the Kanban Management Professional (KMP) certification (32 hours, $2,200).
Additional discounts are available. Contact us to know more.
More questions answered
Do Scrum teams need Kanban metrics?
They help. The four flow metrics give a Scrum team evidence about how work moves, which makes retrospectives and forecasts more concrete than opinion alone.
What is a Service Level Expectation?
It is a forecast of how long an item will take, stated as a probability, for example “85% of items finish within 8 days”. It comes from your own cycle time history.
How many items do I need before the data is useful?
A few weeks of finished items is enough to see a pattern. Treat early numbers as rough and keep collecting.
Last reviewed October 2026 by the AgileFever editorial team.
