Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020
Cumulative flow diagrams (CFDs) help you monitor your work process by visualizing the flow of work through your system. This article explains how to use CFDs, cycle times, and lead times to identify issues and improve workflow efficiency.
- To set up or view a CFD, see View and configure a cumulative flow diagram.
- To add a lead time or cycle time control chart to a dashboard, see Lead Time and Cycle Time widgets.
- To set up or view a CFD, see View and configure a cumulative flow diagram.
- To add a lead time or cycle time control chart to a dashboard, see Lead Time and Cycle Time widgets.
The continuous-flow CFD is the chart most teams that follow a lean process prefer.
But many teams combine lean practices with Scrum or other methods. They use lean practices during an iteration or sprint. In this case, the diagram looks a bit different. It shows two extra,The continuous-flow CFD is the chart most teams that follow a lean process prefer.
But many teams combine lean practices with Scrum or other methods. They use lean practices during an iteration or sprint. In this case, the diagram looks a bit different. It shows two extra, valuable pieces of information, as shown in the next chart, the fixed-period CFD.
Continuous-flow CFD
This fixed-period CFD shows a completed sprint.
The top line shows the scope set for the sprint. Because the work needs to finish by the last day, the slope of the Closed state shows if a team is on track. Think of this view as a burnup chart.
In the chart, the first step in the process is in the upper-left area. The last step is in the bottom-right area.
Fixed-period CFD for a completed sprint
Chart metrics
CFDs show the count of work items grouped by state or column over time. The two primary metrics for tracking are cycle time and lead time. You extract these metrics from the chart.
Metric
Definition
Cycle time 1
The time it takes to move work through a single process or workflow state. Measure the length from the start of one process to the start of the next process.
Lead time 1
For a continuous-flow process: The time from when a request is made (like adding a proposed user story) until that request is completed (closed).
*For a sprint or fi For a continuous-flow process: The time from when a request is made (like adding a proposed user story) until that request is completed (closed).
For a sprint or fixed-period process: The time from when work on a request begins until the work is completed (for example, the time from the Active to the Closed state).
Work in progress (WIP)
The amount of work or number of work items that are actively in progress.
Scope
The amount of work committed for the given period. This metric only applies to fixed-period processes.
1 The CFD widget that uses Analytics data and the built-in CFD that you can view from a team backlog or board don't provide discrete lead time and cycle time values. However, the Lead Time and Cycle Time widgets do provide these values.
There's a clear correlation between lead time or cycle time and WIP. More WIP leads to longer cycle times and longer lead times. The opposite is also true—less WIP leads to shorter cycle and lead times. When the development team focuses on fewer items, they reduce cycle and lead times. This correlation is a key reason to set WIP limits on the board you use to track and manage work.
The count of work items shows the total amount of work on a given day. In a fixed-period CFD, a change in this count means a scope change for that period. In a continuous-flow CFD, it shows the total amount of work that's in the queue and completed for a given day.
Categorizing work into specific board columns shows the amount of work in each area of the process. This view gives insight into where work is moving smoothly, where there are blockages, and where no work is being done. It's hard to understand a tabular view of the data, but the visual CFD helps you see what's happening in your work process and why.
Identify issues and take appropriate actions
The CFD provides answers to the following questions. Based on the answers, you can adjust the process to move work through the system.
Will the team complete work on time?
This question applies to fixed-period CFDs only. You can gain an understanding by looking at the curve (or progression) of work in the last column of the board.
In this scenario, you might consider reducing the scope of work in the iteration. This action is appropriate if it's clear that the work isn't being completed quickly enough, assuming it continues at a steady pace. This scenario can indicate that the work was underestimated and should be factored into the next sprint's planning.
However, there might be other reasons the work isn't being completed quickly enough. You can determine those reasons by looking at other data on the chart.
How is the flow of work progressing?
Is the team completing work at a steady pace? One way to tell is to look at the spacing between the various columns on the chart. Are they of a similar or uniform distance from each other from beginning to end? Do any columns appear to flatline over a period of multiple days? Or do any seem to bulge?
Mura, or unevenness, is the lean term for flat lines and bulges. Mura indicates a form of waste (Muda) in the system. Any unevenness in the system causes bulges to appear in the CFD.
Monitoring the CFD for flat lines and bulges supports a key part of the Theory of Constraints project management process. Protecting the slowest area of the system is referred to as the drum-buffer-rope process and is part of how work is planned.
Two problems show up visually as flat lines and as bulges.
Flat lines appear when the team doesn't update the status of their work items with a regular cadence. The board that you use to track and manage work provides the quickest way to transition work from one column to another.
Flat lines can also appear when the work across one or more processes takes longer than planned. Flat lines appear across many parts of the system because if only one or two parts have problems, you see a bulge.
Flat lines
Bulges occur when work builds up in one part of the system and doesn't move through a process.
For example, a bulge can occur when testing takes a long time but development takes less time. The result is that work accumulates in the development state. Bulges indicate that a succeeding step is having a problem, not necessarily the step in which the bulge is occurring.
Bulges
How do you fix flow problems?
You can solve the problem of a lack of timely updates by taking the following actions:
- Holding daily stand-ups
- Holding other regular meetings
- Scheduling a daily team reminder email
Systemic flat-line problems indicate a more challenging problem, although such problems are rare. Flat lines indicate that work across the system is stopped. Underlying causes can include the following issues:
- Process-wide blockages
- Processes taking a long time
- Work shifting to other opportunities that aren't captured on the board
One example of systemic flat lining can occur in a features CFD. Feature work can take longer than work on user stories, because features are composed of several stories. In these situations, either the slope is expected (as in an earlier example), or the issue is well known and the team already raised it. If it's a known issue, the problem resolution is outside the scope of this article.
Teams can proactively fix problems that appear as CFD bulges. The fix that's appropriate can depend on where the bulge occurs. As an example, suppose that the bulge occurs in the development process. The bulge might be happening because testing is taking longer than writing code. Testers might also be finding a large number of bugs. When they continually transition the work back to the developers, the developers inherit a growing list of active work.
There are two potentially easy ways to solve this problem:
- Shift developers from the development process to the testing process until the bulge is eliminated.
- Change the order of work. Specifically, interweave work that can be done quickly with work that takes longer to do.
Look for basic solutions to eliminate the bulges.
Note
Because various scenarios can occur that cause work to proceed unevenly, it's critical that you perform an actual analysis of the problem. The CFD can tell you that a problem exists. It can also tell you approximately where the problem is, but you must investigate to get to the root causes. This guidance provides recommended actions that solve specific problems, but the solutions might not apply to your situation.
Did the scope change?
Scope changes apply to fixed-period CFDs only. The top line of the chart indicates the scope of work. A sprint is preloaded with the work to do on the first day. Changes to the top line indicate the addition or removal of work.
In one particular scenario, you can't track scope changes with a CFD. That scenario occurs when the same number of work items are added and removed on the same day. The line stays flat in this case.
To track scope changes in this case, take the following actions:
- Compare several charts with one another.
- Monitor specific issues.
- Use sprint burndown to monitor scope changes.
Is there too much WIP?
You can easily monitor the board to determine whether WIP limits are exceeded. You can also monitor WIP levels by using the CFD.
A large amount of WIP usually shows up as a vertical bulge. The longer that there's a large amount of WIP, the more the bulge expands into an oval shape. This behavior is an indication that the WIP is negatively affecting the cycle and lead time.
Here's a good rule of thumb for WIP: There should be no more than two items in progress per team member at any given time. The main reason for using a limit of two items, not a stricter limit, is that reality frequently intrudes on the software development process.
Sometimes it takes time to get information from a stakeholder or to acquire necessary software. There are any number of reasons why work can be halted. Maintaining a second work item provides operational flexibility during unexpected delays. If both items are blocked, it's time to raise a red flag to get something unblocked—not just switch to yet another item. As soon as there are a large number of items in progress, the person working on those items can have difficulty switching context. It's likely that they forget what they were doing, which can lead to mistakes.
Lead time versus cycle time
The following diagram shows how lead time and cycle time differ. Lead time starts when a work item is created and ends when the work item enters a Completed state category. Cycle time starts when a work item enters an In Progress or Resolved state category and ends when it enters a Completed state category.
If your team uses a board to track and manage work, understanding how your columns map to workflow states helps you manage work more effectively. To learn how to set up your board, see Manage columns on your board.
To learn how the system uses the state categories—Proposed, In Progress, Resolved, and Completed—see About workflow states in backlogs and boards.
How cycle time handles reactivated work items
For work items that are reactivated (moved from a Completed state back to an In Progress state), cycle time starts from the first time the work item enters an In Progress or Resolved state category and ends the final time it enters a Completed state category. Cycle time includes the entire active work period, including any time after reactivation.
Example scenario:
- New → Active → Resolved → Closed → New → Active → Closed
- Cycle time calculation: From the first transition to Active to the final transition to Closed
- Total cycle time: Includes both active work periods and the time in Closed state before reactivation
This calculation method gives a complete picture of the total time needed to finish the work item, including any rework or extra effort after reactivation. Lead time calculation follows the same principle—it covers the entire period from work item creation to final completion, regardless of any intermediate completed states.
Estimate delivery times based on lead and cycle times
Use your average lead and cycle times and standard deviations to estimate delivery times.
When you create a work item, use your team's average lead time to estimate the completion date. The team's standard deviation shows the variability of the estimate. Likewise, use your cycle time and its standard deviation to estimate when a work item finishes after work begins.
Example Cycle Time widget
In the following chart, the average cycle time is eight days and the standard deviation is six days. With this data, estimate that the team completes future user stories about 2 to 14 days after work begins. A narrower standard deviation makes your estimates more predictable.
Identify process issues
Outliers often mean there's an underlying process issue. For example, waiting too long to review pull requests or not fixing an external dependency quickly. Check your team's control chart for outliers.
Example cycle time widget showing several outliers
The following chart shows several outliers because some bugs took longer than average to finish. Checking why these bugs took longer can help you find process issues. Fixing process issues helps reduce your team's standard deviation and improves your team's predictability.
You also see how process changes affect your lead and cycle times. For example, on May 15, the team worked to limit the WIP and fix stale bugs. The standard deviation narrows after that date, showing improved predictability.