Flow metrics are great, I'm a big proponent of cycle time, limiting wip, tracking the age of your work and forecasting with Monte Carlo Simulation.
But what happens when you calculate all of this but the resulting data and forecast you see simply isn't good enough? Well the good news is at least you now know you've got a problem, but where do you start? Let's talk about it.
Let's say after you've calculated your individual cycle time for stories at the 85th percentile and it comes out at something like 14 days it's not good enough for you. Or perhaps you've run Monte Carlo Simulation and it's telling you that it's going to take you 2 months to deliver 25 stories and that's not good enough for you either. What can you do?
Well, one approach is to calculate your flow efficiency. Now the factors that affect cycle time and Monte Carlo forecasts can be broken down into two basic parts, active time and inactive time. Active time is the time you actually spend working on a story, inactive time is everything else.
We want to minimise inactive time and maximise active time
Now flow efficiency is a simple calculation of these two variables.
Flow efficiency = active time / cycle time
Now before I go on there are many that would say that you shouldn't bother with flow efficiency for three main reasons.
It can be difficult to calculate
Even when you have calculated it, it doesn't provide you with anything actionable i.e. it doesn't tell you exactly what the problem is
There are far better metrics to focus on
Well, firstly, it's not really difficult to calculate at all as we will see shortly. Secondly it's true that it doesn't pinpoint the exact problem but it definitely exposes a serious issue visualising it and helps you to set up a series of interventions to reduce the problem. These are most often things like bottlenecks, handoffs and queues, all of which kill our cycle time. Thirdly there are better metrics to focus on, well yes that is true, cycle time, work item age and forecasting with Monto Carlo. But when you first start using these metrics and the results you're seeing aren't good enough what do you do then? You can use flow efficiency to help you identify problem areas.
So let's dive into flow efficiency. How do we get the data needed in order to calculate flow efficiency? Well you need to use wait states or inactive states in your workflow. I'd recommend creating dedicated wait states as columns such as, development done or ready for test.
In this example from Jira you can see the workflow states ‘to do’ ‘blocked on hold’ ‘in development’ ‘ready for testing’ ‘in test’ and ‘done’. In my example here cycle time starts only when a story first enters ‘in development’ and ends when the story enters done.
Right, so we want to find our active time, so we're going to exclude the state ‘to-do’ because when a story is in ‘to-do’ we're not actually working on it. It's basically queued up ready to pick when we have capacity.
We'll also exclude any time a story spends in ‘blocked on hold’ because this is also an inactive state. A quick word on the ‘blocked’ workflow state. You need specific policies on this, don't move items to this state just for any old reason, you also need to know what action you're going to take when something enters this state otherwise it will just become a dumping ground.
We'll also exclude ‘ready for testing’ because this is a wait state waiting for someone to pick up and test. And we'll exclude ‘done’ because when a story enters ‘done’ we're not working on it anymore because, well, it's finished.
So the first thing you're going to need to do is identify what wait states you're going to need for your workflow. Wait states are very useful especially when you view your aging work in progress chart as you'll be able to see where a story is in your workflow.
We just need to add up all of the time the story spends in our active states. In this example here, it would be ‘in development’ and ‘in test’.
The data for this is automatically getting tracked by whatever agile tool you're using in the background you simply need to extract it. Briefly, if you’re using Jira you can get this data with plugins like Time in Status or eazyBI or by using things like Script Runner. You can actually do it natively in Jira but you'll need to use custom fields, automation and rules. For other tools such as Azure DevOps you’ll need to use something like Power BI.
It should go without saying that everyone on the team must take full responsibility for their stories and move them to the correct state at the right time. You should already be doing this if you're tracking your cycle time and actually care about it. Team members only need to do this once a day, it only takes a few seconds so it’s not much to ask considering the benefits.
If you're a Scrum Master or team lead you'll need to explain to the team why it benefits them. It's in their own interest and that of the teams to do this because it's ultimately going to help everyone work in a more efficient and sustainable way, meaning they won't get landed with lots of fixed scope fixed time work, having to work long hours and weekends towards the end of large pieces of work just to get it completed, and they'll have less stress and better well-being because of this.
So why is this?
Well because they'll be able to provide accurate forecasts to leadership that really come true so trust will be built and all they have to do is update their board once a day, it's a small price to pay.
If you've never measured cycle time before or you're finding that your cycle times are very high then it's not uncommon to find that your flow efficiency is also low, around the 10% mark. Let's examine that. Now if we took 10 days to complete a story, that's your cycle time, but the active time, the time you actually spent working on it, was just one day then that means nine days were spent when essentially nothing was happening, that is your inactive time.
Now remember, to calculate your flow efficiency you need to divide your active time by your cycle time. So in this case 1 / 10 which is a flow efficiency of 10%. Where do you think you should focus your effort in this example? Exactly! You need to focus on getting that inactive time down.
So let's take this a little bit further, let's say that your 85th percentile for your process is 20 days meaning you've got the cycle times of all your previously completed stories and you've used Excel's percentile function to calculate the 85th percentile.
Now to calculate your flow efficiency for all previously completed stories simply sum up all of the active time for each story and divide it by the total cycle time for the same stories, and in this example here, you can see that the flow efficiency of our process is 10%.
A low flow efficiency means we’ve got a lot of inactive time and high flow efficiency means we've got a lot of active time.
If you aggressively go after that inactive time in our example and manage to reduce it significantly and end up getting your flow efficiency to 50%, while keeping your active time the same, that would mean that your 85th percentile would be 5 days instead of 20, much much better.
Now if your flow efficiency is 70% then a better strategy would be to target the active time spent on stories since this makes up the majority of the cycle time.
Flow efficiency doesn't tell you exactly what the problem is, as its detractors have pointed out, but it points you in the right direction, it's a starting point.
The reasons for high or low flow efficiency could be many, for example.
Your stories are too large, they're too complex, so break them down
Maybe you haven't refined the work prior to taking it into Sprint and didn't discover any dependences or constraints
Perhaps it's nothing specifically wrong with the story but you're trying to work on too many things at the same time, so limit your work in progress and reduce your context switching. Start by putting a wip limit on your ‘in progress’ column and stick to it don't ignore it
You've got some process issues causing decision latency, maybe stakeholders or product owners aren't as engaged as they could be so try and build better relationships
When a story goes into ‘blocked on hold’ don't ignore it do whatever it takes to get that story back on track.
But perhaps the biggest offender is very often bottlenecks, handoffs and queues. Are you waiting for something to happen? A stakeholder or a committee maybe, or a colleague needs to pick up the story and do something with it, testing for example. Identifying these queues and removing them is one of the cheapest ways of increasing your flow.
Flow efficiency is a great way to start troubleshooting why your cycle times are too high. So give it a go you might be surprised what you find.
Comments