Lean Metrics to Improve Flow

When it comes to supporting business outcomes, each Kanban system can provide value in a different way. So before you start applying metrics, it’s important to understand each system’s economics. Thinking about the questions below can help you determine which Lean metrics are right for your Kanban system.

What business outcomes does the system support?

Think of the revenue-generating programs and methods that drive your organization or team. Some real-world examples include: A marketing team creating a referral program to boost product adoption, a product development team building a new feature to distinguish the company’s product, or an operations team resolving issues to improve user experience.

What do I want to improve?

Identify improvements based on the value you deliver. Some real-world examples include: A marketing team might want to analyze their cycle time on creating sales collateral so they can deliver value more quickly, a product development team might want to improve their quality to prevent rework, and an operations team might want to track lead time so they can resolve issues more quickly.

Keep your answers to the above questions in mind as you read about the following set of flow metrics. Think about how the metrics apply to your system and how they could help you create economic value.

1. Work in Process or Work in Progress (WIP)

Tracking work items that are started, but not yet finished, can help you improve the overall flow of value through the system. Practically speaking, work cannot add value to the customer, team, or organization unless it’s finished work.

For example, think of a software development team that’s building a new feature for their company’s iOS app. The feature cannot add value to the app until it’s live for customer use. Therefore, it’s beneficial to keep tabs on work you’ve started so you can see how it relates to your system’s capacity.

In general terms, “WIP” refers to any work that has been started but is not yet providing value to the customer (i.e., “done”). WIP can be defined as “work in process” in some instances and as “work in progress” in others.

Work in progress is the total amount of work you have committed to but have not completed at any one time. Work in process, on the other hand, is all the work that is actively being worked on at any one time. Sometimes this distinction is useful, but often both terms are used interchangeably when referencing “WIP.”

If you’re new to measuring flow, start with work in process.

By counting and recording the number of unfinished cards (work items) in your system each week, you’ll gain a basic understanding of how much work is in process and therefore not yet providing value. WIP can be tallied in one of two ways, either by counting the applicable cards on your board or by using a cumulative flow diagram.

Key Takeaway: Be sure to clearly define what you mean by work in process and work in progress within your system, as it can vary for different use cases. Start tracking your current work in process by recording it on a weekly basis to analyze trends in the amount of work you have in process at any one time.

2. Queues

Queues form in your process when work waits between different stages. Since queues often represent the majority of a work item’s total life cycle, it’s important to understand how they affect your team and where they occur in your process. Limiting the time that work spends in queues can help reduce your overall cycle time and keep work flowing through the system.

An efficiency diagram measures the difference between total WIP and the work that’s waiting in queues. It illustrates when the work in queue is growing as a percentage of the total WIP. This allows you to pinpoint where work is likely stuck in a queue and also investigate what can be done to get work flowing again.

Key Takeaway: Identify the queues in your workflow so you can see where work could get stuck in your process. Track the amount of work you have in queues and try to minimize it, relative to the total WIP in the system. Shorter queues lead to shorter wait times and lower overall cycle time.

3. Blockers

Kanban systems commonly use a “blocker” symbol to visually indicate work that cannot move forward in the process. Different from work in a queue – which is often simply waiting its turn to be pulled into process – a blocker is typically waiting on an external dependency or some failure condition. Blockers double as a useful signal that a piece of work needs immediate attention and as a valuable flow metric.

Blockers are one of the easiest board elements to measure, especially for new teams that lack the work history necessary for other metrics. To get started, count how many items are blocked and record how long those work items stay blocked.

The insight you gain from measuring blockers allows you to look at ways to improve flow by reducing both numbers. Limiting the effect blockers have on your system can help improve your efficiency.

Key Takeaway: With or without a large amount of work history, blocked work items are easy to track and can provide opportunities for quick improvements in flow. Track both the number of work items blocked at a given time and how long they stay blocked.

4. Lead time and cycle time

Lead time and cycle time are two useful metrics for understanding how long work takes to flow through your Kanban system. These two useful metrics are similar and easily confused; both help us understand how long work takes to flow through our value streams, but they measure different segments of the process.

Lead and cycle time metrics are a great way to view trends. By tracking and comparing metrics over time, you can evaluate changes and forecast future work.

Lead Time: Lead time measures the total time it takes for work to move through the value stream, from the moment the work is requested to the time it’s delivered. Lead time measures duration from beginning to end. This includes process time, as well as time that work spends sitting in queues, or wait states.

By tracking lead time metrics over a set period of time, you can determine impact of any changes you make – whether they help you deliver value faster, or get in the way of delivering value to your customers.

Lead time helps you become more predictable by quantifying the probability of the percentage of work that will get done in a particular time frame.

For example, if an IT Operations team is performing routine system maintenance, it can measure its past performance to predict the lead time of its current work and provide accurate estimates for customer downtime. Without lead time metrics, any estimates given to the customer would be educated guesses, at best – and without tracking lead time on current work, teams would not know how to improve.

Cycle Time: Cycle time measures how long it takes a work item to get from point A to point B. Since cycle time can be measured from any two starting and ending points on the board, it’s common for several categories of cycle time to exist on one board (e.g., deployment cycle time, development cycle time, QA cycle time, etc.).

