The Cumulative Flow Diagram (CFD) is an extremely valuable management report. It gives you an “at a glance” picture of key process variables such as velocity, WIP and ticket cycle times. It can help you release more features faster by identifying bottlenecks and problems in your development process.
In Assembla it takes less than a minute to generate a CFD with your own ticket data.
In this blog post we will show you how to create a CFD, measure velocity and find bottlenecks in your development process. In the next post we will discuss cycle times and how the CFD can warn you about scope creep and other process problems.
Generate Your CFD
Cumulative Flow Diagrams are one of the management reports available as part of the Assembla Tickets tool.
To create a Cumulative Flow Diagram based on your ticket activity, just
- Click on the Tickets tab.
- Click on the Metrics subtab.
- On the list of reports, click on Cumulative Flow Diagram
- Select the Milestone, Start Date and End Date and click the Update button
What is on This Graph?
You will see a graph that looks somewhat like the one below. It shows the number of tickets in each of you status categories, for the milestone and the time period you have selected.
If you draw a horizontal line at any point on this graph you will see a snapshot of your tickets on a given date (how many with status “New,” “In-Progress,” “Test,” etc.). In fact, if you move your cursor along the top boundary of any layer a popup box will list the number of tickets in that category on each date.
So the CFD is really just a picture of your tickets by status over time. But this picture can tell you a lot about your development process.
Note: In your graph the shape of the layers may differ from Figure 1 depending on whether your development process is based on iterations and sprints, or on a continuous flow. You can see “ideal” Cumulative Flow Diagrams for Scrum, ScrumBan and Kanban processes in Andy Singleton’s blog post: Scrum + Kanban = ScrumBan, an Easy Scrum Upgrade.
The Departure Rate (Velocity) Helps You Project Completion
The bottom layer on the graph (usually labeled “Fixed,” or “Done” or “Completed”) shows the number of finished tickets at different times. The upper boundary shows the cumulative number of tickets completed or “burned up” in the iteration or milestone.
The slope of this line is the “departure rate”; that is, the average number of tickets completed per time period. In Kanban and other flow process this is usually called the “velocity” (in this diagram measured in tickets completed rather than points). Either way, it is a measure of throughput and productivity.
The departure rate can help you estimate:
- The time needed to complete the current milestone.
- The time and resources needed to complete future projects with a given number of tickets.
Of course, these estimates are not going to be exact, because different tickets require different amounts of work. But over time they should average out and let you make rough projections. (Also, if you have a few very large tickets you should try to find ways to break them up into smaller ones.)
In addition, changes in the departure rate might indicate problems with your development process. For example, in diagram below, why were so few tickets completed between 2012/11/12 and 2012/11/26? There might be a good reason, but the CFD clues you in on where to look for possible issues.
By the way, the upper boundary of the top layer on the CFD represents new tickets arriving into the milestone, so the slope of that line is the “arrival rate.”
WIP Levels Show You Bottlenecks
Identifying and eliminating process bottlenecks is a critical element of continuous improvement.
In the diagram below, the red vertical line represents work in process: the cumulative number of tickets accepted into the process but not yet completed.
This information is useful because you can see how much work needs to be done at each level; for example how many tickets haven’t been started, how many are in progress, how many need to be tested, etc.
But even more important, you can see where your process developed bottlenecks. Those are at the places where a “boa constrictor” suddenly becomes fat. For example, in this diagram the “Deploy” layer goes from very thin to very thick between 12/11/26 and about 2012/12/07. It looks like something went wrong during this period and the imbalance in the process was only gradually worked out towards the end of the diagram.
Note that the cause of the problem may well be in the process step below the thick layer. In this diagram the bottleneck in the “Deploy” layer might have been caused by problems preparing new features for deployment, or by a constraint on actually deploying them and accepting them as “Fixed.” (If you “push” tickets, then the problem is likely to be in the fat layer; if you have a “pull” system it is probably in the lower or receiving layer).
The CFD makes it much easier to see when and where the bottlenecks started, so you can investigate the root causes and fix the underlying problems.
In our next post we will look at cycle times and how to the CFD can help identify scope creep.