Excellence in Software Engineering
Estimation Dilemma in Agile: Story Points vs. Hours
09 January 2017

Author: Selcan YAVUZ KADIOĞLU, Agile Coach / Group Manager – UX & Mobile Applications

Effort estimation in traditional software development is done according to the duration in time format: hours, days, etc. While adopting with the Agile methodologies a new term arisen for the estimation: Story Points…

Story points are the unit of the measure used for the overall effort required to implement a piece of work (a story, a task). They are relative estimations and most commonly based on the Fibonacci Numbers: 0, 1, 2, 3, 5, 8, 13, 21, etc.  The use of non-linear scaling with Fibonacci Numbers aims to point out the inaccuracy. This helps team to recognize the lack of precision, instead of wasting time trying to produce exact estimates. Therefore, the story point estimation can be useful when the work to be done has some uncertainty and complexity.

From Agile perspective, here are some advantages to use story points instead of hours for the estimations pointed by Atlassian and by Mike Cohn :

– It is faster
– It is easy for planning with measuring the team velocity*
– It accounts the overall effort of work to complete (For the hour based estimation, non-project related works – overheads, meetings, e-mails may not be noticed.)

Switching from traditional / waterfall process to the Agile may not be a straight-forward action, unfortunately. Management expectations, working habits should be adapted with the paradigm shift. With tailoring the processes and considering the needs, we can find a midway.

If the team is unfamiliar with Agile concept, a transition from hours to story points is helpful until having a common understanding for the user story estimation. An example of mapping between story points and time shown below may be used.

1 story point Less than 0.5 person/day to complete without any complexity
3 story points 1-2 persons/day to complete without any complexity
5 story points 2-3 persons/day to complete without any complexity
8 story points 4-5 persons/day to complete without so much complexity
13 story points 9-10 persons/day to complete with some complexity
21 story points 15-20 persons/day to complete with more complexity
50 story points Hard to estimate the time, complex for now, simplify the story

 

Of course, this style of estimation is just a proposal according to the best practices. “Being Agile” requires team decisions for such common usages and every team can find a better alternatives to become faster and more adaptive.

When the team is experienced in Agile with practices, estimations will be better, more effective and plannings will be more accurate with time.

When and how to take story estimations from the team may be handled with another post.

*: Velocity is the amount of work that a team complete during an iteration. It is calculated with summing-up the story points of completed works. (We will analyze the term velocity in detail with another post for the Agile metrics.)

References:
https://www.atlassian.com/agile/estimation
https://www.mountaingoatsoftware.com/blog/story-points-are-still-about-effort
https://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points
https://www.scrumalliance.org/community/articles/2016/january/agile-estimation-techniques
https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours

Past Articles

Technical Excellence and Agility

Technical Excellence and Agility

We have already started talking about the challenges of distributed agile teams in our previous blog post “Remote Teams in an Era of Agile”. Now, we continue with another topic which is essential to succeed in an era of agile software development.

Navigation