Story Points are one of the most misunderstood topics in Scrum. Are they really that complicated or is it just: 1 point = 1 day?
Context: When do we estimate?
Estimation mostly happens in Sprint preparation, like Refinements or Plannings. In both events the goal is
- as a team to understand the expected result wanted by the customer: What is the minimum we have to do to get a User Story ready for customer feedback gaining
- first thoughts on how to do – not to pre-define every task, but to have first thoughts on how getting started and
- NOT to define what team member is gonna implement a story:
Depending on the stories domain and the developers skillset one team member might be more experienced, means ‘faster’, implementing that story.
Within Sprint Planning, additionally, we are talking about the
- amount of work, that should fit the Sprint, based on our knowledge at this moment and a mostly
- realistic Sprint Goal as our focus for the Sprint, whereby the “realistic” is also based on the stories that can be implemented during the Sprint.
What we need to know
So there are a few things we need to figure out:
- A common understanding of the Story (what to achieve) with some idea(s) on how to achieve the Story:
As soon as the discussion about the Story ends a quick estimation could help uncovering different understandings in what to do to achieve the most simple solution. - Does it fit the Sprint, maybe together with other Stories?
We don’t need to hire a fortune teller knowing: Predicting the future is difficult. So, we just don’t do that: We only focus on the expected complexity! - Should we slice it, reducing the risk not to achieve it within the Sprint?
Slicing the Story we increase the possibility of achieving at least one of the two slices, delivering more value. - Figuring out what Stories are the easiest to implement but most valuable, delivering the most possible value to the customer (thinking WSJF).
Understanding complexity: Visualization
Maybe the best visualization on complexity is given by Ralph Douglas Stacey:
The more we now about
- the users expectancy and
- the possible technical solution
the more clear and thus simple the solution and vice versa. That’s it!