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.
By the way: If you prefer to calculate Story Points instead of estimating them, feel free to download the free excel template here. 🙂
Get your free Story Point Calculator
Download the free Story Point Calculator in the Excel template with instructions included.
Content of this article:
Why Story Points?
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.
Why do we want to determine velocity anyway?
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.
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.
If one doesn’t even know the item, it would at least be helpful to know what processing speed my team has.
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.
What are Story Points?
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”
or
“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:
How do we calculate Story Points?
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.
How do I calculate story points?
- Adjust the Definition of Ready
We like to use the adapted Fibonacci sequence, let’s say on a scale up to 20. The definition of ready says that all stories over 20 have to be split, so the numbers up to 20 are fine. This makes things a bit easier for us.
- Use the first story as a benchmark
The first story receives 5 story points. Maybe even 8. Why? Because it doesn’t matter. The first story is just a benchmark.
- Compare stories in the first sprint
Any other story in this sprint will be compared to the first story. We ask: Is this story more complex to implement or not? Yes, in this phase it’s all about effort. So the second story is much more elaborate, say 13 story points. This gives us a total of 18 story points. Good.
- Determining the implementation effort in time
In a second planning phase, we determine the actual implementation effort in time by creating detailed subtasks and estimating them in hours. This is a truly technical workshop in which we create a concrete implementation plan for this sprint. Let’s say for the first story we had 2 days, for the second 5 days. Since both estimates use different scales, the ratio between the first and second story in both estimates is, of course, not linear.
So we have 2 stories with 18 story points and a total of 7 days of effort.
Strictly speaking, it is by no means important if you estimate the actual implementation time in the second part of the planning, or if you do so after the sprint per story. The latter would be even more objective. But you’ll need the estimate for a valid commitment anyway, and you won’t have to track the time spent per story during the sprint. Instead you can focus on the remaining time. - Starting the sprint
Now we will use these values to start the sprint.
- Repeat the process for a few sprints
In the next sprint we do the same, comparing every story with the first story of the first sprint. In the next sprint we do the same over and over again. At some point, we get to the 5th, 7th, or 10th sprint. Time has passed. Time that teams used to familiarize themselves with technology, to train juniors, to get to know each other, to have retrospectives, to make improvements in the process, etc.
- Compare the complexity to the very first story
Now let’s do the same thing again. We take the current story in the 5th, 7th, or 10th sprint and compare it to the first story of the first sprint. But now we ask a different question: “If we had to implement this story in the first sprint – when we were young and beautiful and inexperienced – how long would it have taken us compared to the very first story?
This is where the theory of relativity kicks in, as we have changed over time, but the complexity of the story hasn’t.
The only difference is that we need less time to implement the story today than we did back then. This will be shown in the second phase of planning in which we estimate the exact implementation time. For example, the story also has 5 story points, because back then it would have required the same effort. But today we don’t need 2 days, we only need 1.5. This means that we have become better, our velocity has increased.
Get your free Story Point Calculator
Download the free Story Point Calculator in the Excel template with instructions included.
The Bottom Line
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.
Update: In the meantime, we at scagile developed a method to calculate Story Points. Check out this article:
-
Pingback: URL
