Story Points vs Hours: Turn the Bane of Project Estimation into Boon

Table of Contents

Introduction

Humans have always been at the top tier among all the living beings on the planet. Even after tremendous technical enhancements and advancement, they still hustle over a puny estimation issue. Similarly, the Agile Project Estimation is problematic for the product and business owners. Product owners often confuse themselves with the two effective methods of project estimation, Story Points vs Hours, one of which is the traditional method of measuring the project in Hours or Time, and the other one is the brand-new method of Story Points Agile. However, before we move forward with the topic, let us clear ourselves with the fact that there are in total of Nine Agile Estimation Techniques, namely:

• 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

So, now that we are aware of our topic of today. Let us first recall our knowledge of the age-old debate of Jira Story Points vs Hours by reviewing the basics of both the Traditional Estimation and Story Point Estimation Methods.

Traditional Estimation Method of Time or Hours

When talking about the traditional estimation based on hours, the bottom-up approach works the job to help evaluate the near-exact estimate for the project. This approach requires in-depth assessment and considering every aspect of your project. Then the product owners answer the clients’ most dominant question, ‘How long will it take to complete the project?’

Though the question seems simple, the answer is a tad more complex as it depends on factors like the skills of the team involved in the project, their speed of work, the possibility of emergencies, and others. This helps the managers estimate the schedule for a specific project in the units of hours or days.

Agile Estimation Method of Story Points

The agile estimation method adopts an opposite approach called a “top-down” approach. In this, the estimation is measured based on the project’s complexity or the efforts needed to complete it. This method of estimation is based on the principle of relativity.

For example, task A’s complexity level is decided concerning task B’s complexity level. Thus, to give a gross-level estimation to the client, the teams look into each aspect of the project relative to the other aspects. This investigation measures how hard one story is from the other and what efforts are needed for its successful completion.

What are Story Points?

Story Points are the unique aspect of Agile Software Development and are the abstract units for measuring the features or the requirements of the application; they are beneficial to calculate and present an estimate of the efforts needed to implement a Product Backlog Item or any other work completely. For Story Points, the team works to fully implement or assign them to the project based on its complexity, amount of work, risk, or uncertainty. The features or 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.

How to Estimate Story Points?

Now that we know the details of Story Points, it is crucial to know How we can estimate the Story Points, their benefits, and the common mistakes when using Story Points. The core of Story Points Estimation is based on three factors or components:
Risk, Complexity, and Repetition.

• Risk refers to unnecessary demands, dependencies, and random changes within the project development.
• Complexity refers to the facet of complexity or the difficulty of the feature that needs to be developed for the project.
• Repetition refers to the knowledge and familiarity of the team member with a feature and the monotonousness of the task.

Now, that we are familiar with the components Let us have a look onto the Steps to estimate the Story Points:

• Fibonacci Sequence Numbers: helps to better estimate the complexity of the project.
• Formulating the Estimation Matrix for Story Point: involves measuring the efforts more effectively to formulate the estimation table from least to most.
• Involve the Planning Poker Technique: helps to segregate which task will be given more or fewer story points or if the tasks would be incorporated into another story point.

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

Benefits of Using Story Points Over Hours

Several product owners and even Software Development Companies prefer the Story Points approach of the Agile Methodology, and there are many reasons for that. Let us have a look at a few of them.

• Quick Estimation of Issues: The Story Point Estimation allows you to easily and quickly estimate the required work for every item in the Product Backlogs and relatively estimate based on the completed Backlog Items. It also allows getting a proper estimate of the work that can be done in one release.
• No Precise Time Commitments: Story Points Agile frees you from superficial deadlines; you can easily contribute the timeframe to a particular task per your requirement. Also, you are not bound by unwarranted pressure to meet a specific deadline.
• Uncertainty Accompanies the Estimation: With Story Points, one of the best factors is that it captures the uncertainty, like the unavailability of a team member, and keeps you and your team from over-committing, saving effort and time.
• Plan your Sprints Priorly: Another factor that makes Story Points a better option for you is that it helps you better plan and manage the implementation of your work, and its deadlines are effective in helping your team to accomplish goals more effectively.
• Enhanced Performance Efficiency: The Story Points approach gives your team members ample time to process their thoughts and how they will come to life in the end project. This gives the freedom to work on various aspects and deliver the best possible result, leading to better performance and client satisfaction.

