“Story points vs. hours” is a common dilema for newcomers to agile. You might have trouble understanding this even if you’re not such a newcomer yourself. Why do people recommend story points estimation in agile? Why not simply use time instead? How does story points differ from hours? These are some of the questions we’ll answer in this post.
By the end of it, you’ll know:
- what story point estimation really looks like and what the benefits of using it are
- how estimating in story points differs from using hours and why you should prefer one over the other
- what teams shouldn’t use story points for—but often do.
Regarding the last point, we’ll also talk about one important pitfall related to the use—or rather misuse—of story points estimation. This pitfall might generate terrible consequences for your team’s morale and performance, and that’s why you should be aware of it.
Let’s get started.
Story Points vs. Hours: The Fundamental Questions
Before we go any further, it’s crucial we’re on the same page when it comes to story points. So, let’s start by answering some basic questions about this estimation technique.
What Are Story Points?
Story points help teams estimate the effort/complexity of implementing a given user story. Story points have some interesting properties. For starters, they are unitless. They are simply numerical points, not having any unit of measurement associated with them.
Also, story points don’t have—and shouldn’t have—an absolute value. (We’ll go back to this point later, but for now, suffice to say that you shouldn’t translate points to hours or any other measure of time.)
Instead, points are relative. They only have a meaning when compared to each other. For instance, a team should expect to complete a user story estimated at one point with much less effort than another estimated at five. An 11-point story should be much harder still.
Finally, story points are highly contextual. They only have meaning within the boundaries of a single team. As you’ll soon see, story points estimation is a team process in which the goal is to reach consensus on the effort required to complete each story. Thus, what “one point” means in one team can be wildly different from its meaning in another.
How Are Story Points Calculated?
You don’t calculate story points. Instead, you estimate them. How this happens might vary according to the team and methodology used.
But in a nutshell, the process goes like this:
- During the planning for the next iteration, the team iterates through the items or user stories selected by the stakeholder—e.g. the product owner.
- For each story, developers express their estimation using numerical points.
- They should do this in a way to prevent influence from more senior members of team.
- Some teams might use a deck of cards, or show a number of fingers after a countdown.
- There are fancier alternatives, such as mobile apps.
- If team members disagree by a large margin, they defend their estimations, arguing why they picked that number.
- The ensuing discussion can lead to important results, such as the discovery of unclear requirements for the user story.
- The estimation ends when a consensus is reached for the given story.
As you can see, story points estimation is more art than science. Over time, the team will get better in their estimation, having a deeper understanding of their skills and their capacity for work during a single iteration.
Story Points vs. Hours: Going Deeper
Having covered the basics about story points, let’s go a bit deeper in our investigation, exploring the reasons why points are used in agile and their relationship with hours.
Why Are Story Points Used in Agile?
First of all, you don’t necessarily need to use story points in agile. The scrum guide, for instance, says only the development team is responsible for figuring out how to turn the selected stories into an increment of value during the sprint. How they do that is up to them.
There are teams who succeed using different estimation tactics, such as t-shirts sizes. And yes, you could still use hours for estimation.
So, why points? In short, story points estimation helps teams handle two important facets about software estimation:
- We’re hopelessly bad at it.
- There’s an intrinsic uncertainty involved in software projects, particularly the kinds of complex projects that are a better fit with agile methodologies.
It’s incredibly hard to look at a user story and estimate how long it would take to complete it. You might get it right for the easiest stories, but things get trickier as complexity and effort go up.
However, it’s way easier to look at two stories and say, “Well, the first is certainly way easier than the second one,” or “The second one has more straightforward requirements, while there’s a lot of uncertainty about the first one.”
Story points express the value of stories relative to each other. Also, the higher the value, the less confidence the team has in the estimate.
Why Are Story Points Better Than Hours?
Estimation in hours has one big problem: Different engineers will take different amount of times to complete the same task. This is an inescapable fact due to differences in their experience, knowledge, and skill.
An engineer highly experienced in Java might need 40 minutes to complete a story that requires knowledge in that language. A newcomer to the language might need 2 hours. Thus, they would give wildly different estimates for the same story.
However, the complexity of the story relative to other ones would stay the same, regardless of the difference in developer skill. This consensus is what story points can provide and hours can’t.
The benefits are immense. After many successful iterations, the team will improve in their estimation skills, allowing them to estimate their iteration capacity very accurately. If you know the individual capacity of each developer, it becomes easier to plan when you know that developer will be unavailable for an iteration—for instance, due to a vacation or PTO. If Alice’s weekly capacity is, say, 14, and she’s going to be absent for a week, then subtract 14 from the team capacity for that iteration and you’ll have a more accurate estimation.
Beware: Story Points Can Go Wrong
As a tech or team lead, you’ll probably track the amount of story points your team delivers during each iteration. Based on that, you can calculate their agile velocity, which helps you understand and estimate their capacity for work.
Agile velocity is a valuable metric, if used correctly. However, teams often abuse it, which transforms it into the worst possible metric for engineering teams.
I said it, and I’ll say it again: Story points are meaningless once they leave the boundaries of a single team. When team leads forget this, they might abuse velocity by:
- using it as a comparison metric between teams
- measuring developer performance
- using it as a predictor of delivery dates
To make matters even worse, they often tie this abused metric to a desirable outcome like bonuses, creating perverse incentives. Always remember Goodhart’s Law, often paraphrased as: “When a metric becomes a target, it’s no longer a useful metric.”
If you use story points and velocity in the wrong way by creating economical incentives for engineers to game the metric…guess what? They’ll probably do it! This will lead to story points inflation, causing velocity to cease being a useful metric, making estimation harder and destroying the team’s morale.
“How Many Hours Are Three Points Worth?” Is the Wrong Question
The thing about story points that many people and teams have a hard time wrapping their heads around is that points don’t mean anything. Asking “How many hours are n points worth?” is the wrong question.
First, as you’ve seen, points only have meaning relative to other estimations within the same team.
Also, the benefits of points—such as not being affected by differences in skill and experience inside the team—stem from their being relative measurements. Forcing a translation to hours would negate the whole point (no pun intended) of using points in the first place!
Before we part ways, here’s a final thought. You’ve seen that agile velocity, when used in the wrong way, can lead you down a dark path. Don’t let that discourage you from using metrics, though! Tracking and improving the right metrics can certainly make a difference when it comes to the performance of an engineering team. And a tool like LinearB might be exactly what you need to visualize those metrics. You might want to give it a try.
Thanks for reading, and until the next time.