Nothing else in Scrum generates more confusion than story points. So what are they and just as importantly, what are they not? Here is my definition:
Story points represent the relative difficulty in completing development tasks that produce business value
Note the use of the word 'relative'. They are not an absolute measurement and should never be used as one. I have seen many teams equate story points to hours or half days. Why is this a problem? Well, are all the members of a team equally productive? Do some do particular types of story well and other types of story less well? If you rate a story as 'half a day' do you mean every member of the team should complete the story in a comparable time? No, the idea of story points is to measure a teams output and not an individual member of the team. For example, the team has a typical velocity of 40 points per sprint.
Use of story points
- they are used consistently
- the relationship between the sizes remains the same
For example, a 3 point story might take roughly 3 times as long as a 1 point story. Or a medium story might take roughly twice as long as a small story. The actual ratios are unimportant as long as the team is happy with them and uses them consistently.
The trickiest aspect is usually for the team to define the minimum sized story in a consistent manner. A good approach to this problem is to start each planning session by picking out one story that fits the team's definition of the smallest story size and then base the rest of the estimation around that.
Another thing to note is that points are applied to stories that provide business value. What about other tasks, such as setting up development environments or continuous integration? Well, hopefully you got all those tasks out of the way in sprint 0. Of course, in the real World that is not always the case and some technical tasks will arise that do not directly produce business value. It is important to not assign points to these types of task as they represent an overhead. If you did assign them points then in the extreme case a team could complete 100 points in a sprint but not produce any business value! The team's velocity would no longer have any meaning to the business.
The sprint planning process
Here is a reminder of the format of a sprint planning meeting:
- First half is deciding what you will do in sprint
- Second half is working out how you will do it
We use the points to help us decide what to put in the sprint. In the second half of sprint planning the team will often get down to design details and may even provide 'hour' based estimates of sub-tasks of stories. It is important to remember that this is not really part of the estimating process, it is more related to the desire to limit task size. For example, most teams will try not to have any sub-task that takes more than half a day, so that there is a clear indication of progress.