Menu
Last updated on
Plutora Blog - Agile Release Management, Deployment Management, DevOps, Release Management, Value Stream Management

A Product Manager’s Guide to Reading Cumulative Flow

Reading time 7 minutes

The role of a product manager can be overly taxing if core responsibilities are left to chance. This is exactly the reason that a cumulative flow diagram exists. It’s the one chart from which all crucial metrics can be deduced. When explained, a cumulative flow diagram can help you manage the C-suite’s perceptions. Then again, you have to be able to read cumulative flow diagrams for them to spark sense. 

This post will guide you toward being able to look at a cumulative flow diagram and make useful deductions. We’ll be using the case of a software application product manager to build on the synopses herein. 

Before setting up our ephemeral project, let’s kick things off with a formal definition of a cumulative flow diagram. Shall we? 

Quality software releases at scale with Plutora

Plutora provides a complete toolkit for application delivery. Schedule releases , track dependencies and maintain compliance while accelerating change.

Learn More

What Is a Cumulative Flow Diagram?

In all its easy-to-dread colorfulness, a cumulative flow diagram is a pictorial display of how easy tasks progress through a workflow. To fully grasp the concept of a cumulative diagram, let’s split it down into its components, with our software project in mind. 

We’ll imagine three stages for each task along a workflow: 

  1. Planning (backlog)
  2. Active (in progress)
  3. Complete (done)

Let’s plot point a line on a task/time graph with each task that goes through the stages above causing an uptick.

We’d result in something like this:

Diagram: A task vs. time chart
Diagram: A task vs. time chart 

As you can tell from the chart, week 1 saw the spring of a single task (0 to 1). Assuming this task doesn’t end, another one was then added during week 3. The trend goes on. This plot would be awesome as a cumulative task counter. At week 9, we can quickly tell that five tasks have been added to our developers’ backlog.  However, this plot only covers phase 1 of the way tasks evolve. 

If we were to track another attribute, say tasks in action, and superpose the plot onto the same diagram, we’d come up with something like this:

Diagram: Cumulative tasks, and active tasks plot
Diagram: Cumulative tasks, and active tasks plot

Two things have happened since our introduction of the second phase (tasks in progress). First, we have new numbers registered by the first line of just tasks. A confusing perception of this is to say new tasks have been added. That’s not true. We can always count the number of tasks as they accumulate by noting the gap between the two plotted lines.

Accumulated Task Count

The integer value obtained from the difference between plotted lines. 

Looking at our charts so far, and focusing on week 5 as a measuring point, the first diagram showed three tasks (and counting). The second diagram has the upper line flat on 5 and the lower line on 2. See where we’re going with this? 

Reaction Time (R)

The time it takes for a planned project to start being acted on.  

The second change is that we have a different starting time for the second phase. This is actually expected since tasks can lie dormant for weeks before they become active. This difference is the reaction time, represented by R in the second diagram. 

At this point, we can already tell how many tasks have been created from the time our graph starts. A good product manager would also start recognizing patterns in reaction time. Wait and see what happens when we add the last stage of the workflow.

Rection time

Once all the workflow stages have been plotted, we start to appreciate a few more signs from the resulting diagram. 

  • Cycle time: The lifespan of an active task (active to done).
  • Work in progress (WIP): The number of tasks in progress.
  • Tasks completed (T.D): The number of tasks confirmed as complete at the time of measuring.
  • Lead time: The time it takes for a task to go through all stages of a workflow.

You can refer to this article for an in-depth talk about lead time and cycle time. Now that you can tell one colored area from the next, let’s get into what each change tells you to do. 

Decoding a Cumulative Flow Diagram

The decision process set alight by a cumulative flow diagram often affects the actors immensely. They can speed up delivery time and even improve the quality of work produced. Let’s go over a few scenarios and decode what they imply for your workflow. 

To start with, the cumulative flow diagram and its lines are always on an upward trend. The opposite would mean your tasks are entering a black hole. This would indicate a glitch in the process of monitoring and recording tasks as they progress. When this happens, halt and look for lost tasks. 

Optimizing the Cycle Time

Being the period during which value is added to your product, it’s worth investing attention to how tasks evolve in it. While the diagram neglects to show how many members of your team are working on a task, you could fluctuate that variable and see how the cycle time changes over time. 

The idea here is to make the flow as smooth as your resources allow—like water flowing down a channel. So, remove any impediments along the way. You should also eliminate idle time that could be elongating the cycle time unnecessarily. If too many approvals are in the way, optimize the checks and remove redundancies for better throughput. 

Throughput is measured by the gradient of the Done plot. The steeper the line, the faster your tasks are being completed, and the smoother your process flow. 

Monitoring the Delay Time

“Delay” itself is unattractive when managing a product. The fact that your cumulative flow diagram has it should not be a worrying sight—unless, of course, there’s a growing time lapse between projects being planned and action commencing. It’s worth investigating just why this may be so. Possible reasons include not having enough resources for a project to get the attention it needs and even a rigid process flow that restricts timely activity. All of these findings can emerge from observing the cumulative flow diagram for a few minutes. 

Monitoring the WIP Gap

Remember the WIP gap? That’s the distance between the done line and the task-active plot. A healthy workflow either maintains or narrows this gap with time. The inverse would signal a growing number of tasks without any exit activities. Your staff could get choked by tasks if you let that proliferate. A widening WIP gap often means it’s a good time to hire more actors. 

Tools to Measure Cumulative Flow

After reading to this point, the next cumulative flow diagram you see will reverberate a lot of insight without making you squint your eyes. However, as you can imagine, the measuring tool for such a feat would have to be plugged into every metrics counter in your organization. 

This implies an enterprise-wide application integration strategy. Daunting, but possible. The more systems in use you’re tapping into, the more accurate your cumulative flow diagram. 
An accurate cumulative flow diagram can only be the result of an elaborate value stream flow monitoring effort. One such solution is the Value Stream Flow Metrics in Plutora. In the case of our imagined software application development house, all the applications along the value-infusing process would pour data into an aggregator for central processing and presentation.  

Taurai Mutimutema

Taurai is a systems analyst with a knack for writing, which was probably sparked by the need to document technical processes during code and implementation sessions. He enjoys learning new technology, and talks about tech even more than he writes.