Issuu

STORY POINTS VS HOURS: CHOOSE WISELY; TURN THE BANE OF PROJECT ESTIMATION INTO BOON

www.bacancytechnology.com

CONTENTS

1. Introduction 2. Traditional estimation method of time 3. Agile estimation method of story points 4. Why story points are perceived as better estimation method than hours 5. Why Bacancy Technology uses traditional method of hours over story points? 6. Conclusion: Story Points vs Hours

Introduction

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 3. Big/Uncertain/Small 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.

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.

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 Technology uses traditional method of hours over 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: Easier to understand Project managers and enterprises connect to hours and days more easily due to the familiarity quotient Easier to use for those team which frequently see entry and exits of team members More precise in comparison to points Removes confusion quotient of story points estimation method

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.”

Conclusion: Story Points vs Hours

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!”

Thank You