I’m often asked how do we start with Flow Metrics? What's the first thing we should do? Well it's easy so let's talk about it.
Now the cornerstone of flow metrics is cycle time.
If you haven't heard of Peter Drucker you really should have, he's widely regarded as the father of management and created many ways of doing things in the workplace that we now take for granted.
He consulted for IBM, General Electric, Proctor and Gamble and Intel. He foresaw the information age and coined the phrase knowledge worker.
He's often quoted as saying
You can't manage what you can't measure
To manage the flow of work we need to measure the parts that make up the end product and that's where cycle time can help. If you don't already know, cycle time is the time it takes you from when you start a story to when it's done so you need to decide the starting point in your workflow and the end point.
I usually measure it from in progress to done.
If you're thinking hey we do Scrum so flow metrics don't fit into our process think again, they are just as valid in Scrum as story points, velocity and burndown charts - none of which are part of Scrum or the Scrum Guide.
This is a Scrum board in Jira.
You'll notice that to-do is part of the Sprint, When an item is taken into Sprint at Sprint Planning it's placed into the to-do column. This is because it's queued ready to start but we haven't actually started it yet. If we measured from to-do to done all the stories would end up having very similar cycle time, certainly their start date would be the same and that isn't very helpful.
We don't start all stories in Sprint at the same time and this is why we have a to-do column but don't use it as our starting point for our cycle time. Your workflow will probably vary but base it on this concept and in case you're wondering yes cycle time will include anytime a story spends in blocked or on hold.
If you base your cycle time on when a story first lands in your backlog to when it's eventually done this is not cycle time it's called lead time.
Now lead time is also a very important metric, it tells you how long it takes to get a story done from when it's first asked for. But I wouldn't recommend starting with this as you can end up tying yourself in knots and getting nowhere. In my opinion this is best looked at after you've got cycle time under control.
So why cycle time?
Well firstly because it's solely related to the team and that makes it quicker and easier because it's based on what the team does day in day out.
Lead time starts earlier than this and involves more players than just the team so it's more difficult to address initially. Secondly it helps us understand our throughput and predictability which then helps us find issues in our process that we can improve upon.
No matter what tool you're using (Jira in this example) it will track the time it takes to get a story from one status to the next, often called a transition, in the background. The fun starts when you try to extract this data as most tools don't allow you to do this natively which is extremely irritating.
With Jira you'll need an Atlassian Marketplace plugin to do this such as eazyBI or Time in Status. It is possible to do it natively in Jira by using Jira’s automation, adding some custom fields and a few rules that will calculate and display your cycle time within Jira itself and extract that data for free but it's pretty involved and you'll need a Jira admin to do all the work.
eazyBI is my preferred method because you can do a lot with it.
I'll quickly show you how to do this in Time in Status by RVS which is by far the easiest method.
So you'll first need to purchase Time in Status by RVS from the Atlassian Marketplace and get your Jira admin to install it. It's licensed per Jira seat and you can see the current pricing here for a 1000 users.
Once installed you'll find it here under apps in Jira.
Time in Status does lots of different things which I'm not going to go into here but we're specifically interested in cycle time between our designated start and end date in our workflow which in this example is in progress and done.
So to do this in Time in Status select ‘status transition dates’ from the dropdown. You can narrow this down further by selecting one or more of the filters at the top such as project, team, Sprint, date range etc. And there you have it, the dates that your stories transitioned to each status.
Now simply download this to a CSV file and import it into Excel which I will show you in a moment.
For other tools such as Microsoft ADO you'll need to use PowerBI to extract the data but if you're lucky enough to be using Kanbanize you should be able to get this through the interface.
When you extract the data you'll most likely end up with a CSV file so just import that into Excel or equivalent and it will look something like this.
The only two columns we need are the dates our stories entered in progress and done because they are the statuses we're using in our workflow for our start and end date in our cycle time. So you can delete the other columns. This is all you need to calculate cycle time.
You simply subtract the date from the done column from the date in the in progress column and add one day. You add one day because we want to count every day which the item was worked on as part of the total for example when an item starts and ends on the same day we would would never say that the story took zero time to complete. So we add one effectively rounding the partial day to a full day.
So what about stories that don't start and end on the same day for example let's say a story starts on the 1st of January and finishes on the 2nd of January while using this calculation the cycle time time would be 2 days and I think this is a reasonable and a realistic outcome.
You can do this easily with the Excel function Networkdays which automatically excludes weekends. Networkdays accepts three arguments a start date an end date plus an optional list of exclusion dates that you specify. And these could be for example bank holidays, so you can see in this example I have a list of all UK bank holidays in 2024. I simply select that range as argument three and they will be excluded from the calculation.
I actually wouldn’t recommend excluding weekends or people's annual leave as this is a normal thing to happen and will even itself out during the year but you could if you really wanted to simply by adding those dates to the date exclusion list.
So your calculation would look like this.
Now simply copy that formula all the way down your list. This shows you your cycle time for every individual completed story and this is great information to have in itself but we can go one step further to make this data incredibly useful.
You could take an average of all of our completed story cycle times but averages are notoriously bad, now check this book out by Sam Savage, ‘The Flaw of Averages’ to find out why.
Instead what we want to do is find out what a high probability of completing any of our stories is so we can take the 85th percentile of all our previously completed stories.
To do this we just use Excel's percentile function which you can see here. The data here is looking pretty good but this is just from my home simulation, I would expect your data to look very different.
So if your 85th percentile is telling you that it took 10 days to complete any of your stories with an 85% chance of it happening do you think that's good or bad?
Well if you're doing Scrum and 2 week Sprints this is telling you that you would need to start all your stories pretty much as soon as you start the Sprint to have a high probability of completing them, which isn't great.
So it gives you insight into possible actions you might need to consider such as perhaps your stories are generally too big or too complex or perhaps they haven't been well defined and you're hitting many blockers during the Sprint or maybe you're taking too much work into the Sprint.
In my experience a good 85th percentile of all your completed stories to aim for is 5 days or less if you're doing 2 week sprints.
The great thing about using percentiles is that it does not matter how big or small or how complex the story is, it simply doesn't matter, so dwell on that for a moment.
You can choose whatever probability you like but 85% is my favourite because it gives a good balance.
Now for me this is far more powerful than using story points or velocity which is based on educated guesses and let's not forget developers hate estimating how long something will take to get done so this approach removes all of that and makes everyone's life easier.
That doesn't mean you don't need to discuss the work, break it down and discover constraints and dependencies, of course you still need to do this, it just removes the rubbish part of saying something will take 5 story points which has no value.
Using cycle time and the 85th percentile takes out all the guesswork because it's based on fact, what has actually happened in the past.
So this is your starting point for flow metrics. Get your cycle time under control and then you can move on to analyse other things such as flow efficiency, work item age and for me the big game changer Monte Carlo Simulation.
Using Monte Carlo Simulation means we can forecast with a high degree of certainty when we can get a feature or a project completed.
This isn't guesswork, this is based on what has actually happened and in my experience leadership and stakeholders far prefer this as it's something they can actually get their head around and understand, plus teams like it because it means they can stop wasting time with story points.
The data that you've already collected for cycle time is all the data you're going to need to forecast with Monte Carlo, you just need to know your throughput, so how many stories were completed on what date, which you already have.
Let me know if you’re interested in seeing a blog on how to do Monte Carlo Simulation.
Comments