In my recent article, Sequencing Product Backlog, I used the shortest weighted processing time (SWPT) strategy to sequence a product backlog in order to minimize flow time and work in progress [1]. In that article, I defined four concepts needed to measure flow through the development process: flow units, flow rate, flow time, and work in progress (WIP) inventory. In this article, utilizing the same concepts, I will show you how to use the cumulative flow diagram (CFD) to visualize flow through the development process.
Measuring Flow
It is natural to consider a feature in the product backlog as the flow unit in the development process. To be precise, the flow unit is the task that is undertaken to develop the feature. However, not all features deliver the same monetary value. If we do not account for this, we end up comparing apples and oranges. To be able to aggregate our measurements across teams within an organization and across projects with varying types of features, we need to express the value of features in monetary units. In our analysis, we will treat flow units as both features and dollars. We will see that the value-based view of flow is more nuanced.
The rate at which flow units move through the development process in a specified amount of time is called the flow rate or throughput. The flow rate is bound by the capacity of the process, which is usually somewhat constrained by resources. We will start our analysis using a single-resource example, but then I will demonstrate how to relax that constraint.
The amount of time that a flow unit spends in a process or system is called the flow time. It includes the processing time (cycle time) needed to develop the unit, as well as any time the unit spends waiting to be developed. Typically, features are released for development at the start of a project or the start of a sprint. Flow time is the difference between the unit’s completion time and its release time. Wait time (or queue time) is the difference between the unit’s start time and its release time. Flow time is the sum of a unit’s wait time and processing time.
Work in progress (WIP) is an inventory measure. We can count the flow units in the process at any one point in time and average those numbers across the timespan of the project. The total number of units in the process is the sum of those waiting to be started and those actively being developed.
Generally, if we want to deliver the most value within the shortest amount of time, we want to limit the amount of WIP, decrease flow time, and increase flow rate, in some combination.
Little’s Law
The relationship between flow rate, flow time, and WIP is explained by Little’s Law [2][3][4]. It states that average flow time equals the quotient of average WIP and average flow rate. Table 1 defines the basic parameters and equations. LS is the average number of flow units in the process (not completed), and LQ is the average number of features waiting to be developed (not started). WS is average flow time, and WQ is average wait time. WS equals the sum of WQ and the average processing time. LS equals the sum of LQ and the average number of units actively being developed. The average number of units being developed concurrently is limited by the capacity of the process.
Table 1. Little’s Law parameters and equations.
Single-Resource Example
If there is only one resource, only one feature can be worked on at a time. Features will be executed serially. The resource Gantt chart and product backlog data for the example used in the aforementioned article are shown below.
Figure 1. Resource Gantt chart and product backlog data for single-resource example.
In the following figure, there are two cumulative flow diagrams (CFD’s). For the sake of this example, one is feature-based and one value-based. Each CFD has three curves. The top curve shows the number of units released for development. This is the total WIP. All five features were released at the start of the project, and the number of features available for development remained constant over the duration of the project. The inflow curve (middle) shows the cumulative number of started units. Each time a feature was started, the cumulative inflow curve was incremented. The outflow curve (bottom) shows the cumulative number of completed features. Each time a feature was completed, the cumulative outflow curve was incremented.
The vertical distance between the inflow and outflow curves represents the number of units (features or dollars) being worked during a given time. The vertical distance between the release and inflow curves represents the number of units waiting to be processed. The vertical distance between the release and outflow curves represents the total number of flow units in the process.
In the single-resource example where features are executed serially, the horizontal distance between a feature’s release time and completion time is its flow time, which includes the amount of time it took to develop the feature (its process or cycle time) and the amount of time the feature may have waited to start. The horizontal distance between the inflow and outflow curves is its processing time.
Figure 2. Feature-based and value-based CFD’s for single-resource example.
The CFD on the left above is based on the feature as the flow unit. There are five features that were completed over the 19-week span of the project. This represents a flow rate of 0.2631 features per week (5 features / 19 weeks). The average number of features being worked at any time was one since each feature was developed serially. The average feature processing time was 3.8 weeks (or 1 / flow rate). That is, a feature completed every 3.8 weeks on average. This is referred to as cycle time. Flow time is the difference between a feature’s release time and completion time. It represents the total time the feature was in process, including time waiting to be developed and then actually being developed. In this example, the average flow time was 8.2 weeks, which means that a feature had to wait 4.4 weeks on average before it was started. Over the span of the project, the average number of features either waiting to be started or being developed, was 2.1579. The average number of features waiting to be started was 1.1579.
The CFD on the right in the above figure is based on the dollar value of each feature. The flow unit is one dollar, and we track how each dollar flows through the process. The total value of the project upon completion was $212,000. The project spanned 19 weeks. The flow rate was $11,158 per week. The average dollar-value of features both waiting and in development was $68,263. This can be computed as the average of the sum of released but incomplete feature values per time period as it was in the article mentioned above [1]. Given the flow rate and average work in progress (WIP), the average flow time can be computed as 6.1179 weeks using Little’s Law. This means that it takes 6.1179 weeks on average between the time a dollar is invested and the time that a dollar of value is delivered.
Note that the average processing time and flow time of one dollar is less than that of one feature. In the single-resource example, we sequenced features in decreasing order of flow rate to provide more value sooner. You can see this in the value-based CFD, but not in the feature-based CFD. Furthermore, in the value-based CFD, note that 42% of the project’s duration is spent waiting on the completion of a feature that provides only 6% of the project’s total value. Perhaps it would be wise to drop that feature in order to complete the project with the remaining features sooner?
What Happens If We Double The Resources?
So far in our example, we have used just one resource. If we add another, our capacity is increased so that we can work two features at one time. Figure 3 shows the resource Gantt chart and product backlog data for a two-resource example. The sequencing of features is arbitrary here, but an attempt was made to complete all of the features in the shortest amount of time and preserve the original sequencing. The sum of the feature processing times is 19 weeks. Using two resources, the shortest possible time to complete the release is 10 weeks (with upward rounding). We can see that both resources are fully utilized except for the last period.
Figure 3. Resource Gantt chart and product backlog data for two-resource example.
The CFD’s for the two-resource example are shown in Figure 4 below. Note that the vertical distance between the inflow and outflow curves increased since more work is being performed concurrently. Also, note that doubling the number of resources cuts the project duration roughly in half. The average flow rate increased while WIP and flow time decreased. One should question whether the gain in accelerated value is offset by any additional cost associated with using a second resource.
Figure 4. Feature-based and value-based CFD’s for two-resource example.
CFD Interpretation
The CFD offers a visualization of a process’s WIP, flow rate, and flow time. The vertical distance between the released and inflow curves shows the number of units waiting to be processed. The vertical distance between the inflow and outflow curves shows the number of units being processed. The horizontal distance between the inflow and outflow curves shows cycle time. The horizontal distance between the start of the project (release time) and the outflow curve shows flow time. The slope of the inflow and outflow curves shows the flow rate.
If the slopes of the inflow and outflow curves are similar, then the two curves will be roughly parallel. This indicates that work is being processed at a stable rate. If the vertical distance between the curves increases, it means that more work is being started than is being completed in a unit of time. If the vertical distance decreases, it means that more work is being completed than started. If the horizontal distance between the curves increases, it means that it is taking longer to complete work that is started. If the horizontal distance between the curves decreases, it means that work is being completed in a shorter period of time.
In the feature-based CFD’s above, the inflow and outflow curves were mostly parallel since the flow rate was constant and limited by the number of resources being utilized. However, in the value-based CFD’s the value of the features being processed varies. The features were sequenced so as to achieve more value sooner, hence the flow rate generally decreased as the project progressed. This is an important aspect to consider, and one that is easier to see in the value-based CFD’s.
How Do You Use CFD’s?
What types of flow units do you track? What tools do you use to create CFD’s? In what ways have CFD’s helped you diagnose process bottlenecks or other process anomalies? Please share your thoughts and insights in a comment below.
References
[1] Nicklas, Robin. (2020, April 21). “Sequencing Product Backlog.” MPUG. https://mpug.com/articles/sequencing-product-backlog/.
[2] Reinertsen, Donald G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing. Pp. 71-75.
[3] Stevenson, William J. (2012). Operations Management, 11th ed. McGraw-Hill. Pp. 800-803.
[4] Cahon, Gerard and Terwiesch, Christian. (2013). Matching Supply with Demand: An Introduction to Operations Management, 3rd ed. McGraw-Hill Irwin. Pp. 15-19.
