A Cumulative Flow Diagram is my favorite information radiator, especially at the team level. I love just how many discussion points they can generate and the level of insight they can provide. They clearly indicate current status of a sprint as well as trends over time, so I often include CFDs in executive briefing presentations as well.
As an Agile coach, who may or may not be in tune with a team’s day-to-day activities, I find these diagrams to be more useful than the burndown charts in understanding a team’s work process. I’ve often used the sprint’s CFD to jump-start a retrospective with excellent feedback.
Since we are talking about visual information displays, below are two CFDs for one of my former teams. The relatively experienced Scrum team was working on web-based software development projects in two-week sprints.
Please note that as with any information radiators or metrics, they should serve as a starting point for discussions, not as an absolute measurement especially without context! So I’m including these just to illustrate the kind of observations obtainable from a cumulative flow diagram, not to diagnose specific causes or for team assessment.
A quick guide for the diagrams:
- the horizontal axis displays time, in business days and the vertical axis displays story points
- the colors indicate state of the user story where Orange = To Be Started; Yellow = Development; Blue = Completed (inc. testing) and Green = accepted
- The team completed all of their sprint commitment, but on story had not been accepted by the product owner within the sprint. If memory serves me right, the product owner was unavailable the last day of the sprint and accepted the story next morning, but …
- The team was able to start delivering quite early in the sprint. This could either indicate that there was a story carried over from the previous sprint or that team was able to swarm and complete stories very quickly.
- The blue is rather limited, indicating that there was not a large waiting time for the product owner to accept stories that the team had completed, so good partnership!
- Obviously, the team had either taken more work mid-sprint or had work injected as illustrated by the increase in the overall height
- The orange bloc indicates that the team was swarming on a few stories, rather than each person starting to work on a different story.
- In this sprint, the team had started working on most of the stories by day two, indicating lower degree of swarming, though the cause is opaque at this level.
- Compared to the first CFD, this one indicates that the team spent more concentrated time in development stage, perhaps because the stories were more complex
- The first story was still completed between days 4 and 5 which is good for a Scrum team since we don’t want to have all work completed and accepted in the last rush
- The team did take on more work but was able to get all work completed and accepted within the sprint.
- There is slightly larger blue bloc indicating some time gap between a story’s development completion and the product owner’s acceptance; could just be the time available in the PO’s schedule to test the story and get any concerns addressed.
I’ve seen even experienced Agilists express some unfamiliarity with Cumulative Flow Diagrams, so hope this post can provide some encouragement.
As far how to create them, these particular CFDs were automatically generated in Rally, and Version One and most other ALM tools can do the same. I know ScrumMasters who have used Excel to generate CFDs, but I will leave that to the Excel whizzes, of whom I am most definitively not one!