If you, along your journey, have worked or had any contact with Kanban, you have probably heard of the CFD chart, right?
The CFD Chart, or Cumulative Flow Diagram, is a tool applied in Scrum and Kanban methodologies. Despite being well known, CFD is a chart whose interpretation may not be carried out superficially.
Therefore, today we will explain the concepts of CFD charts with practical examples so you can extract their full potential.
It is worth mentioning here that the CFD does not usually bring answers, but rather provides valuable insights so that you can delve into the root cause of the identified problems.
Keep reading and find out more about what CFD charting is, main concepts and chart patterns in everyday life.
What is a CFD chart in Scrum?
The CFD (Cumulative Flow Diagram) is a graph capable of visually identifying different bottlenecks or dysfunctions that your team may be facing on a day-to-day basis. Many consider it one of the most important graphs in flow management.
This graph provides basic information about the workflow, such as: Amount of work already completed; Amount of work in progress; Delivery rate, etc.
This way, it is possible to identify more complex problems. One of the main objectives of CFD is to clearly show how stable your workflow is and where you can take action to make it more efficient and predictable.
What is CFD for in Scrum?
The CFD Chart (Cumulative Flow Diagram) is used to monitor the progress of activities carried out by the team in the Scrum methodology. Thus, it allows everyone to monitor the progress of work in real time, which makes it easier to identify possible bottlenecks and problems that could harm the progress of the project.
With it, it is possible to know whether the workflow of a Kanban team is stable or not.
The CFD also serves to measure the team's efficiency in relation to the established objectives and defined deadlines, thus allowing adjustments and improvements to be made to guarantee the delivery of the final product on time and with the desired quality.
How to read a CFD chart?
Before starting to analyze some everyday situations in projects, we will introduce CFD and its main concepts.
Below, see a simplified illustration of a CFD: CFD Chart Example — Credits: Kanbanize Building a CFD chart for Scrum is simple: On the horizontal axis, we have the timeline, which you can choose to represent in days, weeks, sprints, etc; On the vertical axis, we have, in an accumulated form, the number of tasks in the process over time.
Each of the curves represents a stage of the workflow as they appear on the team's own kanban board (backlog, in development, in testing, finished, etc.).
The CFD chart is also cumulative: each of the curves can only increase or, in the worst case, maintain its value if there is no movement at that stage. If you see any curves falling on the Y axis, something is wrong.
The upper line of the curve will represent the entry point of the tasks at that stage of the flow, while the lower line shows the task output from that stage.
Just based on this, it is possible to extract some very interesting metrics.
For example, by drawing a parallel line between the top line of the “backlog” stage curve and the top line of the “ready” stage curve, you will have the amount of time an item took to complete from the moment it entered production. your backlog.
In other words, your lead time. According to the image below, carrying out a very similar analysis, you will arrive at other metrics such as cycle time, WIP, amount of work yet to be done, among others.
Visualization of Metrics in CFD — Credits: Mauricio Fritsch What are the common CFD scenarios?
A very simple and practical way to analyze how stable your workflow is through CFD is by analyzing how the different graph curves are progressing.
At this point, there are some very common patterns to highlight: When CFD curves are progressing in parallel: Pattern 1 — Curves progressing in parallel — Credits: Kanbanize This scenario would be considered ideal for a stable and fluid workflow.
The fact that the different curves are progressing in parallel means that you have a workflow where the team can produce at a stable speed in the different stages and new tasks enter the flow stages at the same rate as tasks that are leaving it.
In practice, you will hardly see a CFD chart as beautiful and stable as this one on a daily basis.
But this can also be good news, as it's when things aren't going so well that you'll have the greatest learning opportunities with CFD.
When one of the graph's curves is widening rapidly: Pattern 2 — Curves widening rapidly — Credits: Kanbanize This scenario represents a typical situation in workflows. The range that is widening in the CFD tells us that the number of items being worked on simultaneously at that stage is increasing.
In other words, the items are leaving the stage at a slower speed than the speed at which they enter.
But what is happening in the team's day-to-day life for the graph to have this behavior? Is CFD able to answer questions like this? The answer is no.
CFD will help you identify that your workflow has a problem, which, in this case, could be caused by different reasons.
Tasks may be piling up due to locks, context switches, pressure for more tasks to run in parallel, among other reasons. You will need deeper investigative work to get to the root cause.
In the scenario in question, a good approach would be to promote a reduction in the WIP limit of the stage that is swelling, in addition to making sure that the team is really focusing its efforts on completing the items that are already in the stage before starting other tasks.
One of the curves on the CFD chart is rapidly narrowing: Pattern 3 — Curves narrowing rapidly — Credits: Kanbanize This situation points to a scenario opposite to that presented previously. When a curve appears narrowing on the CFD chart, it means that the quantity of activities at that stage is decreasing, that is, the quantity of items leaving that stage is greater than the quantity of incoming items.
A possible approach to this scenario would be to think: is the WIP of the stage in question not higher than necessary? Couldn't the workflow be optimized if more effort was being put into some other stage?
When one of the curves presents staircase behavior: Pattern 4 — Stairs — Credits: Pawel Brodzinski In this scenario, it is possible to observe that the number of items in the testing stage grows continuously, but they are not being completed, as the “done” curve does not follow the same growth.
When you see a CFD chart where there are curves with this ladder behavior, this is probably linked to very large items being worked on.
Very large items will spend a lot of time being developed and a considerable amount of time being tested and validated before they can only then be considered complete.
The same scenario can happen in situations where work is accumulated to be validated only at the end of a cycle or close to the delivery date, instead of being continuously tested, validated and delivered.
Another hypothesis would be that testers are taking much longer than expected to complete the tests because they are finding a large number of bugs, for example.
Again, as mentioned other times, we may not know the root cause, but we know where to start investigating.
When all CFD curves have straight lines: Pattern 5 — All Curves with Straight Lines — Credits: Pawel Brodzinski Well, the interpretation of this situation is somewhat obvious. If there is a flat curve in a straight line, it means work is stuck at that stage of the workflow.
In this scenario, we have three different stagnant curves. In other words, the entire flow is stagnant.
Again, the root cause of the problem may not be one, but several: the first and most obvious would be to check if there were holidays, if people on the development team were on vacation or other events that prevented the team from working.
A different hypothesis is the existence of other reasons preventing the team's work from progressing. For example, very large items worked on with a long completion time may be the case.
In a scenario like this, possible approaches would be to investigate the existence of blockages that are blocking the workflow. After identifying them, it is important to take action to remove them or even investigate whether the team is working on very large items. In this case, the ideal would be to break them, if possible, into smaller items.
In the scenario in question, regardless of what the reason for the stagnation was, after a while the situation was resolved, as it is possible to see the curves progressing again.
When only some curves have straight lines: Pattern 6 — Some Curves with Straight Lines — Credits: Pawel Brodzinski Very similar to the previous scenario, the difference is that, in this case, stagnation is occurring in only part of the flow.
In this case, while the development stage seems to be progressing well and as expected, the testing stage and the completion of items stopped progressing at a given moment and did not resume the normal pace, signaling the non-resolution of the problem until that moment.
Considering that the pace of development remains normal, a strong hypothesis here would be that there is a problem occurring specifically in the testing stage, with the testers or with the testing environment itself, for example.
As the items cannot be tested, they will not be delivered. Therefore, the “done” curve is also stagnant.
When faced with a CFD of this type, a few things can be done. The first of these would be, as in the previous case, to investigate the reason for the blockage at the stage in question.
Another possibility would be to analyze whether people are not working in isolation and whether better teamwork would be efficient in unlocking this flow.
When the curves on the CFD chart show declines: Pattern 7 — Lines Descending — Credits: Pawel Brodzinski We have reached our last example scenario. Here, we have a clear situation of something that definitely should not be happening within your project.
Curves going down means that there were items being worked on within your stream that either came back in the stream or simply disappeared.
It's a classic example of when there is some dysfunction happening within the flow. It can also be explained by canceled deliveries/projects or by giving up on continuing to work on a certain item, which probably means that the team discovered late that the item in question no longer made sense within the project.
A tip, in this case, would be to assess whether your team has the habit of returning items in the flow and whether this is the best approach.
Some people may do this with good intentions when they want, for example, to pass the item in question to another person within the team.
An example would be a tester who finds a bug and wants to pass the item back to the development stage to fix the bug.
This type of approach may not be ideal, as, in addition to generating this type of dysfunction, when returning the item to a previous stage it is possible that the item loses priority compared to other tasks already in development.
The most appropriate approach, depending on the case, would be to keep the item in the testing stage and inform a developer that a bug has been found which is preventing the release of the item and whose correction needs to be prioritized.
What metrics are possible to view from a Scrum CFD?
From the CFD chart, it is possible to view several metrics, such as: Lead time: the time it takes for a given task to go from “To Do” to the “Done” column. It is possible to see the evolution of lead time over time and identify which factors contribute to increasing or reducing it; Throughput: the number of tasks completed in a given period of time; WIP (Work in Progress): the number of tasks in progress at each stage of the process; Cycle Time: the average time to complete a task, from start to finish; Average waiting time: the average time a task sits in a given column before being moved to the next. These metrics are essential for evaluating the efficiency of the software development process and identifying possible improvements.
Still have any questions about the CFD chart?
