Cumulative Flow Shows Where the Work Is

If you’ve only used Gantt charts or a Scrum board, you may never have seen where the work in a project is. A cumulative flow chart shows how much work is in which state. The following is a cumulative flow chart from a real team after three iterations. The team made slow progress. This chart explains why.

The product owner was working as an individual, churning out stories. He anticipated the team would need 30 stories to finish this short project. The team was confused about the work, so it had a number of stories in what it called Analysis.

During this review, the team met often with the product owner, as often as three hourly meetings each week. The more the team asked questions, the more it needed to bring in stories it would have to address later. That’s why the total number of features in Analysis rose during the three iterations.

The team tried to finish work. The developers fell into the trap described in ​Trap: Everyone Takes His or Her Own Story​. The testers had questions for the developers or the product owner; everyone was busy. That team saw its cumulative flow and decided it would attack that problem in its retrospective.

The next chart shows what happened after Iteration 3. The product owner learned that he had been creating feature sets instead of stories. That was okay, except the team couldn’t complete the entire feature set in an iteration—nor did he want it to. He continued to create his roadmap, finally finishing at 130 features. He still was ahead of the team, which is why that top stack of features is larger than what the team completed in any one iteration.

The team still worked a few iterations ahead with him on the features. It took the team a while to understand what a one-day story was for them. By about Iteration 7, they had a pretty good idea.

The team was still ambitious as to what the developers and the testers could complete in an iteration. It wasn’t until about Iteration 10 that the team started to pull work across the board instead of push it.

The testers remained “behind” the entire project. In the last three iterations, when the developers finished writing code, they helped the testers with test automation. That test automation uncovered defects, so the developers alternated between fixing and test-automation help.

At the final project retrospective, the team decided it would always use cumulative flow to track where the work was. It also decided to try WIP limits and see what happened if the team limited its WIP and watched its cumulative flow. One of the team members said, “Cumulative flow actually helped us work as a team. We could see who had which work—not a person, but which parts of the team.”

Note that in iteration-based agile approaches, I expect to see the cumulative flow—at least in Development and Testing—move to zero for each iteration. Sometimes the product owner works in advance, and that provides a look ahead for the team. But the team’s accumulated work goes to zero at the end of the iteration, because the team completes what it committed to.

Flow-based teams might always have a constant number of stories in the Ready column. That constant number will look like WIP. In addition, because the flow-based teams might not care about seeing the WIP decrease to zero for an iteration, those teams might have some small WIP (whatever their WIP limits are for their columns) for their cumulative flow chart. I advise teams to keep the WIP in development and testing close to zero so the teams finish more work than they start.