Story points
"Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work." "[1]
Story pointing should be used to:
- Promote curiosity and questions
- Improve the team
- Call out when a story is too complex and needs to be broken down
- Focus the team on the top priorities
Story point should not be used to:
- Compare the performance of people or teams - Every team will story point differently, you can't compare the burndown of one team to another.
- Assign timelines
- Measure productivity
Complexity vs Effort
Thanks @seanholung for educating me about this!
The default is to link story points with effort (or time). So a 3 pointer is equivalent to 1 day of work, or an 8 pointer is over a week. The problem with this approach is that it focuses more on delivery, you end up talking about adding more people or decreasing the scope.
And that's why it's important to link story points to complexity. With complexity, the team will end up discussing:
- What is our confidence level of implementing this functionality?
- What can we change with the UI or UX that would simplify this story?
- What are the unknown risks of this functionality?
- What prior experience will help us solve the problem?
- What investigation do we need to do?
- Who else in the organization might have existing knowledge?
You end up with a very different conversation that is focused more on implementing the solution rather than cutting scope or adding more people.
Example Scale
Story Points | Complexity |
---|---|
8 | Low confidence, need time to research or ask PM to breakdown. |
5 | 30% confident, def complex, but have a rough idea of how-to. |
3 | 50% confident, complex, probably edge cases. |
2 | 80% confident, a bit complex, need to confirm a few things. |
1 | 100% confident, not complex, 3x prior experience. |
0 | 100% confident, 10x prior experience |