You can discuss this for a long time, but arguably the most important KPIs, or maybe two of the most important top 5 KPIs in Scrum, are sprint accuracy and velocity.
From a process-related point of view, the former is almost a prerequisite for the latter. I’ll come back to that later.
Sprint accuracy shows how often a team manages to keep the sprint commitment, or more precisely, how close teams will come.
But that’s not what I want to talk about today. This article is about velocity.
Strictly speaking, the objective is to describe a method for calculating and displaying velocity that is suitable for showing a real trend and allowing a forecast to be made.
I would also like to help you to apply the following trend analysis in your projects and provide you with a free Excel template:
Velocity in Scrum is clearly a difficult issue
Scrum teams often find it very difficult to maintain or even increase their velocity and thus provide organizations with the possibility of a reasonably reliable forecast for effort, duration, cost (you name it) of new features.
Adequately measuring velocity in Scrum in a way that allows meaningful conclusions can also be a problem.
How often do we all sit over our JIRA velocity charts, looking at the fever curve and thinking “Hmmm…. O.K. And what is this supposed to tell me?
Then we go back to our burndown charts and hope to make it to the end, first the sprint and then the project.
This morning two students approached me on their bicycles and I could only pick up a short snippet of their conversation. One of them said, ” I hope will be about the vocabulary I’ve studied”. We all know this phrase, but it no longer sounds as dramatic as it did 30 years ago, but it’s all the more funny. Draw the parallel yourself.
Unfortunately, the problem with velocity starts much earlier.
In order to measure a velocity, Mr. Scrum has created a currency for us: the story points (SP). However, story points are often misunderstood and misapplied, which doesn’t make it any easier to calculate velocity. I have already written an article about story points. If you are interested, you can read more there.
In short, story points represent the complexity of a story in terms of its effort and are therefore neither complexity nor effort, but the relationship between the two. They are therefore often expressed in Fibonacci numbers. This should ring a bell with most people, because Fibonacci sequences are used by scientists to represent the growth of populations.
Let’s say you use story points correctly. That leaves the problem of calculating velocity.
Let’s also assume that you’ve successfully completed the other SCRUM courses as well, and in a sprint you’ll only award story points for stories (and not for bugs, yes, I have seen it all) and only when the story has been completed. Unfortunately, sprint accuracy in teams is often not very distinctive.
If this were the case and everything else went well, your velocity chart in JIRA would look more or less like this:
The presentation is based on a simulation of 6 sprints and the story points achieved there.
|1||20||02. Jul||06. Jul|
|2||27||09. Jul||13. Jul|
|3||33||16. Jul||20. Jul|
|4||39||23. Jul||27. Jul|
|5||40||30. Jul||03. Aug|
|6||44||06. Aug||10. Aug|
That looks very good. Unfortunately, this is a simulation. One that doesn’t do justice to reality at all.
Reality often looks like this:
Hm, a trend cannot be identified from it at all. You remember the situation I described before. But why is that? We don’t have to guess for long.
But since they will be finished quickly in the following sprint, we will get even more story points in the following sprint.
Then there are also various influencing factors, the bug rate, capacity fluctuations, etc., which are all factors that have to be taken into account. These are real factors influencing velocity. But they can hardly be separated from the sprint limit blur.
How do we solve this problem?
We solve the problem quite easily. We separate the correct practice – awarding story points only when a story is closed, no matter if in this sprint or in the next – from calculating the real velocity.
If you are working under an agile contract, you will only be paid for the story points achieved in the sprint, but you will still be able to measure the team’s real velocity – regardless of this logic.
Let’s have a look at the following spreadsheet. We listed each story with the date when it was closed and the sprint to which it belongs.
|Story #||Sprint assigned||Sprint closed||SP||Closed|
In this spreadsheet we don’t look at the sums per sprint, but at the stories themselves. We see in which sprint they were originally and when they were actually closed.
Now we map a trend on it and get this much more meaningful picture.
This method’s advantage is that we can spot a real trend instead of confusion of the sprint-based velocity chart.
The team obviously isn’t very good at sprint accuracy, because they haven’t quite managed to deliver the stories they set out to do in this sprint several times. Shame on the team for that. But their velocity grows steadily over time, so the boys and girls aren’t half bad.
At least now they know exactly what they have to work on and management can relax a little.
Anyway, the Scrum process is very delicate and quite complex. Besides, Scrum doesn’t offer a lot of KPI’s that look like a number.
If one of these KPI’s distorts reality by using an inconvenient representation or inappropriate measurement method or mixes things that should better be separated, the task of advancing a team becomes very difficult.
Do not misunderstand: The way JIRA presents the velocity chart is not exactly wrong. But sprint accuracy and velocity are mixed so poorly that the result is a distorted picture and it’s virtually impossible to work sensibly with this incredibly valuable instrument.
There are many more measuring points in the proposed method. This means it doesn’t matter whether a team has one-week or two-week sprints, or if they change the rhythm.
This not only provides more measuring points, i.e. we don’t have to wait until a trend becomes apparent, but also more independence from the lived Scrum process.
And even the velocity of kanban teams can be measured, even if they usually fly under the radar.