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

runScrum: Scaled Agile Project Management Tools for SharePoinnt

Sit back. Relax.
And let SharePoint runScrum!

The first all-in-one scaled agile project management suite for SharePoint

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. 

Story Points
Story Points: The Why and How
What are Story Points, why do they exist and how can thy be calculated? Find all the answers in this article. You will be surprised at what they have to offer!

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.

12002. Jul06. Jul
22709. Jul13. Jul
33316. Jul20. Jul
43923. Jul27. Jul
54030. Jul03. Aug
64406. Aug10. 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.

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.  

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 assignedSprint closedSPClosed
111503. Jul
211806. Jul
311204. Jul
411204. Jul
511305. Jul
6221312. Jul
722210. Jul
822212. Jul
923517. Jul
1023517. Jul
11332020. Jul
1233817. Jul.
1333518. Jul
14441326. Jul
1544524. Jul
1644824. Jul
17441327. Jul
18552002. Aug
19562008. Aug
20661307. Aug
2166508. Aug
2266508. Aug
2366809. Aug
2466810. Aug
2566510. 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.

Calculating Scrum Velocity
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.

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.

1 Comment

  • Chris Karpyszyn
    Posted November 11, 2019 2:52 pm 0Likes

    Can you go into more detail about the calculation used for stories that spill into the next sprint?

    I’d love to be able to get a clearer picture of my team’s velocity but 1) your template doesn’t work and 2) it’s a bit of work to get this data out of JIRA and into excel. I’m looking to distill this into something simpler.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.