Story points for estimation

Most of the Agile team use story points these days for estimation. In this write up I have attempted to explain about story points , when to use it and when not to use it.

What is a  story point?

Story point is a random measure for estimation used by Agile teams. This is used to determine the size of  effort required to complete the development of a user story.

Remember Story points measures size of effort and this should not be confused with person days required

A story point is usually assigned after considering following factors

• Effort required in development of story
• Complexity of story
• Unknowns or risk factors in the development

While all these may be factors for determining story points one should remember that the purpose of story point is to get an idea of the size of effort required to develop the story.

How to assign story points ?

Pick a baseline story

In the beginning team picks up a baseline story and assigns some story point to that story. Rest of the stories are assigned story points based on their comparative size with the baseline story.

Baseline could be different for different teams. For example one team can assign 5 where as other can assign 3 to the same story.  This is perfectly fine as long as same baseline is used for estimating all the stories of the backlog. Normally these baselines are fixed at organization levels so that matrix from one project can be used for planning other projects.

Planning Poker for estimation

Planning poker is among one of the popular techniques for story point estimations.  Here a team is formed for estimation. It may constitute the entire project team or some selected representative depending on project structure. It is recommended to have representation from QA and design team also while doing estimation. 

Each story is discussed and individual estimations are made for each of participants. If there are wide difference between estimators then brainstorming is done with reasoning for each estimate. After discussion re estimation is done. This process  continues for each story until estimations converge.

Use Estimation series 

Most commonly modified  form of Fibonacci series is used to assign story points. It looks like           1,2,3,5,13,40,100. 

Some teams also use powers of two, or have a scale like 1, 2, 5, 8, 20

The idea is to use a non linear scale which help in making decisions. for example its much easier to say it is more 8 than 5 to say its more 6 than 5.

How can story points be used?

This is used for relative measurement.It is used to compare user stories in a product backlog and give a long term prediction about product release.

Average Velocity of the team can be calculated based on story points completed each sprint. This average velocity can then be used for preparation of release plan .

For Example let say a development team comes up with following data during first 6 sprints :

Sprint 1 - Velocity 28 story points

Sprint 2 - Velocity 28 story points

Sprint 3 - Velocity 32 story points

Sprint 4 - Velocity 30 story points

Sprint 5 - Velocity 34 story points

Sprint 6 - Velocity 28 story points

Based on this data average velocity for this team would be : 30.

This figure can be used for assessing time required to complete items in product backlog.

One should remember that these are high level figures and efforts should also be allocated to some other standard activities while preparing release plan. Some example of the standard activities are :

• Scope for addition of new features and enhancements 
• Effort for bug fixing and re factoring
• Effort for deployment

When not to use story points?

For Sprint Planning

Story point are good tool for doing release planning , they  should not be used for sprint planning. For sprint planning each story should be broken down into required task and effort estimation should be done for each task in hours. This is important because a sprint target is commitment from the team and they should be absolutely clear on what they are committing on.

For measuring productivity of team

Using story points or ideal days to measure productivity is a bad idea because it will lead the team to gradually inflate the meaning of a point.  Team might tend to assign higher story points if   they are being evaluated on productivity as measured by the number of story points finished per iteration.

Productivity can be measured by other means like number of backlog items delivered or % of backlog items completed Vs planned

For relating story points to hours

Story points are not directly related on hours so they should not be compared.

Why use Story points vs Hours / mandays ?

Help in separation of size and productivity

The amount of time it will take to complete an item depends on factors like skill set , productivity etc.

For example consider the distance between two cities in 200 miles. It will take more time to travel if we go walking, less if we go by a car and even less if we fly using a helicopter.  While the distance between the cities is constant , the time it takes to travel vary on the means of transportation chosen. 

Similarly while the size of an backlog item is constant , time it will take to complete the item varies based on team chosen to complete the item. 

Using story points we are measuring the constant which was distance in our example. 

Takes away need to commit time  

Story point based eliminates removes commitment of time from developers. This helps them in focusing on size of problem rather than worry about making commitments.  This is especially important because during initial phases only high level requirements are known and its difficult to give exact time commitments.