Remember when you were a kid being told to eat your vegetables? Even though you know they’re good for you, you just don’t “wanna” sometimes. Story point estimation can be similar. It can feel like an extra meeting in your already busy schedule. IN spite of several story point estimation mistakes, it’s well worth it.
Story point estimation happens during backlog grooming or during sprint planning. When complete, it provides a relative assessment (estimate) of how complex each of the stories will be to get it to “done”. It also tells the Product Owner how many and which stories can fit in the sprint, which might affect the Sprint Backlog. Product Owners can also use this as a tool in discussing the work with stakeholders. Benefits of story point estimation include estimations with a longer shelf-life, time-saving, and better metrics.
It’s important to be aware that there are common mistakes to avoid to fully realize these benefits.
Mistake #1: Not involving the entire team
While story point estimation is just that–an estimation–precision is still a worthwhile goal. Estimating with just one person, even your most senior team member, is a mistake because of their limited perspective. A test engineer will view the work differently from a developer who will view it differently from UX. Including the entire team will increase consistency and learning.
Mistake #2: Settling for Average
If one person estimates a story at 1 and another at 13, do you take the average of 7? Not unless you want the team to miss out on a great learning opportunity. Taking the average is the Scrum equivalent of sweeping something under the rug. Instead, encourage conversation between the opposing viewpoints (a.k.a. outliers) and let each person explain the reason for their estimate. The whole team will learn from this conversation, and get a clearer understanding of the work. After that discussion, the team re-estimates.
Mistake #3: One Estimating Round
More rounds of estimating means better and more complete understanding of the work when there are outliers. (See above). Only when necessary, of course. If the team agrees during the first round, there’s no need for more.
Mistake #4: An exact number, not a range
Whether using Fibonacci or T-shirt sizes to express size, remember that the value is relative to its neighbors, not an exact amount. A story that’s an “8” is between 5 and 13, it’s not an 8.00. If you think of it as a range (“between 5 and 13” or “bigger than a 5, smaller than a 13”), the number does a much better job of representing the uncertainty during the estimation process. For teams just starting with story point estimation, it might be easier to get into the estimation mindset using something fuzzier like t-shirt sizes.
Mistake #5: Relating a point to a unit of time
It is tempting (especially for managers and product owners) to equate story points to time. Don’t give in. With story points, there can be a range but it’s not a direct relationship and it won’t be valid. Remember that story point estimation compares one story to another in terms of complexity or difficulty. Unless you are tasking out a story, it is not worth exploring the relationship between the work and time. Mike Cohn does a good job of explaining the relationship between the story point and hours systems. In his post, he shows why 1-pt stories can have the same hours as 2-pt stories.
Story point estimation is a tactic that benefits product owners as well as the entire team. It enables product owners to understand how much work the team can commit to based on what they have done in the past, and it allows all members of the team to understand the work by examining it from all angles. We will continue to explore story point estimation in the next few weeks. If you have any ideas or questions on the topic, please share in the comments below.