Other Benefits:

• More Accurate: The approximate idea in the abstract units proves to be more accurate and flexible, allowing developers to work at their best.
• Gives a Sense of Objectivity: If a developer can complete one story in 5 hours, the same 5 hours can be either two or seven for the other. Hence, the estimation in hours is subjective, whereas the estimation in story points is objective, wherein three 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 a practice or a skill, it certainly gets better as you grow with this practice of making story points-based estimations.

Mistakes to avoid when using Story Points

Story Point Estimation is crucial; hence, a few mistakes must be avoided for the most relevant estimation when implementing the Story Point Agile method.

• Understanding the importance of Efforts while evaluating Story Points, only considering the factors like Uncertainty, Complexity, and Value is not preferred.
• Don’t Convert Story Points to Hours, as it invalidates the purpose of Agile Story Point Estimation.
• Average is not the Optimal Solution with the Poker Planning Technique
• Never readjust the Story Points mid-Sprint, if in case it turns out wrong
• Story Point a new Bug, but not a bug related to a Story Pointed Issue
• No Story Points for puny issues
• Not preferred to adjust the Reference Product Backlogs Item with every Sprint.
• Adjust the Reference Product Backlogs Items based on the experience of the team on Story Point Estimation
• Never Story Point the unfinished issues again.
• Avoid Story Point estimates based on the expertise of the Developer working on it
• Involve the Experts first to understand the tasks and then Poker Plan without them
• Retrospectively Discuss the incorrect Story Pointed Issues

Why Use Story Points vs 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.

Why Bacancy Uses The Story Points Method?

Bacancy is a leader in Agile and Lean Software Development, and thus, the simple answer to Scrum Story Points vs Hours lies in Why Story Point is better than Hours? Let us explain that further, as we know that the wiser ones understand the effective working of both technologies and human minds. Similarly, being the industry leader in software development. At Bacancy, our team of experts includes a wide assortment of experience and skills in various arenas of software, hardware, and embedded development. Therefore, after years of our own experience, we have inferred that Story Points estimation is a sensible choice as it accommodates all types of experiences and skills to come to an effective estimation compared to Hours which is just a probable estimation without any proper study or assessment based on the needs and requirement of the project.

Further, another reason to involve the Story Point methodology at Bacancy is that we believe in the efficiency of our developers, who assess and evaluate the best possible solution for your product. This involves a decent margin for flexibility, and competent estimation as the person doing the work is responsible for providing a proper deadline for the project’s completion.

To understand this further, let us have a look at a few reasons Why Bacancy Technology prefers Story Points over the Hours approach:

• Enhanced Accuracy for Delivery
• Better Results as adequate time is allotted following the issues.
• Saves time on shorter projects which can further be invested for the longer projects.
• Better Results and More Satisfied Customers.
• Energetic Team and Efficient Development as they have more freedom
• Better management as the estimated timeframe is more precise

Conclusion: Story Points vs Hours

Frequently Asked Questions (FAQs)

What are the disadvantages of story points?

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

What is the purpose of story points?

Story points tend to be a unit of measurement to estimate the effort to undertake a backlog or any other task. Assigning point values to each base makes calculating the entire project effort calculation easy.

Why use hours over story points?

There is a familiarity with hours, unlike story points. You can easily estimate and compare, which is impossible with story points. Story points must be redone as the team changes, whereas hours are unaffected.

Why are story points calculated as per the Fibonacci series?

Each number in the Fibonacci series is the sum of the previous two. Scrum teams use this Fibonacci series to calculate the story points to estimate the relative effort for undertaking a particular task compared to previous tasks.

1 Story Point is How Many Hours?

Often, we hear that “One Story Point = 8 Hours,” but the actual case is different; there is no exact metric that can tell the number of hours in Story Point.