Why story points are better than hours for estimation

February 27, 2013

Story point estimates are a way of estimating Agile projects. Story points are calculated using known tasks as a frame of reference to estimate other tasks. For example, if a task such as creating an input screen, for which we already know the amount of effort required to complete, has been assigned 3 points, we use it as a frame of reference to estimate other tasks based on their perceived complexity. While the estimation of backlog items and tasks is intended to reflect a combination of characteristics such as complexity, effort, and time needed to complete, most customers and many Product Owners focus on the time needed to complete. For them, time is money and hours are the preferred unit of estimation. So, what makes story points better than hours for estimating Agile tasks and Product Backlog items?

Adaptive planning is a key practice in Agile methodologies. This implies that extensive estimating in terms of hours, which is time consuming at the beginning of a project, is not an ideal practice on Agile projects. It is a daunting task to estimate at the beginning of a project. To determine the number of hours required even before any work has started, can not only be difficult but can also be riddled with inaccuracies. It is also difficult to foresee the impediments that arise during the course of the project. Factoring time required to overcome any possible obstacles can make the estimates seem inflated to customers and Product Owners. This is especially true because time is seen as money, and quick mental calculations are being made to determine the “actual cost” of the project being performed. Inaccuracies in the opposite direction can arise when team members are asked to estimate of how long a certain task will take them, and they try to mitigate a customer’s possible objections to high costs by under-estimating the time required. Since the premise of Agile and Scrum is to deliver value, and value is most often defined as the functionality the customer wants, the equation of time and money becomes counter-productive. The value of a particular working program is derived from what it will do for the customer not from how long it took to write it.

Story points reduce the effort spent on estimation so that we can get the project off the ground as quickly as possible. When asked to give an estimation in story points, the team member knows that the answer they give will not be immediately translated into dollars and cents. The motivation for the estimation is to accurately assess its complexity, effort, and resultant time in order to assign it a point value. There is no mixed motive trying to guess and allay assumed monetary objections.

Using hours for estimation can make it difficult to relate to the progress of the project, especially since they are the same units used to measure our workweeks. For example, if a team completes 200 hours of work in one week and 150 hours of work in the next, some might perceive that the team is slacking, even though the fewer hours might be due to the complexity of the tasks or to other non-project related activities such as meetings. Story points estimate the size of the story and do not necessarily have to be linked with the number of hours that might be required to complete it.

For ease of use, protection against biased motives, and clarity of expectation, story points are more useful—better—than hours for estimating Agile tasks and Product Log items.


Leave a Reply

Your email address will not be published. Required fields are marked *


× two = 2


Follow Us On

Post-Plugin Library missing