Control progress with the cumulative flow diagram

Along with diagrams like Gantt charts, burn up charts and burn down charts, the cumulative flow diagram can also be used to control your work progress.

With this diagram, you can determine, amongst other things, how long it will take to develop a feature, and how many there are in the current development so that bottlenecks can be avoided. It already sounds very promising. But how does it work?

Basic principles of the cumulative flow diagram

The cumulative flow diagram is just a plane diagram and a frequently used technique in Kanban because it visually presents the “flow” of tasks (requirements, user stories, etc.) from one state to the next. The x-axis represents the time (for example, in days) and the y-axis represents the amount of tasks or their workload. Then the amount of tasks and the states they are in is entered daily. Different curves emerge over time, through which it is possible to – depending on your level of development – recognize potential dangers to your project and derive countermeasures.

To maintain an overview, don’t present all possible states of requirements or user stories in the diagram – because sometimes that can be more than ten. In a cumulative flow diagram the editing states are condensed into “higher” states and only these are displayed on the cumulative flow diagram. At the very least, the states in backlog, in realization and completed should be there. Of course, the names of these and the states that they contain is up to you. What is important is that you precisely define the states and what counts as done for a task.

Cumulative Flow Diagram: States

Example of the states that are visualized together in a cumulative flow diagram.

The top curve is your guideline because it visualizes how many tasks are in the backlog at a particular point in time. The other curves get closer and closer to this one over the course of the project until they meet at the end: all the tasks have been implemented.

Should you measure the number or workload of the tasks?

As mentioned, the y-axis can measure either the number or workload. Why are there these two options?

Measuring the number is recommended for small projects where there are not thousands of requirements to deal with. Measuring the workload is interesting to those who carry out large projects and work with features. Because theoretically, you have to break these down carefully into requirements, which often does not happen during the project. If you do that, do the number of requirements really correspond to the reality of the project? Here it is better to measure the workload than the amount of tasks.

But if a feature has been dismantled into individual requirements, another challenge emerges: Does the cumulative flow diagram present the development of features or of the corresponding requirements? Or both? Measure the workload on the y-axis so that you can, for instance, fix the workload of a feature and visualize the development independent of its requirements.

Key figures from the cumulative flow diagram

The cumulative flow diagram determines three key figures as estimated values:

  • Date of completion
  • Lead Time (“How long will it take to implement a feature?”)
  • Work in Progress (WIP) (“How many features have already been implemented?”)


Cumulative Flow Diagram

Read the lead time and work in progress (WIP) in the cumulative flow diagram.

As mentioned at the beginning, these can be used to detect potential problems in the project. Because different conclusions can be made depending on the position of the lines. For example:

If all the curves become flat at the same time, then it might be because of public holidays where no one worked. What if there wasn’t a public holiday and your colleagues weren’t all on holidays at the same time? Then you have to find out why the project developed like this at this point. Maybe everyone was working on another, more critical project. Or maybe a technical problem was responsible.

Notice: The cumulative flow diagram does not provide clear answers on the state of your project, but rather starting points that you have to pursue yourself. But these starting points are useful. Pawel Brodzinski nicely describes other available interpretation options [1]. Or take a look at our knowledge base.

Conclusion: Use a suitable tool

To be able to use the cumulative flow diagram, you have to regularly record the current state of your tasks and enter them in the diagram as data points. A lot of work, you are dealing with a lot of requirements that might be in paper form or in an Excel table. So it is best to use a tool that supports you with this.

With our software solution objectiF RPM, you can create a central place to collect all your tasks and to document the progress of development. Through this, diagrams like the cumulative flow diagram can also generate existing project data with a click. Another advantage of objectiF RPM is measuring tasks through the number or the workload, to be able to control the progress of projects of any size. The tool also offers more project controlling options like the burn down and burn up charts as well as the classical and the agile earned value analyses.


Does this sound promising? Then click here to get acquainted with project controlling with objectiF RPM.

Or get started straight away with an online test.



[1]: Pawel Brodzinski (2013). Cumulative Flow Diagram. From Software Project Management – Lean, Agile and Kanban retrieved from

You can find more information about the cumulative flow diagram and other themes concerning project management, application lifecycle management and requirements engineering on our website in the Knowledge Base.

Lisa May is a part of our marketing team. She is interested in making new, interesting or curious knowledge entertaining and easy to understand. As a professional technical writer and translator, she can not only write in German, she can also reach our English-speaking readers.

0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *