We, the humans, are terrible at estimation, mostly unintentionally. However, instead of banging our heads against this rather unintentional human trait, we can try to be kinder and compassionate towards ourselves by accepting the very dynamic nature of all the existing things.

Agile project estimation is indeed a difficult feat. The companies often find themselves getting confused with two major methods of project estimation—the traditional method of measuring the project in hours or time and the newest method of story points.

This blog post is about story points vs hours, but there are 9 agile estimation techniques that use the new technique of story points agile estimation. These nine techniques are:

  • Planning Poker
  • The Bucket System
  • Big/Uncertain/Small
  • TFB / NFC / 1 (Sprint)
  • Dot Voting
  • T-Shirt Sizes
  • Affinity Mapping
  • Ordering Protocol
  • Divide until Maximum Size or Less

Before we attempt to simplify this age-old debate of jira story points vs hours, let us understand the basics of both the traditional estimation method and the story point estimation method.

Traditional Estimation Method Of Time

As the developers and insiders, we know that traditional estimation involves a “bottom-up” approach to prepare near to exact estimation for the project. The bottom-up approach needs to consider each aspect of the project in minute detail to be able to answer obvious questions that all the clients ask: “How long will it take to complete the project?”

These details often include the skills of all the people involved in the project, their speed to work on that project, their availability, and the possibility of emergencies. This helps the managers give the precise estimate of the schedule for a specific project in the units of hours or the days. Now, let’s understand story points vs hours each of them in-detail.

Agile Estimation Method Of Story Points

Agile estimation method adopts an opposite approach which is called a “top-down” approach. In this, the estimation is measured on the basis of the complexity of the project or the efforts that are needed to get it completed. This method of estimation is based on the principle of relativity.

For example, the complexity level of task A is decided in relation to the complexity level of task B. Thus, to be able to give gross-level estimation to the client, the teams look into each aspect of the project, which is relative to the other aspects of the project.

This investigation measures how hard one story is from the other and what efforts are needed for its successful completion.

Why Story Points Are Perceived As Better Estimation Method Than Hours?

The common and often erroneous perception around the story points estimation method is that it gives the teams more freedom to decide their other tasks that need to be completed and a user story in question. It also allows them to identify their skills which are relative to each task exactly.

Since the story points method gives more importance to problem-solving abilities than the ability to complete a certain task in certain hours, it is perceived to be more liberal and flexible than time or hours.

It is against the backdrop of this perception that we intend to explore the following:

  • What are story points?
  • Why use story points over hours?
  • Perceived advantages of using story points over hours
  • What are hours?
  • Disadvantages of using story points over hours
  • Why choose the traditional method of hours over story points?

What are Story Points?

Story points are the unique aspect of agile software development. They are abstract units for measuring the features or the requirements of the application. These features or the requirements are called user stories in agile software development.

These abstract units are often represented by arbitrary numbers such as:

  • 1,2,4,8,16
  • X-Small, Small, Medium, Large, Extra-Large — also called T-Shirt Sizing
  • 1,2,3,5,8,13,21 also called story points fibonacci agile points

These arbitrary units of measurement for user stories convey the team’s difficulty or complexity level. They also measure the efforts required to complete a specific story. As the scrum story points do not represent actual hours, it allows Scrum teams to think in an abstract manner which is supposed to lessen the burden and the stress inherent in the estimation process.

Why Use Story Points Over Hours?

Some companies choose story points as their preferred method of project estimation is the inherent human need to make an informed decision and be more in control of the entire process. And, how does choosing story points over hours make this happen?

Story points estimation method does comparisons between the completed and the running stories. The intention of this comparison is to let team members collaborate and communicate effectively. Let us understand it with a typical example of an estimation session which is a common scene in almost all companies.

A project manager needs to add a feature to one the pages of the product. Using the fibonacci agile points, the PM asks the developers to estimate. He gets 3, 5, 2, and 8.

PM to Dev A: Why did you estimate it at an 8?
Dev A: It needs to be added to multiple pages and not to just one
PM to Dev B: Why did you estimate it at just 2?
Dev B: Oh c’mon. It’s just one small feature. We have so many in this application. Not a big deal!

The first round of estimation allows the team to use their gut feelings and first impressions of the feature to be added. When there is a huge difference among them that gets reflected in these estimations, the second round of estimation talks about the justifications for the highest and the lowest score.

And after a thorough discussion with the team members, they all agree with the 3, a unit from the Fibonacci sequence that represents the task’s difficulty.

This is what the method of story point involves—collaboration and involvement of the whole team. This eventually makes the whole team responsible for the mammoth task of estimation.

Contact Us

Ready to Start Your Project?

Contact Us

Perceived Advantages Of Using Story Points Over Hours

The popular premise of choosing story points over hours is that humans are incapable of predicting the exact time needed to complete any user story. The reason for this incapacity is attributed to the relative nature of the sense of time. Therefore, using arbitrary units as the units of measurement gives the team a sense of objectivity that is needed to complete the project without any fuss.

