The Kanban Guide for Scrum Teams presents four key flow metrics that teams can use to see and improve their flow:
Work in Progress (WIP)
Number of work items started but not completed (according to the team’s definition of “workflow”).
Note the difference between WIP and WIP limit. A WIP limit is a rule that teams can use as a “constraint” to help shape their workflow. The goal of the WIP limit is to reduce the amount of actual work in progress (WIP) — also known as the flow load. A team can use WIP metrics to provide transparency into their progress toward reducing WIP and improving throughput.
While teams can directly visualize WIP levels over time (which I recommend), many use a cumulative flow chart to visualize WIP.
Cycle/flow time
The amount of time elapsed between when the work item “starts” and when the work item “finishes”.
This metric is a lagged flow indicator. It is only available after the item is actually completed from a workflow perspective (eg it has reached the Done track on the Kanban board). It is typically used to drive improvement work and establish internal/external expectations regarding the team’s turnaround time on specific items. The main chart/report used for cycle time visualization and analysis is the cycle time scatter plot, where teams can understand their cycle time trends and distributions and look at anomalies.
Permeability
The number of “completed” work items per unit of time.
Note that throughput is the exact number of work items without compensating for item size — a big difference between throughput and speed based on story points. Flow is measured at a specific step in the workflow, usually at the end line of the workflow. The flow can be visualized through a separate graph or by looking at the angle of the curves on the cumulative flow diagram.
Age of the work item
For currently active items — The amount of time elapsed between the “start” of the work item and the current time.
WIP and cycle time are classic metrics that most Kanban practitioners are probably familiar with, and throughput is somewhat similar to speed.
Work Item Age is the new guy on the block. The age of the workpiece complements the cycle time. If cycle time is a lag indicator relevant only to finished items, work item age is a leading indicator relevant only to work-in-progress items. The basic idea is to provide transparency as to which items are flowing well and which are somehow “stuck” even if they are not formally blocked.
Many mature Kanban teams tend to observe aging information through various reports or indicators on their dashboards. Over the years, most serious Kanban tool vendors have introduced some ways to visualize card/item age.
Years in themselves are interesting, but not enough. We also want some indication of the correctness of the flow. One common thing to visualize is the age of the current step in the workflow, also known as “tabs that haven’t moved recently”.
Another way to look at it would be to look at the total age, but combine it with the current position of the work in the pipeline as well as what the team expects the cycle time to be (the Kanban Scrum Team Guide calls this SLE — Service Level Expected). Combining all of this information can help the team focus on items that are at the highest risk of missing team/SLE expectations. For example, let’s say the team has an SLE of 16 days with 85% confidence. If one of the cards on their board is 10 days old, is that ok? Is it a problem? The answer is that it depends. If that card is very close to the end of the workflow, it’s probably not a problem. If it’s very close to the start of the workflow, that’s probably an indication of a problem that needs attention. The “Aging Work in Progress” chart below provides this perspective and where the active items are in the pipeline, what the typical cycle times are for this team and, based on that, which items are indicators of workflow risk (obviously orange-red means very low probability of completion within team flow expectations).
In summary, work item age is the best metric to look at if you want to determine when an item that has already been started will be completed. This is in contrast to the non-starter item – where your best bet is your historical cycle times. The expected service level is just the expectation that the team has set for itself by answering the question, “What cycle time do we expect to see for an item of this type and what is our confidence level for that?”.
Using flow metrics in typical team events
So how can these flow metrics be leveraged in typical team events? Teams can use different events, but a typical set of events combines some planning activities, ongoing check-ins, product progress review, and a retrospective/process improvement session — in other words, the team events suggested by Scrum. Here is a mapping of these flow metrics that can be used in these events:
Here are some more details:
- Sprint planning mainly uses bandwidth to create a realistic forecast for the Sprint backlog. Work item age can be relevant when you have some items left over from a previous Sprint and want to decide what to do with them.
- Focus of Daily Scrum is an ongoing process within the Sprint, so of course what we’re interested in is what’s happening right now. Therefore, the current WIP and the age of the work item are the most important indicators in the Daily Scrum.
- Sprint overview includes stakeholder review of both incremental and overall team behavior—trends in cycle time and throughput are interesting. Throughput can also be used as part of release planning/path mapping discussions, especially in combination with Monte-Carlo simulations, which provide better visibility/confidence in “What can be done by when”. NOTE: It is always important to emphasize that these are projections/predictions, not commitments.
- Sprint retrospective it is based on checking and adjusting processes and workflows. So it’s a good place to look at WIP, cycle time, and throughput from the perspective of looking for areas for improvement.
This article introduced flow metrics that any team, whether using Kanban, Scrum, native process, DevOps, or even traditional waterfall, can use to see and accelerate/improve workflow. I also presented some ideas on how to weave these flow metrics into the team’s routine.