Team Services | TFS 2017 | TFS 2015 | TFS 2013
You use cumulative flow diagrams (CFD) to monitor the flow of work through a system. There are two CFD charts, the one viewed from the Kanban board and the one you access by adding the CFD widget to your dashboard.
Feature availability: The CFD widget is available only for Team Services at this time.
The CFD widget provides more configuration options than those supported by the default CFD charts shown on the backlog and board pages. With the CFD widget, you can monitor the count of work items as they progressively move through various states which you define. You can configure the CFD chart to monitor the flow of epics, features, user stories, product backlog items, or requirements, depending on the process (Agile, Scrum, or (CMMI) you've selected.
View the cumulative flow chart (Kanban board)
You open the cumulative flow for your backlog or portfolio backlog by clicking the image in the upper-right corner of the Kanban board page.
The CFD shows the count of items in each Kanban column for the past 30 weeks or less. From this chart you can gain an idea of the amount of work in progress and lead time. Work in progress counts unfinished requirements. Lead time indicates the amount of time it takes to complete a requirement once work has started.
A few options are available for you to configure your chart.
Sample charts and primary metrics
The two primary metrics to track, cycle time and lead time, can be extracted from the chart.
The Continuous flow CFD provides the chart most favored by teams that follow a lean process.
However, many teams have begun combining lean practices with Scrum or other methodologies which means they practice lean within the span of an iteration or sprint. In this situation the diagram takes on a slightly different look and provides two additional, and very valuable, pieces of information as shown in the next chart.
|Continuous flow CFD
The Fixed period CFD shown here is for a completed sprint.
The top line represents the scope set for the sprint. And, because the work must be completed by the last day of the sprint, the slope of the Closed state indicates whether or not a team is on track to complete the sprint. The easiest way to think of this view is as a burnup chart.
The data is always depicted with the first step in the process as the upper left and the last step in the process as the bottom right.
|Fixed period CFD for a completed sprint
CFD charts display the count of work items grouped by state/Kanban column over time. The two primary metrics to track, cycle time and lead time, can be extracted from the chart.
|Cycle Time 1||Measures the time it takes to move work through a single process or workflow state, calculated by the start of the given process to the start of the subsequent process.|
|Lead Time 1||For a continuous flow process: measures the amount of time it takes from when a request is made (such as adding a proposed user story) until that request is completed (closed).
For a sprint or fixed period process: measures the time from when work on a request begins until the work is completed (i.e. the time from Active to Closed).
|Work in Progress||Measures the amount of work or number of work items that are actively being worked.|
|Scope||Represents the amount of work committed for the given period of time. Only applies to fixed period processes.|
- The current CFD implementation does not provide discrete numbers on Lead Time and Cycle Time.
Feature availability: For Team Services, you can add a Cycle time widget and Lead time widget to your dashboard. You need to first install the Analyics Marketplace extension. You can then add the widgets to your dashboard. You must be an account owner or a member of the Project Collection Administrator grou to add extensions.
There is a very tight, well defined correlation between Lead Time/Cycle Time and Work in Progress (WIP). The more work in progress, the longer the cycle time which leads to longer lead times. The opposite is also true—the less work in progress, the shorter the cycle and lead time is because the development team can focus on fewer items. This is a key reason why you can and should set Work In Progress limits on the Kanban board.
The count of work items indicates the total amount of work on a given day. In a fixed period CFD, a change in this count indicates scope change for a given period. In a continuous flow CFD, it indicates the total amount of work in the queue and completed for a given day.
Decomposing this work into specific Kanban board columns provides a view into where work is in the process. This provides insights on where work is moving smoothly, where there are blockages and where no work is being done at all. It's difficult to decipher a tabular view of the data, however, the visual CFD chart provides clear evidence that something is happening in a given way.
Identify issues, take appropriate actions
The CFD answers several specific questions and based on the answer, actions can be taken to adjust the process to move work through the system. Let's look at each of those questions here.
Will the team complete work on time?
This question applies to fixed period CFDs only. You gain an understanding of this by looking at the curve (or progression) of work in the last column of the Kanban board.
In this scenario it may be appropriate to reduce the scope of work in the iteration if it's clear that work, at a steady pace, is not being completed quickly enough. It may indicate the work was under estimated and should be factored into the next sprints planning.
There may however be other reasons which can be determined 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 this is to look at the spacing between the different columns on the chart. Are they of a similar or uniform distance from each other from beginning to end? Does a column appear to flat-line over a period of multiple days? Or, does it seem to "bulge"?
Two problems show up visually as flat lines and as bulges.
Flat lines appear when the team doesn't update their work with a regular cadence. The Kanban board 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 for. For this to occur, flat lines must appear across many parts of the system because if only one part of the system or two parts of a system have problems then you'll see a bulge.
Bulges occur when work builds up in one part of the system and it isn't moving through a process.
An example of this may be that testing is taking a long period of time but development is taking a short period of time therefore work is accumulating in the development state (bulges indicate that a succeeding step is having a problem, not necessarily the step in which the bulge is occurring).
Mura, the lean term for flat lines and bulges, means unevenness and indicates a form of waste (Muda) in the system. Any unevenness in the system will cause 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.
How do you fix flow problems?
You can solve the problem of lack of timely updates through daily stand-ups, other regular meetings, or scheduling a daily team reminder email.
Systemic flat-line problems indicate a more challenging problem (although you should rarely if ever see this). This problem means that work across the system has stopped. This may be the result of process-wide blockages, processes taking a very long time, or work shifting to other opportunities that aren't captured on the board.
One example of systemic flat-line can occur with a features CFD. Feature work can take much longer than work on user stories because features are composed of several stories. In these situations, either the slope is expected (as in the example above) or the issue is well known and already being raised by the team as an issue, in which case, problem resolution is outside the scope of this topic to provide guidance.
Teams can proactively fix problems that appear as CFD bulges. Depending on where the bulge occurs, the fix may be different. As an example, let's suppose that the bulge occurs in the development process because running tests is taking much longer than writing code, or testers are finding may be finding a large number of bugs and continually transition the work back to the developers so the developers have a growing list of active work.
Two potentially easy ways to solve this problem are: 1) Shift developers from the development process to the testing process until the bulge is eliminated or 2) change the order of work such that work that can be done quickly is interwoven with work that takes longer to do. Look for simple solutions to eliminate the bulges.
Because many different scenarios can occur which cause work to proceed unevenly, it's critical that you perform an actual analysis of the problem. The CFD will tell you that there is a problem and approximately where it is but you must investigate to get to the root cause(s). The guidance provided here indicate recommended actions which solve specific problems but which may 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 because a sprint is pre-loaded with the work to do on the first day, this becomes a set level of work. Changes to this top line indicate worked was added or removed.
The one scenario where you can't track scope changes with a CFD occurs when the same number of works are added as removed on the same day. The line would continue to be flat. This is the primary reason why several charts should be used in conjunction with one another to monitor for specific issues. For example, the sprint burndown chart can also show scope changes.
Too much work in progress?
You can easily monitor whether WIP limits have been exceed from the Kanban board. However, you can also see monitor it from the CFD.
Not so oddly, a large amount of work in progress usually shows up as a vertical bulge. The longer there is a large amount of work in progress, the bulge will expand to become an oval which will indicate that the work in progress is negatively affecting the cycle and lead time.
A good rule of thumb for work in progress is that there should be no more than two items in progress per team member at any given time. The main reason for two items versus stricter limits is because reality frequently intrudes on any software development process.
Sometimes it takes time to get information from a stakeholder, or it takes more time to acquire necessary software. There are any number of reasons why work might be halted so having a secondary item to switch to provides a little bit of leeway. 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 will have difficulty context switching, are more likely to forget what they were doing, and likely incur mistakes.
Configure the CFD chart (Kanban board)
Each team can set their preferences for the cumulative flow charts for their Kanban boards.
Open the Board page for the backlog level for which you want to configure and then open the common configuration dialog. Click the gear icon.
If you're not a team admin, get added as one. Only team and project admins can customize the team Kanban boards and CFD charts.
Click the Cumulative flow tab and specify the team's preferences.
Repeat steps 1 and 2 for each backlog level you want to configure.
Configure the CFD widget
Feature availability: For Team Services, you can add the CFD widget to your dashboard. You need to first install the Analyics Marketplace extension. You can then add the widget(s) to your dashboard. You must be an account owner or a member of the Project Collection Administrator group to add extensions.
You will need to be a team administrator or a member of the Project Administrators group to perform these tasks. See Manage team assets to get added as a team admin.
If you want fixed scope CFD charts, make sure that you've defined the sprint iterations for those sprints of interest.
To add a CFD chart to your team dashboard, see Add a widget to a dashboard. Add the Cumulative Flow Diagram widget.
Click the configure icon to open the configuration dialog. Modify the title, and then select the team, backlog level, swimlanes, and time period you want to monitor.
For a continuous flow diagram, select Rolling period and specify the number of days you want to view on the chart.
Or, for a fixed scope view, choose and specify the Start date. Choose this view if your team employs a Scrumban process or follows a standard sprint process.
The main difference between these two types of CFD charts is that the fixed scope CFD will provide information (in most cases) of scope change.
Choose the color. You can distinguish the CFD for different teams by choosing different colors.
Click Save when done. The following image shows an example CFD chart showing 30 days of data.
For the CFD chart to reflect useful information, you'll want to update the status of work items to reflect progress as it occurs. The quickest way to make these updates is through your Kanban board.
For additional information, see these resources:
Plan and track
Switch team project or team focus
Remember that the CFD chart is based on data collected for a specific team.
You navigate to your team context from the top navigation bar. The method changes slightly depending on the platform/version you work from and the features you have enabled.
To switch your team focus, see Work in the web portal, Switch team project or team focus.