The simple cumulative flow diagram (CFD) used in Metrics: Cumulative Flow Diagrams – Basics introduces most of the concepts needed to read and use a CFD. However, software development, regardless of the size of the work or the method used, is more complicated. CFDs adapt to the true complexity of software development. CFDs allow teams and managers to visualize the flow of work .
An Example of Increased Complexity:
Context: In 2011, an application maintenance team built kanban board that included each of the major steps in their software development process.
The team was using a “kanban-y” version of Scrumban with planning and retrospectives every two weeks, but without any requirement to have an empty board (all cards complete) before the end of the two week period. Releases primarily occurred once a month when a group of features was completed, but could occur as work completed testing for critical items (interim releases were generally problem tickets).
Scenario One: A standard pace of work is shown in the CFD approximately four weeks after implementing their Scrumban approach. The team established an initial backlog of 137 stories (no additional stories were added during the timeframe, and many lower priority stories had not been groomed) of which 12 were in process and 7 had been completed. The CFD for this point in time is shown below:
At this point, the flow of work shows the backlog items flowing normally through the steps of the process to completion. For those of you that watch replays of sporting events late at night, you will recognize the first scenario as a ploy to introduce the standard ebb and flow of work before jumping forward to a point in the process where “stuff” happens.
Scenario Two: Approximately six weeks into the team’s use of Scrumban, they noticed a bottleneck between assignment (the triage level analysis in this group) and analysis, and more troubling between development tasks and testing.
While the team had set work-in-process limits due to time pressures and a lack of coaching they did not adjust roles when backups started to emerge. In retrospect, the team found that one of the coders who had been new to the team was really good at coding APIs and that a few of the functions being worked on had no automated testing facilities. This caused stories to begin to pile up waiting to be tested. The problem of stories piling up in the assignment category was a reflection of a lead developer that ignored WIP limits and starting to triage more stories than the analysis step could absorb and work on. The CFD let the team and management to visually identify evidence of the problems as they began to emerge and find solutions. The CFD two weeks later showed substantial improvement (below).
The team stopped starting new work for a period of time (reflected in the flat backlog) and shifted the technical lead to support code reviews and the testing process (they kept him busy enough that he would not fall prey to the urge to do more triage).
The examples shown here are a reflection of specific points in time. The team and their leaders were reviewing their CFD on a daily basis during their stand-up meetings. The CFD was easier to use than a classic Kanban board with WIP limits. The team was distributed across several time zones and two continents. The team held two separate stand-ups one in the US and one in India. The team passed an updated CFD to the other location at the end of the day so they could visually recognize progress. As we have seen in Metrics: Cumulative Flow Diagrams – Basics, CFDs are useful for showing and monitoring a wide range of metrics. Each of the metrics (velocity, throughput, cycle time to name a few) a CFD shows will be directly affected by the flow of work between the steps; therefore, adding the complexity of tracking work through the varied steps provides additional transparency and value to a CFD.