Home
Welcome to the FlowMetricsCSV wiki!
Here you find all the relevant information on how to use the visuals created with the script!
As an input, you'll need a CSV file that contains the "started date" and the "closed date" of your work items. You can find how-to's on how to create those CSV's for some work tracking systems in the wiki of the sister project MonteCarloCSV. The only difference is that you need two dates (start and close) for the flow metrics instead of just the close date that is needed for MonteCarlo.
Following you find a list of charts that will be created by the tool and how you can use them.
Whether you are a Scrum Team or not, this blog post will also share some details on how to use some of the charts you can create with the tool.
This chart plots the Cycle Time for each item in the selected history. On the X-Axis you can see the Closed Date of each item, while the Y-Axis is the Cycle Time of the specific item.
The Cycle Time is calculated as follows:
Cycle Time = (Closed Date - Start Date) + 1
The "+1" comes from the fact that we assume a cycle time of 1 day when an item is started and closed on the same day. That means the minimum Cycle Time is 1. Items that are not yet closed (no Closing Date) don't have a Cycle Time and will not be shown in this Chart.
The chart also includes four different percentile lines. By default 50, 70, 85, and 95, but you can configure them to your liking. They indicate how many items were closed in x days or less.
In this chart, you can see there is one outlier (20+ days). 85% of all the items were closed in 8 days or less, and 70% of all items were closed in 6 days or less.
You can use the chart to spot patterns (for example, are we closing many items on a single day, which would indicate some kind of bigger batches) or outliers (are there items that took way longer than the rest). Also, you can use the percentiles to give you guidance for Right-Sizing your work items. In the example above, you might decide with your team that the 85th percentile might be a good target for your team. You can set your "Service Level Expectation" (SLE) to this number, so you can communicate this also with stakeholders: 85% of all the items will be done within 8 days or less (once they are started). Instead of estimating time or effort (for example using Story Points), you can simply size the items by asking: Will we manage this in 8 days or less? If the answer is, you're good. If not, you might have discussions on how to achieve this or how it could be broken into smaller pieces.
This chart plots the Work Item Age for each item in the selected history. On the X-Axis, you can see the Start Date of each item, while the Y-Axis is the Work Item Age of the specific item. The scatterplot also includes the percentile lines from the Cycle Time. This is useful to spot when items are approaching our SLEs or are even already beyond them.
If items are started, but not yet finished, they won't have a Cycle Time. Instead, they have a "Work Item Age". The calculation of Work Item Age is done similar to the Cycle Time, but instead of the Closing Date, we take today's date:
Work Item Age = (Today - Start Date) + 1
Again we use the "+1" because the minimum age is 1 day. So as soon as we start to work on an item, its age becomes 1.
In this chart, you can see that quite a lot of items are beyond our percentile lines. There is one item that is in progress already 80 days, while two more are between 20 and 40 days in progress. A team should find ways to close those items first, before focusing on the items that are near the percentile lines.
A way to use this chart can also be to check it out during daily meetings (if you have them) and discuss the oldest items and how progress can be made on them. If you were to use the 85th percentile as SLE, you should start discussing how to close the item once it hits the 50th percentile line.
The chart shows the Throughput over the history specified. On the X-Axis you can see each day, while on the Y-Axis you can see how many items were closed on this day.
The run chart can help spot whether the team is using bigger batches to close items (for example everything gets closed at the end of a Sprint instead of continuously). The goal should be to have a steady Throughput with no big outliers in either direction. The more "even" this is, the more predictable your team is. This also serves as input for the Monte Carlo Simulation, if you run them. The more steady this is, the more precise your forecasts will work.
In the above example, you can spot that there are not many periods of days where nothing was completed. As weekends are included, some "gaps" are expected. Also towards the right side, you can see a bigger gap, but most likely this is due to the holiday break at the end of December.
And while there are some "outliers" where 4 or 5 items were closed on the same day, it seems that the work is flowing through rather steadily in this team.
This chart shows the total amount of Work In Progress over the specified history. On the X-Axis you can see each day, while on the Y-Axis you can see the WIP total for that day. One Kanban Practice is to "Controlling Work In Progress" and this chart helps you to spot outliers. Are we steadily increasing or decreasing WIP? It allows us to take action if we spot this, for example by saying that we don't start anything new until we're under a certain Threshold.
An item counts to the WIP if it's started but not closed, meaning it has a Started but no Closing Date.
In the above example, you can see that around the start of December, the WIP increased a lot, before slowly decreasing again.
This chart shows the total amount of items closed and finished per week. On the X-Axis you can see each week, while on the Y-Axis you can see the number of items closed for this week.
One assumption of Little's Law is that "Average arrival rate equals average departure rate". This means we should not start more than we finish (as we otherwise will continuously increase WIP). But also that we don't finish more than we start (as otherwise we eventually starve the process).
This chart helps to visualize how much we start and finish weekly.
In the above example, you can see that in the beginning more was started than finished for a couple of weeks, increasing WIP. This chart helps you take action if you spot trends like those, for example by triggering a discussion on what's going on and why this might be the case. Are you batch-starting many things and closing everything at the end (as often seen with Scrum teams) instead of focusing on the flow of work? This chart gives a good visual indication of such behaviour and support you and your team taking action.
Sometimes it can be useful to compare estimates with how long items took. In many cases I used this to show that Story Points (or other estimations for that matter) won't help you a whole lot, as the the estimates and cycle-time don't correlate much. I can recommend reading Nick Browns three-part blog post series: Story Pointless to learn more.
In the above chart, you can see the cycle-time on the y-axis and the estimates on the x-axis. One would assume that there is some kind of correlation, so in general, a higher estimate would mean things take longer. Reality often looks more like the example above. Actual time to complete items seems to not have any relation to the estimates. A good example of this is items that were estimated with a 5: They range from 2 days to 27 days.
Goal of this chart is to support you to make such things visible, helping people understand the waste of time estimation often is and spending the time on more meaningful things.
Process Behaviour Charts help to see how predictable your process is and whether your data shows "regular variability" or indicates a signal that should be acted up. You can read up more about PBCs in the following resources:
- Objectively measuring “predictability”
- Process Behaviour Charts - An Introduction
- Actionable Agile Metrics for Predictability: Advanced Topics
FlowMetricsCSV allows to generate the process behaviour charts for Cycle Time, Throughput, Work in Progress, and Total Work Item Age.
Following are example charts for all four measures.
You want to look for occurrences where data points are above the upper natural process limit or below the lower natural process limit. If you operate "in between" those two lines, your process can be considered predictable.
For example if you keep your throughput in between the upper and lower natural process limit, you can expect that a Monte Carlo Simulation will provide decent results.