4 Metrics Your Development Team Can Leverage To Visualize and Accelerate Flow

The Kanban Guide for Scrum Teams introduces four key flow metrics teams can use to see and improve their flow:

Work in Progress (WIP)

The number of work items started but not finished (according to the team's definition of "Workflow").

Note the difference between WIP and the WIP Limit. The WIP Limit is a policy that teams can use as a "constraint" to help them shape the flow of work. The goal of the WIP Limit is to reduce the amount of actual Work in Progress (WIP) — also known as Flow Load. The team can use the WIP metric to provide transparency into their progress towards reducing their WIP and improving their flow.

While teams can directly visualize the WIP levels over time (which I recommend), many use the Cumulative Flow Diagram to visualize the WIP.

Cycle/Flow Time

The amount of elapsed time between when a work item "starts" and when a work item "finishes."

This metric is a lagging indicator of flow. It is available only after an item is actually finished from the workflow perspective (e.g., it reached a Done lane 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 to visualize and analyze Cycle Times is the Cycle Time Scatterplot, where teams can understand their Cycle Time trends and distributions and look at anomalies.

Throughput

The number of work items "finished" per unit of time.

Note that throughput is the exact count of work items without compensation for item size — a major difference between throughput and story-points-based velocity. Throughput is measured at a certain step in the workflow, typically at the finish line of the workflow. Throughput can be visualized via a separate run chart or by looking at the angle of curves on a Cumulative Flow Diagram.

Work Item Age

For currently active items — The amount of elapsed time between when a work item "started" and the current time.

WIP and Cycle Time are classic metrics most Kanban practitioners are probably familiar with, and throughput is somewhat similar to Velocity.

Work Item Age is the new guy on the block. Work Item Age complements Cycle Time. If Cycle Time is a lagging indicator only relevant for finished items, Work Item Age is a leading indicator only relevant for non-finished items. The basic idea is to provide transparency to which items are flowing well and which are sort of "stuck" even if not formally blocked.

Many mature Kanban teams gravitate towards looking at aging information via a variety of reports or indications on their board. Over the years, the most serious Kanban tool vendors have introduced some ways to visualize card/item age.

Age on its own is interesting but not enough. We also want some indication of flow health. One common thing to visualize is the age of the current step in the workflow, also known as "cards that didn't move recently."

Another way to look at it would be to look at the overall age but combine it with where the work currently is in the workflow as well as what the team expects their cycle time to be (The Kanban Guide for Scrum Team refers to this as SLE — Service Level Expectation). Combining all this information can help the team focus on the items that are at the most risk of missing the team's expectations/SLE. For example, let's say a team has an SLE of 16 days with 85% confidence. If one of the cards on their board is 10 days old, is that okay? Is it a problem? The answer is that it depends. If that card is very close to the end of the workflow, it is probably not a problem. If it is very close to the start of the workflow, it is probably an indication of a problem that requires attention. The "Aging Work in Progress" chart below provides this perspective of both where active items are in the workflow, what the typical cycle times for this team are, and, based on that, which items are indications of flow risks (obviously orange-red means very low probability of finishing within the team's flow expectations).

To sum up, work item age is the best metric to look at if you want to determine when an item that has already started is going to be finished. This contrasts an item that hasn't started — where your best bet is your historical Cycle Times. The Service Level Expectation is just an expectation set by the team to themselves answering the question, "What Cycle Time do we expect to see for an item of this type, and what is our confidence level for this?".

Using the Flow Metrics in Typical Team Events

So, how can these flow metrics be leveraged in typical team events? Teams might use different events, but a typical set of events combines some planning activity, ongoing check-ins, a review of a working product increment, and a process retrospective/improvement session — in other words, the team events suggested by Scrum. Here's a mapping of these flow metrics that can be leveraged in these events: 

Here are some more details: 

• Sprint planning mainly leverages throughput to create a realistic forecast for the Sprint backlog. Work Item Age might be relevant when you have some items left over from the previous Sprint and want to decide what to do about them.
• The focus of Daily Scrum is the ongoing flow within the Sprint, so naturally, what we care about is what's currently going on. Therefore, Current WIP and Work Item Age are the most important metrics in Daily Scrum.
• Sprint review includes a review with stakeholders of both the Increment and overall flow behavior of the team—trends in Cycle Times and Throughput are interesting. Throughput can also be used as part of release planning/road-mapping discussions, especially when combined with Monte-Carlo simulations, which provide some better visibility/confidence into "What can be done by when." NOTE: It is always important to emphasize that these are projections/forecasts, not commitments.
• Sprint retrospective is all about inspecting and adapting the process and the workflow. Therefore, it is a good place to look at WIP, Cycle Times, and throughput from the perspective of looking for areas for improvement.

This article introduced flow metrics that any team, whether they're using Kanban, Scrum, home-grown process, DevOps, or even a traditional waterfall, can use to see and accelerate/improve the flow of work. I also introduced some ideas for how to weave these flow metrics into the team's routine.