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.
While Bacancy Technology uses the traditional method of hours in its agile project estimation. 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:
1. Planning Poker
2. The Bucket System
4. TFB / NFC / 1 (Sprint)
5. Dot Voting
6. T-Shirt Sizes
7. Affinity Mapping
8. Ordering Protocol
9. 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.
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 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.
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?
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:
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.
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.
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:
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.
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
The simple answer to scrum story points vs hours is that the wiser tech experts know better both the workings of technology and the human mind. At Bacancy, our team members have different types of experiences and skills. Therefore, estimation in hours is a sensible choice as it accommodates all types of experiences and skills unlike story points estimation method.
when it comes to choose between agile story points vs hours, Bacancy prefers to use the hours method as our clients are more comfortable with the hours method than the story points method.
Following are some other reasons why Bacancy Technology considers that hours are better than story points:
Ron Jeffries, co-founder of Extreme Programming (XP), has already apologized for inventing the story points as he was actively involved with the team that invented this estimation method.
Jeffries has said, “I like to say that I may have invented story points, and if I did, I’m sorry now.”
Jeffries is of the opinion to avoid the concept of estimation per se, either in points or time. He says that while “normalizing story points…., in the name of easier planning….,” may seem “sensible enough on the surface, it’s too easy to fall into the trap of comparing teams, and, too often, organizations do that.”
He then discusses how story points often compare, track, pressure the teams unnecessarily and how it certainly distracts them from delivering the main product really quickly.
While this age-old debate of story points vs hours often finds itself in a grey area, Bacancy Technology agrees with Jeffries when he says that story points “are frequently misused and that we can avoid many pitfalls by not using story estimates at all. If they’re not providing great value to your team or company, I’d advise dropping them on the grounds as that they are waste. If, on the other hand, you just love them, well, carry on!”
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.
Scale up your remote team and execute projects on time
Bacancy Technology is an exclusive hub of top dedicated software developers, UI/UX designers, QA experts, and product managers with an incredibly rare and hidden talents you will ever come across. We let you access the top 1% IT talent from independent software developers to the fully managed teams.
Timezone is never a constraint when you are working with Bacancy Technology. We follow one very simple principle – our developers and your time zone. Hire dedicated software developers from us and make collaboration in a faraway to work according to your time zone, deadline, and milestone.
Whether you are looking for skilled developers in emerging technologies or looking for an extended arms to augment your existing team, we can lend a helping hand in both situations. We are a full-stack software development company with 300+ skilled and experienced software developers whom you can hire at your convenience to address the ongoing business challenges