When there is an urgency to deliver results and deliver them on-time, often the stakeholders take estimates as guarantees and hold team members to every estimate they provide. If the team takes longer than what they estimated, the team gets in trouble. As a consequence, teams start padding estimates and that exacerbates the lack of trust between stakeholders and teams.
Sometimes also higher estimates are not enough and the team finishes late anyway as, knowing that the estimates are too high, they wait too long to start the work and they fail to finish on-time.
As a consequence of this, teams don’t want to estimate at all, or they become obsessed with perfect estimates, as it seems the only way to be right, and discuss each item to a tedious level of detail.
All of this is caused by miscommunication about the meaning of an estimate.
Fortunately we can solve these problems with a shared understanding about estimates, their accuracy, and what they are good for.
I am going to describe four techniques that every team can try and that will help to uncover hidden assumptions and encourage communication both for people who want the answers and for those responsible for creating them.

First thing to do is agreeing with the team which type of estimates they want to go for and share that choice with the stakeholders.
Usually, teams estimating based on the worst case will give higher estimates (and might be right 99% times), on the contrary, teams estimating based on the best case will give lower estimates (and might be right only 10% of times), and finally with a median estimate, roughly half time they will finish faster than estimated and half time it will take longer.
Without a shared understanding on the type of estimate being given, not only the team will struggle to agree on an estimate and estimating takes longer than it should, but also it could happen that stakeholders think they are given the worst case estimate, so they think the estimates could be wrong in 1% of cases, instead the team is providing a median estimate which in 50% of cases is expected to take longer.
The Scrum Master can and should help the team to agree on the type of estimate, then the SM should talk to stakeholders and tell them first which type of estimates the team chose and then remind them that estimates are just guesses and not guarantees.

Anyway, even if stakeholders understand that the team is providing an estimate that might be wrong 50% of times they might still ask for some level of guarantee. In that case a second step for the teams is to add some margin of safety to their project estimate.
If a project is made up of 10 items, with the median estimate 5 might take longer and 5 might take less, my suggestion for the team is don’t just sum up the 10 estimates and tell the stakeholders the delivery date, instead sum the 10 estimates and add some safety margin and communicate that as the plan.

The third challenge is that many teams have a tendency to underestimate and they need techniques to balance underestimating with overestimating. If that is the case, the technique I suggest is to try the bucket estimation with the Fibonacci sequence which reframes the question from ”what estimate to give to the item”, into “which bucket does this item belong in”.
Each bucket can hold estimates up to its size. This way if the team thinks an item is 6 story points, that doesn’t fit in the 5 bucket, it would make the 5 point bucket overflow, so the item has to go into the 8 bucket. Using this technique, the team will have a slight tendency to round up and they are more likely to balance under and over estimates.

My last suggestion is related to the scale to use when estimating. Product backlog items are usually big and the team struggles to choose between two estimates that are too close to one another. They cannot tell the difference between 42 or 43 story points even if they are good at estimates. A good choice could be the Fibonacci series, as in this sequence, for numbers above 3, each number is roughly ⅔ larger than the previous. And it might be a big enough difference to be discernible.

Moreover, as the precision decreases with larger features, teams might find it useful to break the feature into smaller stories or tasks. In one of my revious posts I explored a few simple techniques to split big stories, check out “Splitting User Stories with SPIDR” for inspiration.

This post was inspired by Mike Cohn, https://www.mountaingoatsoftware.com/