Revision as of 18:01, 19 September 2015

Story Points are an estimation tool used by many IT-development teams. Story Points are often recommended in Agile Project Management frameworks and methods such as Scrum, Agile-Kanban or Extreme Programming (XP). The Story Point estimation tool separates itself from conventional tools by being an arbitrary unit of measure that estimates required effort instead of the more tangible and well-known hours. Proponents of the tool argues that Story Points encompass a range of dimensions including, complexity, uncertainty and risks involved in the task. It remains, however, a controversial tool, often because the concept is not well understood, its benefits are abstract and effective use requires prerequisite work as well as medium or long project run-times.

One clear benefit of using Story Points is that it enables the project team to measure the velocity of the team: An hour is always an hour, and in a perfect world the burndown-chart burns with exactly the amount of work-hours you assign to your tasks. This is, of course, almost never the case. Project teams works more efficiently in some periods than other. Overhead also varies through the different phases of the project. By assigning Story Points based on effort to tasks you create an effective tool to measure the current speed of the team. An added benefit is that the perceivable metric often creates a common goal to increase the pace within the project team.

Application and Use

A Story Point is an arbitrary unit of measure, and so, the precise method of application is not well defined, and may vary greatly between different projects and teams. It is, however, very important that a shared understanding and application of method exists within any team estimating using Story Points.

The template method below provides an example application of the Story Point estimation tool. It is in no way prescribed, and any truly Agile team should aim to develop their own approach:

• Step 1: Identify base stories.

Most Agile software development teams will have either general or technical User Stories made available to them at the beginning of the project. From the backlog of stories identify one or more base-stories to serve as reference to estimate the relative size of the backlog.

• Step 2: Make individual "bids" on stories.

Have each team member (including testers, front- and back-end developers, project owners etc.) write down a reasonable "bid" for the story and keep it secret for now. This could for instance be done using the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21...^[1] The bid should represent each member's personal estimation of the effort required to complete the given story. Make sure to underline the importance of not only taking into account the number of hours they believe the task will take to complete, but consider the task's complexity, risks, size and so on.

• Step 3: Have each team member explain the reason for their bid.

Taking turns, have each team member reveal and then explain his reasons for the bid. Afterwards, discuss in the group the required effort to complete the task and reach a consensus before moving on. Especially pay attention to the outliers and never just average the bids. An example of why this is important has been outlined below: In an Agile team estimating using Story Points, a back-end developer with a lot specialized knowledge has made a bid on a User Story he is very likely to develop some time in the future. Using his considerable knowledge about this kind of story he has decided to make a bid of 13 Story Points. Meanwhile the project owner, who was in charge of writing this particular User Story has failed to see the technical difficulties in implementing this (he thinks) rather simple story. Therefore, he has made a bid of just 3 Story Points. After some discussion between the developer and the project owner it becomes apparent that what the project owner actually wanted delivered was far less extensive than what the back-end developer had read from the User Story. Following, the User Story was quickly rewritten, another round of estimations took place and the team reached a consensus of 5 Story Points for the Story.

• Step 4: Reach consensus for assigned Story Points.

Through group discussion the team should reach a consensus value for each story. This particular endeavor gets easier as the project progresses; this is because the amount of reference stories will grow, making relative estimation faster and less demanding. With enough reference (base) stories the project team will simply have to reach a consensus if the new story requires more, less than or the same amount of effort than a couple of the base stories.

• Step 5: Break down stories.

Once in a while, the team will reach the conclusion that a story requires an extraordinarily large amount of effort to implement i.e. 13, 21, 34... Story Points. This is a good indication that the story can be broken down into two or more smaller stories. As an example a story of 21 Story Points could probably be broken down into 2 stories of 13 and 8 story points, or maybe even 3 stories of 8, 8 and 5 Story Points. The reason an Agile team should always stride towards breaking down large tasks is because the individual, smaller tasks become more manageable while it also facilitates easier Sprint-Planning, reduces the risk of over commitment as well as diminishes some estimation uncertainty.

• Step 6: (During development).

For each story in the backlog, make a rough estimation using the base stories as reference. This will give the team a relative size of the backlog and a gauge of the required effort to implementing the entire project. Before committing a story to a sprint go through step 2-5 to ensure the team is continually working on the same page.

inspiration - (https://www.scrumalliance.org/community/articles/2014/january/a-practical-guide-story-points-based-estimation.aspx, http://www.ascendle.com/blog/a-step-by-step-guide-for-estimating-software-development-free-software-development-estimate-template, https://dev-wiki.maastro.nl/display/SDTP/Estimate+story+points) perils of estimation: http://dannorth.net/2009/07/01/the-perils-of-estimation/ Fibonacci alternatives: http://scrummethodology.com/scrum-effort-estimation-and-story-points/

Limitations

Alternatives

There are a number of ways to estimating and measuring size of software projects alternative to using Story Points. Among these alternative ways are measuring Lines of Code (LOC), Thousand Lines of Code (KLOC) or Ideal Days^[2]. Another obvious alternative is simply to estimate using Hours.

Measuring velocity: How much the team can do in one iteration (sprint) ....

Consider using Story Points just for estimating the product-backlog, while using hours to estimate each sprint.

References

1. ↑ http://scrummethodology.com/scrum-effort-estimation-and-story-points/
2. ↑ http://www.diva-portal.org/smash/get/diva2:400313/FULLTEXT01.pdf