Note: After reading this post, you may find these posts of interests as well:
“Bottlenecks – Revisiting the Reading of Cumulative Flow Diagrams” dated 11/27/2012
“Are You Just an Average CFD User?” dated 02/21/2014. Also, Dan Vacanti has also captured and expanded in greater detail on much of the topics touched on in this post, in his book titled “ActionableAgile.”

During our Agile Denver Kanban SIG’s September meeting, we revisited the previous month’s discussion on the “basics of reading cumulative flow diagrams.” I captured our initial questions and a brief summary of our discussion a few days later to post on our SIG’s LinkedIn site. However, I felt there was a bit more “food for thought” from our discussion to capture.

This post is the “expanded summary” inspired by our past two recent SIG meetings. If you’re relatively new to CFDs and still find the basics of reading them a bit puzzling, I hope these questions and the “walk-through style” responses help clear up a few things. If you see something that “smells” wrong or have an interesting insight, let me know that too!

First Things First!

If you’re completely new to CFDs, here are two links we used to “kick-off” our SIG’s discussions.

The first link is to a Slideshare post by Zsolt Fabok, on the basics of kanban. Check out slide 27 in particular though for a high-level visual and description of a CFD first.

The second link is to a blog post by Håkan Forss, where he does a great job showing step-by-step how to create a simple CFD using MS-Excel. This should help you get started creating your own but more importantly, even if you don’t create your own going forward, seeing and understanding the basic mechanics of creating one should help your understanding of them.

Wait, one quick question first, what is lead time, and what is cycle time, and how do they differ?

Lead time vs Cycle time – at a basic level “lead time” for a work item includes queue (waiting) time in a To-Do (or Ready) process state; it’s the time from when the work item enters the ToDo process state, progresses through the Doing process state, and enters the Done process state. Lead time is likely of most interest to stakeholders or customers, as from their perspective the “clock” started with the request for the desired work item. In contrast, “cycle time” starts when the development team “pulls” the work item from the ToDo state and begins actual “work” on it, but it includes any “wait times” too as the work item is worked on in the Doing process state until it enters the Done process state.

Note: the Doing process state can be further sub-divided into several sub-Doing or even sub-Todo/sub-Doing process states but these sub-Doing process states are typically considered part of the overall Doing process state and part of “cycle time.”

Also, one person’s lead time can be considered cycle time by another based on the context, perspective, and the level of the work item. For example, a stakeholder may only be concerned with “feature level” work items and from their perspective, a feature’s “cycle time” started with efforts to prepare the feature for placement into the development team’s ToDo queue. But from the developer’s perspective they have not “started” the feature until it is “pulled” from their ToDo queue so any time in their ToDo queue is considered part of the feature’s overall “lead time” but not part of its “cycle time.”  As work proceeds, the requested feature work item is also likely broken into a set of smaller work items (ex. stories), and tracking lead and cycle times for the “parent” feature work item is done along with also tracking lead and cycle times for individual “child” story work items. In essence, any child story work item lead time is part of its parent feature work item cycle time. Another point to consider is a development team may consider a work item “done” at an earlier date than stakeholders or customers whose “done” often means in the field and may include a “warranty/bake-in time” period.

Confused? Clearly, any meaningful conversation related to lead vs cycle time requires both a “basic” understanding of the difference and a shared context and perspective on when request time starts, when work time starts, when work is done, as well as what level of the work item is being discussed. In many software development contexts, it is beneficial to measure and track the average and variation for both the lead and cycle times for one or more levels of work items.

Okay, now on to “basics of reading CFDs.”

How do you “read” WIP from your CFD?

WIP (Work in Progress) – is read for a point in time from a CFD by obtaining the arithmetic difference between the # of items for any two process states in your workflow. Keep in mind that WIP could be of interest at a specific workflow process state, or across several adjacent or all workflow process states.

In a simple case for a CFD charting ToDo, Doing, and Done states, the WIP at some point in time across the workflow would be read as follows (see chart below, click image to enlarge, and note I choose to run my CFDs with latest dates appearing on the left and earliest dates scrolling “off” to the right, you’ll see it reversed most often, but it’s a preference, not required):

1. Draw a vertical line (rise) up from a specific date of interest (a time interval along the x-axis) crossing the Done charted line, crossing the Doing charted line, and intersecting the ToDo charted line.
2. Draw a horizontal line (run), from the point where your vertical line intersects the ToDo charted line, parallel to the time intervals along the x-axis until it intersects the # of items along the y-axis.
3. In a similar fashion, from the point where the vertical line intersects the Done charted line, draw another horizontal line back to the # of items along the y-axis.
4. Where these two horizontal lines intersect the y-axis, read the # of items charted, and the arithmetic difference between these two #s is your WIP for the point in time where your vertical line is drawn up from your x-axis. In this example, WIP includes work items “waiting” to be pulled from the ToDo state and work items “actively” being worked in in the Doing process state of the workflow.

Figure 1 – CFD WIP

In the example above, to identify WIP just for the Doing state, draw a horizontal line as per step three but from the point where your vertical line crosses the Doing charted line.

There are other ways to track and measure your WIP at a point in time, but for some, the visual form of the CFD can be an impactful (easier) way to see useful trends. However, to be clear, this exercise shows how to compute the WIP at a specific point in time on the CFD. We “read” the queue length at a point in time for the work items “in progress”, that is in our example here, the total number of work items in ToDo waiting to be pulled into Doing along with those in the Doing state already being worked on but not yet completed. This is not an average queue length for the process state over a period (span) of time. Can we get an approximate average WIP (queue length) for a process state over a period (span) of time of interest using the CFD? If so, how? Stay tuned; I’m thinking (maybe depending on the response from this post) a walk-through style “deeper dive into CFD basics” post might be useful and fun to do too.

