In the first part of Getting to 85 – Agile Metrics with ActionableAgile we looked at the Cycle Time Scatterplot as generated by ActionableAgile software. That piece also discussed some ideas the scatter plot could bring about and conversations that potentially might occur.
Let’s take a look at another important chart and set of metrics the ActionableAgile can produce based on sample or custom loaded data – Cumulative Flow Diagram (CFD).
In the nutshell, CFD is a stacked area plot, with time scale (usually days) shown along the X axis and number of work items along the Y axis. And here comes the first surprise for Scrum practitioners. That is correct, we are plotting just the number of items in each category, stacking them upon one another. Not their value, or story points associated with an item. One item counts as 1 on the Y axis.
This immediately brings up an argument, that the chart might be useless as we always deal with items of different size and complexity, items that need different effort to complete. Kanban gives a simple answer – it does not matter. Well, almost. It does not matter as long as items are right-sized.
Now we will get into almost a chicken and egg discussion, what comes first, estimation of work, or getting work done and realizing its actual duration. In Scrum we usually right-size our items, ensuring that they fit into a Sprint. Some might use story point to check their Sprint Backlog “what” part against the team’s capacity. Others might skip story pointing altogether, task backlog items and estimate tasks in hours. There are many ways teams do their estimations. I would argue it doesn’t matter much. If you right-size your Product Backlog Items (PBI) and achieve a shared understanding of the work, you are good.
On the other side of the spectrum there’s a camp of #NoEstimators (annoys heck out of me since lately this camp seems to have turned into a #NoEverything camp, but that’s for another story). Those profess that since estimations are usually quite bad (and they mostly are) and way too time consuming for the results they produce, the estimation process itself is a gross waste of time.
CFD Agile Metrics for Estimation
Kanban proposes a different way, which is quite useful for Scrum practitioners as well (those who practice Professional Scrum with Kanban at least). You start with a several items estimated at your Sprint duration or less. The estimation conversation might be as simple as, “do we think we can complete this PBI within this sprint?” If the answer is yes, the item gets pulled into the Sprint Backlog. The estimation is over. Then start working and flowing items across your board, getting them to Done.
Executed properly, with Work in Progress (WIP) limits in place, you will start collecting Cycle Time data in no time. Depending on the size of the items, team capacity, and, therefore, team’s throughput, you might get enough data to calculate reasonably reliable percentiles we talked about in the previous article in no time.
Remember, that percentiles give us the ability to add valuable probability data to the date range in which a team can complete a right-sized item. How might that data be useful for Scrum teams? For example, during next Sprint planning the team might want to replace its definition of right-sizing (a PBI that fits into a Sprint) with the one where a PBI could be done within a number of days with 85% probability (hopefully that comes under your Spring duration, otherwise we face a problem).
There is an even better method Scrum teams could use estimating a number of items that could be completed within a Sprint. That is the Monte Carlo simulation and that one I will reserve for another post. Back to the CFD for now.
CFD Numbers and What They Mean
Let’s take a look at a zoomed-in part of the diagram and talk about all those numbers. In the screenshot above there are four of them. The vertical line for 20190119 shows 35 items. This is the number of items in progress on that specific day – pretty simple. Just count all the items that you have on your board between the commitment and done points and you get that number.
The horizontal line that reads 8 days is a bit more complex. If you ever find yourself in the same room with Dan Vacanti talking about metrics, I would recommend, for your own safety, never ever call that number Cycle Time. He will go ballistic and inflict the unconstitutional pain and suffering upon you (he won’t but just imagine he would and never do it).
Referring to that number as the Cycle Time is plain wrong for a simple reason. Think of the way we build this chart. Every day we count the cards on the board between the commitment and done points and mark corresponding numbers on the Y axis. As time goes by, we get these nice colored areas.
Look at the dot by the call out that reads 8 days (that date is 20190111). The team started some items on that day and completed some on 20190119. What we cannot tell and do not know if those completed items are same items that the team started on 20190111. Maybe they are, but most likely they are not. Unless you set your WIP Limit to 1 for the whole system (and in the example above that is not the case) we cannot tell for sure.
What we see on the horizontal line and what 8 days label represents is the Average Approximate Cycle Time. We average the data from some items that we know moved through the system in 8 days. We can conclude that on average, an item that we completed on 20190119 took approximately 8 days to get done.
How does that compare with our 85% estimate? Quite favorably actually. The latter, if you remember, stood at 16 days. What this means, is that an average item the team completed between 20190111 and 20190119 took less time than our 85% confidence estimation. This should not shake your confidence in the data provided by the scatterplot though. With a specific point on the CFD we are looking at a point in time snapshot, while scatterplot derived percentiles are calculated using the whole of data set.
Last, but not least, let’s look at 2 more data points the CFD provides, arrival and departure rates. Those are correspondingly 3.16 and 3.63 items per day. On the time interval presented in the diagram the team on average started 3.16 items per day and completed 3.63 items. What it tells us, is that the work in progress between the leftmost and rightmost data points decreased. The team on average was completing its work faster than starting the new work. Thus, the lines that represent arrival and departure rates are converging (it’s not quite prominent in the diagram since the difference between the arrival and departure rates is small).
Are We Missing the Bigger Picture Here?
If we zoom out for a moment and take a look at the first screen shot, we will notice that rates of arrival and departure stood there at 2.70 items/day and 2.88 items per day correspondingly. The arrival and departure lines are diverging quite prominently.
This might tell us a few things about the system. Firstly, we see that team’s WIP is growing. Secondly, it tells us that the system is not in the stable state – something is going on there. If I were to make an educated guess, I would assume that some of the items are flowing through the system faster than others and Little’s Law assumptions don’t might not hold (if you are curious about Little’s Law and what those assumptions are I invite you to read Dan’s book, which someone referred to as a treatise on the topic).
The ActionableAgile provides an option to dig even deeper into the data and look at your WIP and approximate average Cycle Time by stage as shown in the screenshot above. This might be an opportunity to take a stab at Muda kind of wastes. For example, Analysis Done stage took 2 days, which is twice as long as the Analysis stage took. The work waited to be tested for a day, which was as long as it took to do the actual development. Are there any improvement opportunities there? I believe so.
I was thinking of covering the Aging Work in Progress chart in this post as well, but the post became quite long already. In the next post I will discuss the Aging Work In Progress metric and its corresponding chart, and then will write a post on forecasting using Monte Carlo simulation built into the ActionableAgile software.