Get certified - Transform your world of work today

Close

Story Points Do Not Equal Development Hours

23 December 2015

AMLENDU CHOUDHARY
Diebold Inc.


One of my regular challenges is how to estimate a user story by using the number of days or hours necessary to complete the work. Management directly maps the number of story points to the number of days. For example, one story point is equal to one ideal day, which is equal to six hours. There could be two reasons for this simplistic approach. First, it is similar to the Waterfall model for estimation, which most of management is used to. Second, this gives them a so-called quantitative way of communicating the budget and deadlines to management.

While the mapping idea may seem good on paper, it often leads to individuals working toward unrealistic deadlines and estimation clashes during planning. Although story points are estimated mostly by senior developers, a new member will most likely ask for more time to complete the same work.

It's important to note that story point estimation is high-level estimation and shouldn't be used to measure the time it takes to complete a user story. Only after user stories are committed for an iteration can you make hourly estimations for tasks. Task estimation is relative and depends on the individual's capacity and experience. This means that a story point can take four hours, eight hours, or 16 hours, depending on the individual's capacity. At the end of the iteration, we should be able to calculate the team velocity. For a newly formed team, the velocity measure in the initial few sprints can help with figuring out the time needed to complete a feature or a release.

Ideally, story points should be a measure of the amount of work involved instead of the number of hours. That is the reason that Scrum specialists use abstract values, such as t-shirt sizes, to represent story points. This approach to estimation helps us to avoid conflicts during the planning meetings, because the scope of work will remain the same, irrespective of the individuals.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.3 (3 ratings)

Comments

Sayi Sarat Chandra Parvatam, CSP,CSM,CSPO, 12/30/2015 10:55:17 PM
Good thought process - I was just thinking how 1 story point can be equal to 1 day - Is it a practice that is being followed ?
Santosh Shaastry, CSP,CSPO, 1/3/2016 7:01:11 AM
My experience and learnings suggest that a team must identify and agree what amount of work is a 1 point story. It could be adding html markup for a button or adding a new class to the design. Since sizing of user stories is done in a relative manner (if adding a markup for a button is a 1 pointer how much is adding 10 fields?) we must not try and map story points to hours/days of effort.
Tim Baffa, CSM, 1/4/2016 8:35:07 AM
Santosh, it is up to the team to agree on what a 1-point story is, if they plan to use 1-point stories. What is important is that the team have consensus on what all story sizes represent. You are right - it isn't about the effort, but the size of the task irrespective of who does it.

In the past, I have started by having the team group backlog stories into similarly-sized categories. Almost always, the team will come up with 4-5 categories of "scope". From that point, it really doesn't matter what values they want to assign, since each category represents an order of magnitude. The team can select 1-2-3-5-8, or 3-5-8-13-21, or any other Fibonacci range - doesn't matter.

The team can then revisit their sizes periodically to evaluate how they are estimating. Gather all of the recent "5-point" stories together, and ask the team if they are in agreement that the stories are all similarly-sized. Repeat for all other story point values.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe