If you use Agile, before you start working on an item, it is important to estimate the effort required.
Because then you can estimate the velocity better, which means you can make better forecasts, and you will ultimately have a higher level of trust in the organization.
If you can estimate efforts and velocity well, your teams will also be able load the correct amount of work into scrum sprints. This is important because it reduces stress and sprint spillover (when work is not completed on time within a sprint).
If you have a lot of sprint spillover, a reason can be that the team has started working on stories that are too large. A common root cause for starting too large stories is that the team allows anchoring bias to affect effort estimation.
What is anchoring bias?
Anchoring bias takes place when we see or hear a number, and then have to make any estimates after hearing the number.
For example, a Product Owner asks the team: “This story is pretty small, I think only three story points. What do you think?”
This already anchors any estimates that the team would be ready to make.
Similarly - if an expert in the team says: “I think this story is five story points”.
Just hearing or seeing this estimate before making your own about the size of the story, impacts your estimate.
There are many studies on how the anchoring effect works on humans. As with most cognitive biases, just being aware of them is the first step towards mitigating them.
But since it is important to your development teams to accurately estimate effort, I will now give you some effective tools you can use to reduce the power of anchoring bias in your estimates. So let’s get started!
Make your estimate before sprint planning
Your effort estimates should be done in either of these situations:
- sprint planning
- backlog refinement
- a separate effort estimation session
I don’t recommend leaving effort estimation to the sprint planning, as you will have no time for story splitting if it is needed. It is much better to do the effort estimation in the backlog refinement stage. Be sure to read my previous blogs on refinement techniques (here and here).
Play some planning poker
In planning poker, each team member makes an effort estimate, and the estimates are revealed simultaneously. This is a great way to counter the anchoring effect on individual stories.
Anchoring can influence follow-up stories
Even if you use planning poker, and reveal estimates from team members simultaneously, the problem could remain. The estimate from the previous story starts to anchor the follow-up stories.
Have you noticed that, if you first have a story of 8 story points, it tends to be followed up with more stories of 8 story points. Team members are anchoring to the previous estimate.
The risk is that by estimating stories in a sequence, the important indication of “this story is too large” is hidden behind this anchoring effect.
Reducing anchoring when estimating stories in sequence
What can you do to reduce the impact of the anchoring effect?
Acknowledge the anchoring effect
Acknowledge within the team that any numbers given or shown will impact estimates done afterwards. This is, for example, why estimates from team members are revealed simultaneously in planning poker.
You should also discuss in the team that the estimate for the previous story will impact the next one. Doing this, you reduce the anchoring effect, by giving the team the courage and freedom of mind to begin anew. You are in principle trying to induce amnesia to the team after each story estimate.
Refine stories by organizing them from large and complex to small
If the team struggles to identify the “too large” stories correctly, try arranging the “to be refined” stories in descending order in assumed size and complexity.
When you do that, your larger stories will be estimated first. As a result, stories following them will be anchored higher, instead of the small stories anchoring the large and complex stories.
But please note that with this approach, someone would need to make an assumption about the size and complexity of stories beforehand.
Re-anchor team with a story that was too large
One problem with using story points is that you compare the smallest possible story (one or two points) to everything else. This means you run the risk of anchoring the work too low.
There is a great trick for that:
Use an example story from the past - one that the team understood to be too large in hindsight. This helps the team re-anchor, and to more easily identify similar stories. Every team has such stories in their history, so remind them before estimating sessions to keep an eye out for similar stories.
Bigger or smaller
Here is another thing to try:
In the estimate session, pick a story and give it a story point value. Let's say it receives a value of eight story points.
Then, to avoid anchoring to give a number value, start to compare each follow-up story.
- much bigger (>>)
- bigger (>)
- smaller (<)
- much smaller (<<)
If you are using chat for planning poker, you could use the characters in the parenthesis to quickly indicate your own estimate.
The team could then discuss what “way bigger” meant - is it 20 or even more? If the consensus of the estimate is just “bigger”, the team could settle for 13. A variance of “bigger” and “smaller” could mean to set the size at eight.
Biggest estimate wins
This approach is especially useful in silent effort guessing sessions, where no discussion is allowed. These sessions are meant to get fast estimates for a lot of items. In “biggest wins” or “second biggest wins” you leave out a lot of the small estimates. If you’re in doubt: you want to choose the larger estimate.
Good effort estimates increase the level of trust
It is important to acknowledge the anchoring effect, and discuss it with the team. Experiment with different ways to avoid anchoring, and your estimates will be better. Remember, the main benefit from good effort estimation is reduced sprint spillover and stress, more accurate velocity and better forecasts. It will also be easier to spot too large stories, and focus on work splitting.
Published: Mar 21, 2022