Let’s have a closer look: Assume we are working with a Kanban board in a mobile development team. The team is working on a new feature for its iOS app. A card is first created for review, then it is sent to build, then to QA, and then deployed. The cycle time is the amount of time it takes to work from the start of the stage to the next. In this example, there’s a cycle time between review and build; build and QA; and QA and deployed. The team can measure cycle times on each of the stages and experiment with ways to improve using their Kanban system.

Depending on the economic value you choose to measure, both cycle time and lead time can be applied directly to your team. For example, if you want to improve the delivery capabilities of your software development team, your cycle time measurement can track the time it takes a work item to go from the commitment point to deployment.

If, however, you want to improve the performance of a section of your process – such as QA – then measuring QA lead time gives you more specific insight into the flow of work through that portion of your system. The flexibility between lead time and cycle time allows you to improve specific components of your process so you can better impact overall efficiency.

Key Takeaway: To avoid confusion, define lead time and cycle time upfront and as a team. Select your metrics based on how your team creates value (e.g., time to market, higher quality, etc.) and the economic system in which you operate.

5. Throughput

Throughput is the average number of units processed per time unit. In a Kanban system, examples can include “cards per day,” “cards per week,” or “story points per iteration.”

Since knowledge work entails plenty of variability, throughput is important to track and define according to what impacts your economic system. Think about how an understanding of the average units processed per time period impacts business decisions and measure it accordingly. Consider the effect of outliers in your measurement, as one significant event can drastically change the entire average.

Because it is an average, throughput alone is not a very reliable way to forecast future delivery dates, except to make very short-term predictions (e.g., “Are we going to finish the items on the board by the end of the current sprint?”). It is more effective to view throughput either as a trend or by combining it with other metrics, such as cycle time and lead time.

Key Takeaway: Determine how your team will measure throughput based on your economic system. Once you make this distinction, you will be able to pair throughput with cycle time and lead time to get an advanced picture of your workflow.

6. Little’s Law in practice

A variation of Little’s Law is often used to calculate cycle time. The formula gives a hypothetical demonstration of how changes made to the system’s input can impact the system’s output. In this instance, Little’s Law shows how an increase in WIP can lead to an increase in the expected cycle time.

For example, if a team has 32 cards in process (i.e., their total WIP) and a throughput of 1.25 cards/day, then the average cycle time is 25.6 days. If the same team maintains the same throughput but increases its total WIP to 40 cards, the average cycle time becomes 32 days.

Little’s Law can be a powerful demonstration of how reducing WIP can reduce cycle time, which is often a valuable business benefit. (Note: You could also improve cycle time by increasing throughput, but increasing a team’s throughput is often more difficult in practice than reducing the total WIP.)

Key Takeaway: Little’s Law allows you to roughly predict the effect of allowing or reducing additional WIP into the system. It is important to pair this ability with an understanding of how changes in WIP and cycle time will impact the economics of the system when making key business decisions.

7. Cumulative flow diagrams

A cumulative flow diagram (CFD) is a graphical representation of your WIP as it flows through your Kanban system. The metric helps you understand the state of your current work and what might need to be done to speed up the pace of delivery.

In a CFD, each band of color represents a lane on your board, and the width (vertically) of that lane represents the number of cards in that lane. When plotted over time (the horizontal axis) you can see how the WIP in that lane changes. When WIP is decreasing, the lane narrows; however, when WIP is increasing, it starts to “bulge.” Drawing a vertical line from the edge of the “done” lane to the edge of the topmost lane will give you your total WIP at that point in time.

You can also draw a horizontal line from a given point to the edge of the “done” lane to get the average lead time from that point on your board. (See diagram below). If you connect those vertical and horizontal lines to form a triangle, (the slope of the line on the edge of the “done” lane”), you can see your average throughput, i.e., the rate at which you are getting things into “done.”

By creating burn-up lines based on the CFD, you can make rough predictions based on your WIP and Throughput. This allows you to estimate if you’re on track with your planned work and whether or not you can expect to finish the work in a set amount of time.

Using a burn-up on a CFD is similar to how a burn-down chart functions in the Scrum methodology, while providing additional flexibility. (Tip: Burn-ups work best when applied to a short time period; projecting an average over a longer timeframe will produce tidy, but highly inaccurate forecasts.)

Key Takeaway: A CFD provides quick, visual insight into the overall WIP in a system and how that WIP is flowing through the system. It can be used to calculate burn-up trajectories for work, as well as to provide a quick visual identification of where process bottlenecks may be forming.

With flow, the goal is more about consistently creating economic value than it is about having the fastest cycle time or highest throughput. Maintaining a steady flow of work through your Kanban system can help you deliver value more quickly and reliably to your customers, team, and organization.

However, achieving a favorable flow in your Kanban system doesn’t happen by accident. It takes time, knowing which Lean metrics fit best with your business outcomes, and continuously improving your process. Defining upfront the big-picture economics of your system will help you stay in sync with your business goals and focused on delivering value.