The Value of Story Points
When a team first starts to use Agile methodology, the concept of story points can be difficult to accept and understand. Story points aren't an absolute value and that can be stressful for people who prefer concrete timelines and deadlines. They are a measure of effort rather than time. Since most of us are used to date-based or time-based deadlines, this can be a difficult paradigm shift.
Story Points are used to estimate the work effort required to complete a story. They are not a commitment to complete a story in a specified time period. Points allow the team to rank stories based on the amount of effort that it will take to accomplish them. Most of the time, developers don't like to give specific times needed to accomplish a task. Because story points aren't based on time, they determine that Story A will take 3 times as much effort as the baseline to accomplish. In the end, it may end up taking more or less time, but the effort will usually end up being the same relative to other stories in the sprint.
The key concept with story points is that is that they are relational, not absolute. Common systems of scale are linear (1,2,3,4...), Fibonacci (1,2,3,5,8...), Powers-of-2 (1,2,4,8...), and Clothes size (XS, S, M, L, XL). For example, if a team is using the Fibonacci sequence, a story that has 8 story points will take approximately 8 times as long as a story with 1 story point. A 1 point story could be changing a name on a button while an 8 point story could be changing the style sheet for the GUI. It is up to the team to determine what a point is worth and use that as a baseline.
It is important that all of the cross-functional team members be involved when assigning story points. What may seem like a 3-point story to Development is an 8-point story for Quality Assurance and a 1-point story for Documentation. It will encourage negotiation when a product manager realizes that something she thought would be easy is actually more complicated. She might settle for 80% of what she is asking for if it is delivered in 50% of the time, allowing more stories to be addressed in the sprint.
There are a variety of methods for determining story points. Some common methods include general consensus, planning poker, and 3-point estimation. New-to-Agile teams may want to start out by giving a time estimate to each number. This isn't ideal but it does help the team to transition from the time-based estimating to story point estimating. My team currently uses 1, 3, 5, 8, 13 for two week sprints with the following time valuations:
- 1 is a couple of hours
- 2 is a day
- 3 is a couple of days
- 5 is a week or so
- 8 is more than a week but still doable in a sprint
- 13 is too big for one person to finish in a sprint
When we first started, we all referenced the time valuations but after several sprints, we were able to move beyond it into relational valuations.