5 Common Story Point Estimation Mistakes

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. If estimating and communicating work is something you continue to struggle with, consider what an agility tune-up can do for your teams. Even high-performing teams need regular tune-ups to optimize current processes and identify new ways to improve.

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.