Some perceived advantages of using Story Points are:

  • It is more accurate: The approximate idea in the abstract units proves to be more accurate and flexible, allowing developers to work at their best.
  • It is quick: The story point saves you from the need to be exact. And, therefore, the efforts to give exact estimation too are not needed. This makes this estimation process quicker than the process that estimates user story at exact days or hours.
  • It gives a sense of objectivity: If a developer can complete one story in 5 hours, the same 5 hours can be either 2 or the 7 for the other. Hence, the estimation in hours is subjective, whereas the estimation in story points is objective, wherein 3 means a particular level of complexity for all the team members.
  • It is in tune with agile and scrum methods of estimation.
  • Since it is indeed a practice or a skill, it certainly gets better as you grow with this practice of making story points based estimations.

What is Hours Based Estimation?

Let us straightaway understand hours by flipping the scene that we saw above in the section: Why use story points over hours?

PM: We have to add this feature to one of the pages of the product. How long would it take?
Dev: About seven hours.
PM: How long would it take for the tests?
Tester: Two hours.
PM: Taking into consideration after-testing additions or omissions, let us then set the estimation at ten hours. Sounds good?
Dev, tester: Absolutely!

This is a very general and the most popular method of estimating user stories. One of the best aspects of this hours method is that it is very easy to understand. It also saves everyone from relying on rather arbitrary units of measurement to estimate the user stories.

Also, a Fibonacci-like sequence such as 1, 2, 3, 5, 8, 13, often used in story points, can be easily used in hours. For example, project managers can easily estimate the user story in 1h, 2h, 4h, 1day, 2day, 4days, 8days, and many more.

Hence, the perception that Fibonacci-like sequence helps make quicker estimations is somewhat not true. The hours estimation too can be quicker and more precise using the same Fibonacci-like sequence.

Disadvantages of Using Story Points Over Hours

The human mind is a wonderful thing. And, it is this wonderful tool that is partly responsible for all the mess that the story point estimation method often creates. Let us understand it in the simplest possible way.

Many times, employees tend to equate agile story points to hours. For example, when the team members attempt to convert story points to hours and say something of this sort, “Three story point = 15 hours “it obviously makes the very purpose of using the story points estimation method redundant.

In a typical scenario, two developers have agreed on the estimate of 3 story points for a specific feature of the product in spite of the fact that their individual estimations of time are surely different.

This exactly is the purpose of using the story points estimation method—to bring people on the same page in spite of differences in individual time estimations.

The moment conversion of story points to hours starts; team members no longer remain on this relatively equal platform.

Hence, when the employees and even top management want to give story points a certain number of hours, it unnecessarily brings the element of complexity in an otherwise simpler estimation process.

It is in this situation that the story points estimation method starts to harm rather than help. And, it is at this time, it is better to estimate user stories at hours or days than at story points.

Some other disadvantages of estimation in story points

  • It takes time to master this estimation skill and determine the real velocity of the team
  • Less transparent way of estimation
  • Not the precise way of estimation
  • Requires stable team
  • So many businesses are hardwired in estimating things in hours and dollars
  • Easy to misunderstand and misuse
  • The learning curve is often a cause of great confusion

Why Bacancy Uses The Story Points Method?

The simple answer to scrum story points vs hours is that the wiser tech experts know both the workings of technology and the human mind. At Bacancy, our team members have different types of experiences and skills. Therefore, story points estimation is a sensible choice as it accommodates all types of experiences and skills unlike estimation in hours method.

One of the main reasons to imply this method is that we, at Bacancy, trust our developers to know what works best for the product. It provides the margin for flexibility and correct estimation as the person who is doing the work is estimating a deadline.

Following are some other reasons why Bacancy Technology considers that story points are better than hours:

  • More accuracy for delivery.
  • Better results as sufficient time is allotted in accordance with the issues.
  • Eliminates time wasted on a shorter project and grants enough time needed for a longer one.
  • Customers are more satisfied with better results.
  • More energy in the development team as they have more freedom.
  • Management becomes easier with an accurately estimated timeline.

Conclusion: Story Points vs Hours

When you have a team with a range of skills and experiences, each project needs to be able to accommodate their skills with the development process, like two perfectly fitted puzzle pieces. For that, the process needs to be more flexible to the one developing it rather than the customer.

These are the things that make the story points method a better fit for a scrum-based Agile environment.

As we see more and more companies adopting this framework, story points method of time estimation is also gaining popularity. That is because more and more people are understanding that this method increases efficiency, which will ultimately result in a happy customer.
And a happy customer is always the end goal.

Frequently Asked Questions (FAQs)

Story points are confusing and not suitable in all situations. They are not right to compare the speed of two different teams. Many a times teams misuse story points to depict their performance.

Story points tend to be a unit of measurement to estimate the effort to undertake a backlog or any other task. By assigning point value to each base, it becomes easy to estimate the entire project effort calculation.

There is a familiarity with hours, unlike story points. You can easily estimate and compare, which is not possible with story points. As the team changes, story points need to be re-done, whereas horse are un-affected.

Each number in the fibonacci series is the sum of previous two. Scrum teams use this fibonacci series to calculate the story points so that they can estimate the relative effort for undertaking particular task as compared to previous tasks.

How Agile Helps in Successful Project Delivery? - Whitepaper


Get In Touch

[email protected]

Your Success Is Guaranteed !

We accelerate the release of digital product and guaranteed their success

We Use Slack, Jira & GitHub for Accurate Deployment and Effective Communication.