Whether you are applying Kanban or not, the four flow measures are a great tool to analyze how well things are flowing through your system. They are easy to measure (most likely you have the data already) and enable continuous improvement.
Being based on historical data from your team(s), they show you what has happened in reality. This makes them perfect to drive improvements. You can design experiments, formulate hypotheses on what should be improved, and check whether that happened or not.
The Measures
According to the Kanban Guide, the four mandatory flow measures to track are:
WIP: The number of work items started but not finished.
Throughput: The number of work items finished per unit of time. Note the measurement of throughput is the exact count of work items.
Work Item Age: The amount of elapsed time between when a work item started and the current time.
Cycle Time: The amount of elapsed time between when a work item started and when a work item finished.
To measure this, you only need the date when your item was pulled into "In Progress" and the date when it was "Closed".*
*In Progress and Closed can mean different things to different teams. Make sure you have a clear definition for your context.
Using Flow Metrics
Following is a quick description of how you can use the different measures to improve the effectiveness, efficiency, and/or predictability of your teams.
WIP
Little's Law tells us that: If we work on too many things in parallel, we will potentially increase Cycle Time and lower our Throughput.
Throughput = WIP / Cycle Time
Often it's the opposite of what we want: Lowering our Cycle Times (so we can have quicker feedback) and in general "speeding up" by increasing our Throughput.
By controlling our WIP, we make sure we're not starting too many things. One tool that can help us do that is the "WIP Run Chart" which shows you how much is in progress per unit of time:
Your goal should be to always be at your optimum. So not be too high, nor too low. The run chart can help you spot trends, for example, if you continuously increase your WIP. That is a sign that something is not "flowing" nicely and can be a good discussion point for potential improvement.
A simple way to control your WIP is to just start something when something else has finished. Using a chart that shows you "how much you've started" vs "how much was done" in a certain period can give you insights on whether you manage to keep the WIP stable:
Throughput
Unlike velocity metrics that use estimates (like Story Points, Ideal Days, etc.) as a base, Throughput is simply counting the number of items closed in a given unit of time (for example days, weeks, Sprints, etc.).
While estimates might be useful in your context to trigger a discussion, making plans based on them might not be the best idea. When you use your Throughput data for this, your plans are based on your team's historic performance, rather than what they think they manage (or even worse: what someone thinks they can manage).
We recommend using Monte Carlo Forecasting (which is based on Throughput), but you can also look at your Throughput directly to get a grasp of how much you might manage to get done:
A common anti-pattern in many teams that use fixed-cadence iterations is the "waterfalling" of the iteration. Many things get started in the beginning, and most (if not all) are "rushed to closure" at the end. If you want to optimize for flow, you want to have items closed and started continuously. A Throughput run chart per day can help you spot such patterns:
Cycle Time
The Cycle Time tells you how long an individual item took from "In-Progress" to "Closed". If you plot the Cycle Time for your recent items on a Scatterplot, you can see how many items (in percentage) you manage to close in a given time:
In the above chart, you can read that 50% of all the items are closed within 5 days or less. So if this team starts one new item today, there is a 50% chance that it's closed in 5 days. Similarly, there is an 85% chance that it will be closed in 8 days.
This chart helps to see "how long" things take for this team and might serve as input to defining a "Service Level Expectation" (SLE). This is the commitment a team gives on how fast an item will be done when they start it. For example, the SLE of the above team could be: "We close 85% of all our items within 10 days or less after starting."
The scatterplot would tell us that this team manages to keep their commitment.
Furthermore, this data could be used to establish some transparency around how long things take and to drive improvements. Right now we need 14 days to close an item with 95% certainty - how could we bring this down to 12 days?
You also spot outliers easily - check the items that took very long and see what you can learn from them, so that next time something similar appears, it won't take as long anymore.
Work Item Age
Cycle Time is a lagging indicator - we only "get it" after an item is closed. Work Item Age (WIA) is the leading indicator: we have the data on in-progress items and that allows us to act on it.
Assuming your team has an SLE that says that you close 85% of your items within 10 days or less, you can use this on your "in progress" items. Everything that is above 5 days might trigger some more discussion about how it can be closed within our SLE. The closer we get to our target, the more focused we should be on "keeping our commitment" and finding ways to get things moving.
If your team runs daily meetings, looking at the WIA and focusing on the oldest items and how you can move them forward today is a good strategy to keep your SLE and bring your Cycle Time down in general.
Tools to Generate Flow Metrics
It's very simple to calculate the flow measures. All you need is the date an item was started and the date when it was closed.
While there are various tools already available (for example ActionableAgile), they might not be usable for everyone, as they need a license or some special permission to run in your environment.
That's why we created some tooling ourselves that helps you generate the charts you saw in this post (and more) that you can use for free and without much overhead.
With FlowMetricsCSV you can create charts based on any CSV input file. Whether you use Jira, Azure DevOps, Excel, or a physical board, as long as you can extract your data into the CSV format, you can use it.
If you use Azure DevOps or Jira, you can also use FlowPulse. This tool allows you to directly query your work tracking system (either via WIQL in the case of Azure DevOps or JQL in the case of Jira) and generate the charts with the latest data.
Conclusion
Flow Metrics are a powerful tool because they are based on the actual performance of a team. They allow you to create transparency about the flow of work in your system which can trigger important discussions. As it's based on real data (and not guesses), it allows you to form hypotheses on how to improve, design experiments, and measure the impact. That way, you can see if your improvement actions had any positive impact or not.
Why not give it a try and see how it helps you and your team improve?
コメント