Calculating the Scrum Velocity

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. 

Calculate Scrum Velocity | scagile Blog

Content of this article

I would also like to help you to apply the following trend analysis in your projects and provide you with a free Excel template:

Get your free Scrum Velocity Template

Download the free Scrum Velocity Template in the Excel template with instructions included.

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 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 say you use story points correctly. That leaves the problem of calculating scrum velocity.

Story Points: The Why and How

Story points are always a source of trouble and discussion. People argue about what they are or represent, what they are useful for and how they are determined.

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. 

The app for scaled agile teams is here!

Scrum velocity: 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.

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.  

Scrum Sprint: Why 1 Week is More Effective

Here you can find out why a 1-week sprint is much more effective and can increase the velocity of your team enormously.

How do we solve this problem? – Calculating the Scrum velocity

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 scrum 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

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.

This method’s advantage is that we can spot a real trend instead of confusion of the sprint-based velocity chart.

Agile Transformation: Goals & Metrics

To avoid your agile transformation from failing, it's most important to define goals and KPI's – but above all measuring them! How and which you'll learn here...

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.

Get your free Scrum Velocity Template

Download the free Scrum Velocity Template in the Excel template with instructions included.

Click to see articles with the same tags:

Klaus Riedel

As an agile coach, Klaus Riedel, together with his team, supports the digital transformation and the introduction of Scrum and SAFe in large organizations such as Deutsche Bank, Conrad Electronics, Volkswagen, PWC and others.

All his gained practical experiences in more than 15 years of agile transformation have been incorporated into the articles of his blog.

In Scagile Academy he trains young Agile Experts and since 2016 he teaches agile project management at the German Faculty of TU Sofia.

More interesting articles for you:

Your free Scrum Velocity Excel Template

We send your free Scrum Velocity Excel template via email. Please enter your contact details here.

WSJF Excel Template | scagile

hbspt.forms.create({
region: “eu1”,
portalId: “27088745”,
formId: “c28f7eb5-39b9-475c-8903-f88c9886f62e”
});