How do you “read” lead time (or cycle time) from your CFD?

Lead time – staying with a CFD as described above for WIP, the lead time is read for a point in time by obtaining the arithmetic difference between # of days (units of time) for the Done and ToDo states (see chart below) as follows:

1. Draw a vertical line (rise) up from a specific date of interest (a time interval along the x-axis) up to where it intersects the Done charted line.
2. Draw a horizontal line (run), from the point where your vertical line intersects the Done charted line and parallel to the time intervals along the x-axis until it intersects the ToDo charted line (going in a direction back in time, again, noting my preference to run my CFDs with latest dates appearing on left and earliest dates scrolling “off” to the right).
3. Draw a second vertical line (rise) down from the point where your horizontal line intersects the ToDo charted line to the time interval plotted on the x-axis.
4. Where the two vertical lines intersect the x-axis, read the two dates (or week # or month # depending on how you’re charting and reporting time intervals), and the arithmetic difference between these two “dates” (or units of reporting time intervals), is the approximate average lead time for those items completed by the specific date (date of interest) where your first vertical line intersected the x-axis.

In the CFD below I chose to use two-week (14 days) time intervals identified by year, quarter, and sprint # and tracked the end dates for each. So in this case I could subtract dates to get my approximate average lead time but I also can see from the chart there are nine two-week intervals (9 x 14 = 126 days). In this example, the work items that were completed by end of interval 2010-Qtr3-S4, you can see on average about half of their lead time (4 to 5 of the nine two-week intervals) was “wait time” in the ToDo state before being pulled into Doing.

Figure 2 – CFD Lead Time

In the example above, to approximate “average cycle time” for stories completed, draw your second vertical line as per step three but from the point where your horizontal line intersects the Doing charted line.

How do you read throughput or ACR from a CFD?

Average Completion Rate (ACR) – staying with the CFD as described above, you can consider work item count along the y-axis CFD as “rise” and time along the x-axis as “run” and use them to calculate a “slope” that approximates the average completion rate (throughput) at a time interval of interest as follows:

1. Along the x-axis go forward in time, from a specific time interval of interest, one or two time intervals (if your time intervals are single days, you might need to go forward in time a few more, like six or eight), then draw a vertical line up until it intersects the Done charted line.
2. In a similar fashion, do this going backward in time, from your specific time interval of interest, again one or two time intervals as you did in step one, then draw a vertical line up until it intersects the Done charted line.
3. Where these two “new” vertical lines cross the x-axis, read the two dates, and the arithmetic difference between these two “dates” (units of time) is the run (the time delta or “difference”).
4. Draw a new horizontal line from the point your first “new” vertical line intersects the Done charted line, parallel to the x-axis until it intersects the y-axis.
5. In a similar fashion, draw a new second horizontal line, from the point your second “new” vertical line intersects the Done charted line, parallel to the x-axis until it intersects the y-axis.
6. Where these two “new” horizontal lines intersect the y-axis, read the two numbers (# of work items), and the arithmetic difference between these two is the rise (the # of work items delta or “difference”).
7. The approximate ACR (throughput) at the specific time interval of interest, is the number from step 6 (# of work items) divided by the number from step 3 (# of days or time units you’re using for your intervals), and your units for this new number will be # of work items completed per unit of time (these are the units for ACR or throughput, for example, stories per day or features per week, etc.).

Figure 3 – CFD ACR

You can approximate “average arrival rates” (AAR) for work items at any process state in your workflow in a similar manner. For example, the AAR for items being pulled into Doing from ToDo would be done in a similar fashion as computing ACR above but you would use the Doing charted line rather than the Done charted line. The AAR for items being submitted into the ToDo process state would use the ToDo charted line and follow similar steps.

What is a desirable CFD?

We ended our discussion on the basics of reading CFDs talking some about what we thought might be desirable to see over time in our CFDs and came up with the following.

1. Ideally, you first like to see over time the chart lines on your CFD become more or less parallel. Why? This indicates that ACRs and AARs between the process states in your workflow are becoming synchronized, and demand is becoming inline with a capacity between process states through your workflow. Why is having the ACR (capacity) and AAR (demand) closely synchronized in your process a good thing?
2. Then, over time you like to see the gaps between chart lines get narrower acknowledging that your context may (or will) determine how narrow a gap can get between process states. Why? This would indicate our WIP at more points in time is decreasing. What does decreasing WIP in your process indicate?
3. Finally, over more time, you like to see the chart lines increase together in slope. Why? This would indicate increasing ACR and ARR relatively in sync with each other. What does ACR (capacity) and ARR (demand) increasing together over time indicate about your process?

Closing thoughts!

If the above “expanded summary” from our Agile Denver Kanban SIG discussions helped you better understand the basics of reading CFDs, it would be helpful (and appreciated) to hear from you and learn how (or what is still puzzling). I’m also interested in learning if a follow-up “deeper dive into CFD basics” walking through some of the unanswered questions above and a few others like the following would be of interest or helpful for you.

I’ve heard of Little’s Law but how does it relate to CFDs and more importantly to my process?

I’ve heard of “steady-state” too, but what does it mean and related to CFDs and my process why is it important?

Take care,

Frank