The Value of Story Points
Story points are not about estimation, but about breaking up your work into manageable pieces
“I want to stop using story points.”
“What?”
“It’s a joke, right?”
“But, can we just do that?”
“But doesn’t that go completely against Scrum?”
“That’s really the last thing I expected a Scrum Master to say!”
This is a conversation I had with one of my teams recently. I had spent months showing them what you can use story points for: Sprint capacity, refining stories, and yes, even planning, but to no avail. They were simply not interested.
So I felt it was finally time to stop wasting time and just get rid of the story points altogether. Why spend time on something you don’t use?
The team was in shock. They couldn’t imagine doing Scrum without story points. I guess they also worried that some manager might come and tell them off.
So I proposed we do it as an experiment: try it for a Sprint and then evaluate if necessary. But of course, by the end of the Sprint, everyone had forgotten about story points and that was the end of it.
Story Points
In case you are not familiar with story points, check this article by Maarten Dalmijn. His description fits perfectly with how I view them: What is the easiest way to explain Story Points?
Simply put, story points are a technique to make a relative estimate of the effort required to deliver a given piece of work, or as we say in Scrum, a Product Backlog Item (PBI). In other words, story points are a tool with a very specific goal. Effective if you use it properly. A sad waste of time if not.
A misunderstanding of this simple fact has led to a lot of negativity toward story points. A simple search illustrates this: https://medium.com/search?q=story+point. This is quite unfortunate because like I said, if used properly, story points can be a valuable tool.
The Value of Story Points
To me, story points are a effective way to learn how to prepare work by breaking it down into manageable pieces. This is an invaluable skill for Developers. It is the most effective way to get a clear understanding of the work. As Maarten Dalmijn points out in his article, the smaller an item of work, the lower the level of uncertainty.
This skill has various consequences. For example, it makes planning a Sprint easier, as the team can more accurately estimate how much work they can handle. This in turn is important because it supports flow. No more stressing at the end of the Sprint to get everything done!
It even helps with, dare I say it, planning. As much as we would like to believe that we can all just dive into the work with the words “it will be done when it is done”, this is simply not realistic. Even from an Agile perspective, it is handy to be able to at least get a feel of what can be done and when. If something takes years to build, even if it is a very rough estimate you will definitely think about it differently than something that takes days to deliver.
The important thing to accept here is that estimates give only a very rough idea. Estimation in this sense is not a planning tool, but a prioritisation tool. This is an important distinction. It is the difference between a Gantt chart where it is all about deadlines and achieving those or else, and a roadmap showing in which order stuff will be delivered. It leads to 2 completely different conversations:
“If this thingy is going to take a couple of months, then let's pick up this other thingy first, as we only need the first thingy in a year or so and there will be enough of a buffer to get it done in time.”
instead of:
“This thingy’s deadline is in 61 days, but progress indicates we will not be able to make the deadline by 22 days to be able to start on this other thingy, so we have to start thinking about overtime.”
Last but not least, learning to prepare their work allows a team to collaborate more easily. Working together on a single PBI is challenging, often limited to pair programming, something that there often is quite some aversion to and is not necessarily efficient. Breaking a PBI into smaller parts allows multiple Developers to work on the different parts in parallel, promoting focus and forcing continuous alignment between the Developers. Voilá: a path to effective collaboration!
Story Points as a learning tool
So how do story points help in learning how to prepare your work? Well, they give us a simple way of visualising the size of an item of work, providing the perfect feedback loop to learn how to break down work.
But, how is that possible, you might wonder, considering that story points are relative and nobody has any idea how they translate to absolute time? Well, it is actually quite easy. A team will commit to delivering a certain amount of story points during a Sprint. If they don’t succeed, then their estimates were too optimistic. If they do and have time over, then their estimates were too conservative. Do this a few Sprints and the team will automatically start to develop a feel for what a story point is.
But in my experience, it is actually even easier than that. At the end of a Sprint, and especially if they have not achieved their commitment, a team will automatically point out the PBI that took longer than expected. It is a question of pride, the natural desire of a Developer to excel at their work.
And yes, it is a gut feeling, and that is perfectly fine. The whole point is that it is the error, not the accuracy, that matters. The worse a team is in estimating, the bigger the margin will be by which they don’t make their commitment, and therefore the more effective the learning will be.
If you are worrying about how bad it is for a team to miss their commitment, realise that that is an output-driven way of thinking. The success of the Sprint is determined by a result-driven output: achieving the Sprint Goal, not a specific amount of work. Focusing on the goal automatically makes the scope flexible, giving the team room plenty of leeway to learn this handy skill.
Story Points are not about getting them right, it is about learning from them. And that is great because it means we don’t need to take the whole thing so seriously! Who cares about whether it’s a 3 or a 5? Endless discussions to reach a consensus? The real conversation happens after, when we talk about whether we achieved our commitment or not.
Knowing that learning happens best when we gamify the learning, this suddenly becomes an opportunity. I myself never do poker sessions anymore, I do bucket estimation. This game is simple: set up a table with the Fibonacci sequence in the title row, and ask the team to individually move PBIs to the column they think is right. Say something stupid like “the one who moves most items gets a price” to make it clear this is a game. Just make sure people have a laugh. If you have a team that is worried about the reliability of the estimates, tell them they will be able to discuss estimates they don’t agree with after the game.
What you will get is a free-for-all where estimation happens in a flash. I’ve had teams estimate 40 items in 10 to 20 mins. And that is including the discussions after.
Conclusion
So there you have it, the value of Story Points. A simple tool that relies on gut feeling and the instinct of your team. Just based on that and the feedback loop the Sprint provides, teams gradually learn to break down their stories to less than 5 story points each.
And once you get to that point — 1, 2 or 3 story points — the learning is done and you can get rid of story points and commitment.
But wait, it gets even better than that. The beauty is that this new skill the Developers have learned not only means they can break down the work reliably, but that they will be able to estimate anything for you!
I’ve had teams where the Product Owner would just casually ask how much some functionality would take, or even a whole project, and the team just as casually giving an estimate in Sprints. The key is one simple rule we all have to agree on:
“The larger the item being estimated, the higher the error margin”
The result is that these teams don’t do ‘classic’ refinements anymore, they do brainstorm sessions in which they break down the work and then give you an ever better estimate.
Who would have thought it, Story Points are a useful and fun tool, which you can best set up as a game, and that is driven by the team's own motivation to ‘win’: be it achieving their commitment, their Sprint Goal, whatever tickles their ego.
And just imagine that moment when you tell your team:
“Congratulations guys, you don’t need Story Points, Commitment of Velocity anymore. You guys are so cool you are doing what many people think is impossible!”
Many thanks to Phil Ledgerwood for helping me with Kanban and Little’s Law.