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.
All the more reason to do an article about them.
You will be surprised at what they have to offer.
In fact, Story points aren’t as trivial as they might seem at first glance. And that’s a reason for many – sometimes strange – discussions that are so common in the communities.
With this Excel template you can easily calculate Story Points with just a few clicks.
Let’s first talk about the why. For what do we use story points?
Story points are a tool to determine the velocity of teams.
Velocity – another funny word. The speed of teams. OK. How fast can a team implement a certain scope? At first, “how fast” is not the problem. We are used to expressing this in time units.
But what does scope mean? And how should this be measured objectively – i.e., so that we can compare it?
This is where story points enter the game. But more about that later. We’ll stay with the purpose for a moment, which is to determine the velocity of a team.
What for and how, those are the key questions here. First of all, let’s talk about the what for.
Everything for the organization
Organizations have a natural interest in keeping track of the economic impact of all their activities. When a project is started – ideally, even before that – an organization would like to know what the project will cost. However, thanks to time-to-market, they usually know fairly well when the project will go live. When it comes to costs and detailed scope, there are usually only a few vague ideas.
Unfortunately, Scrum is always chosen as a methodology when a sufficient specification of the item to be created is not available, but time is short. This can be for multiple reasons such as too complex requirements, time-to-market requirements, etc.
If one doesn’t even know the item, it would at least be helpful to know what processing speed my team has.
So there is absolutely nothing on which one could build a valid estimate and a nice project controlling with a neat Gantt chart and milestones together with resource planning etc. Organizations don’t like that.
Or in metaphorical terms: If I don’t know the route to my destination, it would at least be helpful to know the speed of the car I’m driving. I still don’t know exactly when I’ll arrive, but I could plan the individual sections of the route that are directly ahead of me. In other words, I’m no longer completely in the dark and the more the overall route becomes brighter, the more accurate my planning gets.
This should occur at the latest after 20 to 30 percent of the duration of the project. You should have about 80 percent certainty much earlier: at the point of no return. But we will discuss that at a different point.
The SAFe authors have even been persuaded by the context described here to demand normalized story points. I will come to this later on. Now we’re going to clarify story points and their application.
Everything for the Teams
Of course, Scrum teams also have a strong interest in knowing if they are getting better as a team or stagnating, so that they can then take appropriate measures in retrospectives.
This is also a circumstance that should not be underestimated and that we need to consider as well. Because I’ve often read that the velocity of strong and experienced teams doesn’t fluctuate anyway. Most recently, with the SAFe authors mentioned above, but also elsewhere.
I don’t know about the reality these people live in, the reality of organizations I advise (Deutsche Bank, Lufthansa, Conrad Electronics, Deutsche Bahn and others) and also the reality of our own development teams. In these realities, there are projects running from 9 months to 3 years, then there will be new projects with new teams.
In these realities, teams do not only consist of experienced senior or lead developers, but include a few seniors with several intermediate and junior developers, and we do all we can to ensure that their velocity does not remain stable.
And in practice, not everything is always in place and ready, instead teams fight for their CI and dev environments, tools and frameworks. In practice, development teams constantly have to deal with new technologies and technical debts, new and sometimes inexperienced PO’s and Scrum Masters, and so on.
Velocity under such conditions is rather fragile than stable and it is a daily struggle to keep it high, but at least stable or ideally increasing slightly. It’s not a concept that you can take for granted.
If all of this were stable – and in no way in danger – most parts of the Scrum methodology would not be needed at all.
So if you think that story points are only there to get a feeling for what fits into a Scrum sprint, and you commit yourself to the same number of story points, you could save yourself the trouble. There is an easier way to do that. As a PO, you could simply ask the DevTeam before or during planning: “Do these three stories fit into the sprint or can I add another one? The answer would be just as accurate.
Now that we know what role story points play in Scrum or SAFe, it’s time to get to the definition and description.
And unfortunately, it is complex, even if it does not seem like it at first glance. But the effort will be worth it.
Story points are a way of measuring the complexity of a story. Put them in relation to the implementation effort of this story and you’ll the velocity.
That’s quite simple. But what exactly is the complexity of a story and how do I define it? That makes it a little more difficult – if not more „complex“.
If you google „complexity”, you will get a number of quite different definitions, which I don’t want to quote and discuss here for obvious reasons. Two of them appear short and meaningful for our purposes:
“The number of elements and connections between them within a system”
“The information content of data”
Technically speaking, the latter could also be defined in reverse. Data aggregates into information and does not contain it, but that is a different, rather finicky discussion.
But when teams estimate the complexity of a story, they naturally only consider the effort they need to implement it, due to the lack of other objective criteria. It is easier to determine and also kind of obvious.
Even if the procedure is not completely wrong – as I will show later – the teams will be caught in a bad situation.
Since the effort is individual, this characteristic is automatically transferred to the complexity.
And when we look back at how story points are used – that is, for velocity – the problem immediately comes to light: Time is compared to time, and that of course will lead us nowhere.
Because if velocity is a relation of complexity and effort, I cannot describe complexity with effort. Otherwise I would be putting effort in relation to effort, i.e. comparing time with time.
This would be bad. Besides, complexity is a feature of the story. Effort, on the other hand, points to a property of the DevTeam.
But that’s not how we make progress. The situation is tricky, because we have no objective criteria for determining complexity. At any rate, none that could be derived from a story in a reasonably practical and manageable way.
The solution is a workaround about the “theory of relativity”. This may sound complicated, but it is simpler. And this is how it works:
We will use the following definition for story points:
Story points represent the complexity of a story in relation to its effort.
Therefore, story points are neither complexity (too difficult to determine), nor effort (we don’t want to compare time with time), but somewhere in between.
My God, why all this effort? Well …
Improving teams is a basic principle of Scrum.
Because teams always start under very difficult conditions: New team, no specification, new topic, inexperienced product owner, new technology. There are so many reasons, all of them unpleasant.
The velocity at the beginning of a project is, of course, pretty low. The teams have to catch up as quickly as possible.
Stakeholders must not get nervous too quickly in this early phase and get caught up in micromanagement (a widespread management error).
In other words, becoming better must be institutionalized. And for that we need two things:
A forum, which is the very purpose of the sprint retrospective, the most underestimated of meetings. And a measure that shows us if the velocity is increasing, decreasing or constant, so that we can take appropriate measures in the retrospective and observe the effect: the velocity, generated from the story points and set in relation to the actual implementation effort.
It’s not exactly easy, but it’s the only way to determine where the team is exactly.
Of course, we only do this because there is no objective procedure with good criteria for determining complexity. With such a method, however, teams could immediately be compared to each other.
SAFe wants to do that, hence the demand for normalized story points. Scrum never really did. They both have good and plausible reasons for their position.
Anyone who has ever dealt with agile contracting will certainly understand the SAFe position. But Scrum purists won’t like it, because competition is not a good motivator.
Find your own truth.
With this Excel template you can easily calculate Story Points with just a few clicks.
We send your free Story Point Calculator Excel template including a step-by-step guide via email. Please enter your contact details here.