Scrum
Calculating the Scrum Velocity
How to calculate the scrum velocity and display it in a way that is suitable for showing a real trend and allowing a forecast to be made. + free Excel Template
Menu
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 the scrum 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:
Download the free Scrum Velocity Template in the Excel template with instructions included.
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.
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 the scrum 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 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.
Sprint
SP
Start
End
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.
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.
Often stories are almost finished in the current sprint. Almost finished is not finished and therefore you won’t get any cookies in the current sprint.
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.
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
1
1
1
5
03. Jul
2
1
1
8
06. Jul
3
1
1
2
04. Jul
4
1
1
2
04. Jul
5
1
1
3
05. Jul
6
2
2
13
12. Jul
7
2
2
2
10. Jul
8
2
2
2
12. Jul
9
2
3
5
17. Jul
10
2
3
5
17. Jul
11
3
3
20
20. Jul
12
3
3
8
17. Jul
13
3
3
5
18. Jul
14
4
4
13
26. Jul
15
4
4
5
24. Jul
16
4
4
8
24. Jul
17
4
4
13
27. Jul
18
5
5
20
02. Aug
19
5
6
20
08. Aug
20
6
6
13
07. Aug
21
6
6
5
08. Aug
22
6
6
5
08. Aug
23
6
6
8
09. Aug
24
6
6
8
10. Aug
25
6
6
5
10. Aug
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.
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.
We are referring to the actual close date and not the sprint end.
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.
How to calculate the scrum velocity and display it in a way that is suitable for showing a real trend and allowing a forecast to be made. + free Excel Template
What are story points, why do they even exist and how can you estimate them? You can find out all of this here. You will be surprised what is in them!
Good specifications are simply no longer possible – contracts based on fixed prices or T&M too risky. It’s time for Agile Contracting! An evaluation standard is there already 🙂
For scaled agile organizations it is frustrating when their project management tools don’t support their processes.
That’s why we developed scagile as an app which actively supports agile best-practices with features you haven’t even thought about and with which you’ll be able to create value flow across your entire organization.
