← Back to blog

Story Points vs. Hours: The Relationship and the Difference

Story points vs. hours is an old dilemma. Learn more about points, why they're better than hours, and also some pitfalls to be aware of.
September 21, 2021 • Carlos Schults
Story points vs hours

"Story points vs. hours" is a common dilemma 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 teams? Why not simply use time instead? How do 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 the estimation process 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.

Before we go any further, we must be on the same page when it comes to story points. So, let's start by answering some basic questions about this estimation technique.

Story points definition pull quote

What Are Story Points?

Story points help teams estimate the effort/complexity of implementing a given user story. They 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 more challenging still.

Finally, story points are highly contextual. They only have meaning within the boundaries of a single team. As you'll soon see, estimation is a team process in which the goal is to reach a 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 estimation 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 the 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 discovering 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.

Having covered the basics about story points, let's go a bit deeper in our investigation, exploring why points are used in agile and their relationship with hours.

Story point estimation process pull quote

Why Are Story Points Used in Agile?

First, you don't necessarily need to use story points in agile estimation. 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.

Some teams 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 of software estimation:

  1. We're hopelessly bad at it.
  2. There's an intrinsic uncertainty involved in software project management, particularly the 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?

Estimating the number of hours for a task has one big problem. Different engineers will take different amounts of time 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 time estimates for the same story.

However, the story's complexity relative to other ones would stay the same, regardless of the difference in developer skill. The consensus is that story points can provide what hours can't.

The benefits are immense. After many successful iterations, the team will improve their estimation skills, accurately estimating their iteration capacity. 

Suppose you know the individual capacity of each developer. In that case, 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. You'll have a more accurate estimation.

Beware: Story Points Can Go Wrong

As a tech or team lead, you'll probably track the number of story points your team delivers during each iteration. Based on that, you can calculate their team velocity, which helps you understand and estimate their work capacity.

Agile velocity is a valuable metric if used correctly. However, teams often abuse it, transforming 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 economic incentives for engineers to game the metric, guess what? They'll probably do it! This will lead to story point inflation, causing velocity to cease being a useful metric, making estimation harder, and destroying the team's morale.

Story points meaning pull quote

"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 X 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!

Use the Right Metrics

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.

Improve your engineering organization at every level with linearb
Want to improve your engineering processes at every level? Get started with a LinearB free-forever account today!

Further Reading

Join our community of data-driven dev leaders

Each week we share stories and advice from engineering and product leaders striving to be better for their teams.

LinearB may send you email occasionally about how you can optimize productivity.
We will not share your information with anyone. Ever.