I guess that most of the discussions around any part of Scrum that I participated in so far were related to estimating. Should we estimate in hours or in those ominous story points, and if we choose the latter, what does a story point describe? Is it the sheer duration of the story? Then why not estimate it in hours and save all the trouble of converting story points to hours? — Or does it describe the complexity? Then how can we make use of the estimations for our release planning? E.g. a complex formula may be implemented quickly (because it can be taken from a book) while implementing a routine thing may take a significant amount of time (because it requires lots of manual work).
Usually, story points are described as a measure of the “size” of a story, where “size” is said to include a number of factors like complexity, duration, risk, and so on.
And usually, no further description is given on how to measure these factors. It is implicitly assumed that people know this already. In this article, I want to produce more insight and intuition on how to estimate in Story Points.
How can we Estimate the Size of a Story?
I think that it is of utmost importance that any team learns to take into consideration that ít is dangerous and wrong to restrict their estimations to just the time it takes to type the code into the editor. Instead, the estimations need to reflect the possible duration of a number of aspects:
- Complexity: It takes time to think about possible solutions, to do some research, to decide which way to go, to implement some spikes, and so on.
- Risk: What can go wrong with the story, how much uncertainty is in the solution we are likely to favor? How much experience does the team have with this solution? How much extra time should be added to cover these issues
- Implementation: How long does it take to implement the desired solution? How much time do the automated tests take? How many tests do we need, and what kinds of tests? Do we need manual testing as well? Do we need to refactor the code? Maybe we even need larger code restructurings or architecture discussions?
- Deployment: What is required for deployment? Do we have an automated build system in place or does it involve manual work? How long does it take to start the application and to inspect the new feature manually? What if we encounter problems?
- Interdependencies: Is the task dependent on results that are not available yet? Is there any coordination required before the work can start? How long does it take until feedback is being provided, e.g. because the Product Owner is not always available?
The team should become sensitive with respect to these issues, and the team should become aware that simply suggesting a number of hours (while at the same time assuming that this number has anything to do with reality) does not do justice to the spectrum of factors illustrated above.
The sum of all of these aspects is what is usually referred to as the “size” of the story.
The time that needs to be considered until a story is called “done” can only be given as an order of magnitude of this size. And that is exactly what a Story Point is about: It is just an order of magnitude for the size of a given story. Not more, and also not less.