HomeBlogWhy Does Plan...
April 1, 2022
5 min read

Why Does Planning Poker Use Story Points Instead of Time Values?

Oftentimes, people get confused between story points and time values when estimating with Planning Poker. Well, we’re here to clear up the confusion.
Anton Versal
Anton Versal
That's why Planning Poker Use Story Points Instead of Time Values

Without a doubt, estimation is a difficult undertaking. It is one of the most challenging — if not the most difficult — facets of the job for software developers. It must consider various elements to assist product owners in making decisions that influence the entire team and the company.

Product development teams get frequently challenged by management to enhance the accuracy of their estimates, but this is easier said than done. These teams must not only work hard to figure out how to estimate, but they must also choose the best time to do it. Planning poker is a strategy that can help in agile estimation.

This article will shed light on Planning Poker, specifically, why it uses Story Points instead of time values.

What is Planning Poker?

Planning poker is a gamified strategy used by development teams to estimate the effort to complete project management activities. These estimates are more engaging and accurate than other approaches because they are based on the entire group’s input and consensus. Teams utilize planning poker cards, similar to poker cards, to help measure the number of story points for the required activities.

The Use of Story Points

In a Planning Poker session, each project is assigned story points by the entire team.

Notably, estimated using a unit of measurement known as the Story Point is a systematic approach Scrum teams employ. Thus, a question arises: Why use Story Points instead of hours, days, or any other commonly used time values?

A Story Point is a relative unit of measure that individual Scrum teams decide on and use to generate comparable estimates of effort for accomplishing objectives.

The purpose of Story Points is to make team estimation easier. Teams analyze solely how much effort a product backlog item will demand compared to other product backlog items, rather than looking at it and predicting it in hours. With that, another question arises: What is the problem with utilizing time as a measurement unit?

In a nutshell, the answer is because one’s hour is not the same as another’s hour.

When a Scrum Master asks two developers to estimate the same work, they will develop two different estimates. While some of the variations may be due to gaps in the specification or misunderstanding, the truth remains that developers have varying levels of knowledge and experience. Therefore, the same work will take longer or shorter.

When those same two developers get asked to rate the amount of effort required to execute one product backlog item against another, the Scrum Master is considerably more likely to reach an agreement.

Ultimately, story points get provided to break down work into smaller portions better to address uncertainty. This option helps teams realize how much they can do in a given amount of time and create consensus and commitment to the solution over time. Although it may appear counterintuitive, this abstraction is beneficial since it forces the team to make more difficult decisions about the difficulty of the work.

Here are some more compelling reasons to employ story points:

  • Non-project work that inevitably slips into workdays, such as emails, meetings, and interviews that a team member may be participating in, does not get considered by dates.
  • Dates have a strong emotional component. Emotional attachment gets removed by relative estimation.
  • Each team will estimate work on a slightly different scale, resulting in naturally varying velocity.
  • Teams can swiftly assign points without much dispute once they have agreed on the relative effort of each story point value.
  • Story points incentivize team members to solve tasks that are challenging rather than time-consuming. This option helps team members focus on delivering value rather than wasting time.

Story points, unfortunately, are frequently misused and misunderstood. When story points get used to criticize people, allocate detailed timetables and resources, or measure productivity, they go wrong. Instead, teams should use story points to determine the scope of the project and its priority.

Three Ways to Make Your Agile Estimates More Accurate

There is no need to work weekends to make up for underestimating a project's scope. Fortunately, there are a few things teams can do to make agile estimates as accurate as possible:

Working Together with the Product Owner

The product owner is responsible for prioritizing the backlog, an ordered list of work that provides brief descriptions of all required features and fixes for a product in agile development.

When the engineering team starts estimating, questions about requirements and user stories are common. And that is a good thing: those inquiries help everyone on the team understand the project better.

Breaking down work things into granular chunks and estimations via story points aids product owners in prioritizing all areas of work. Thus, it is not uncommon for a product owner to reorder items on the backlog after receiving estimates from the development team.

Including Everyone in Agile Estimation

It is critical to include everyone on the team — developers, designers, testers, deployers, and anyone else essential to the project. Each team member adds a unique perspective to the product and the labor involved in delivering a user story.

If, for example, product management wishes to accomplish something seemingly straightforward, such as support for a new web browser, development and QA must weigh in because their experience has shown them what dragons lay beneath the surface.

Learning from Past Estimates

Retrospectives allow the team to incorporate lessons learned from previous iterations, such as the accuracy of their estimates. Many agile solutions, such as Jira Software, track story points, making it easier to reflect on and re-calibrate estimates. For instance, look up the team's past five user stories with a story point value of 8. Examine whether each of the tasks required the same amount of effort. If not, explain why. Use your newfound knowledge in future estimation discussions.


Project management for agile teams can entail a variety of difficult decisions, ranging from managing product owner expectations to defining quality standards that are not yet defined. Estimation, however, like everything else in agile, is a discipline. With practice, teams will only get better and better.

As you prepare to use Planning Poker in your next product roadmap planning meeting, consider Async Poker.

Read more

March 25, 202210 min read

Estimates from the Viewpoint of Scrum

Estimates help to align priorities, set mutual understanding, and identify dependencies, but there are no rules or standard practices mentioned in Scrum Guide.Estimates are a great resource for teams and organizations to guess what they can achieve, what are the effort requirements, and when they can achieve. When estimates are done rightly, teams get a proper direction path driven by prioritized tasks. In short, estimates are a valuable practice in the…
September 24, 20215 min read

Evolution of Planning Poker into Async Poker and Hybrid Poker

Planning Poker holds a never-ending bond with Agile teams, but its evolution into Async Poker and Hybrid Poker is just game-changing.If we go back in time when the developers and supporters of Agile, Extreme Programming, and Scrum were explaining all the details about their revolutionary framework, they failed to provide instructions about one important aspect, i.e., backlog estimation. Agile teams were aware of the need for…
February 11, 20229 min read

Why the Whole Team should Participate in Planning Poker Estimation Session

Is whole team participation (including irrelevant skilled members) fruitful during Planning Poker estimation? It's a big "YES" and this article proves why.There is a common perception that those team members who will be part of the project should be the ones involved in its estimation, rather than doing estimation with a whole or different non-contributing group. But the situation is a bit complex in the case of agile teams when they conduct product…