Anchoring Bias in Estimation: How to Keep Early Numbers and Senior Voices Out of Your Team's Votes

The product owner reads out the story title, goes through the acceptance criteria and adds, almost in passing, "This one's small, maybe a 3." Then the team votes. Five engineers pick 3, one picks 5, and the story's estimated in under a minute. Nobody pushed anyone, and nobody felt pushed.

But the number was in the room before anyone had thought about the work. That's anchoring bias in estimation, and planning poker only handles part of it. A lot of the influence happens before the vote: in how the story's introduced, in who talks first, and in the number still hanging around from the last story. If your team estimates during backlog refinement meetings, the few minutes before each vote are where you can protect your estimates.

Four habits cover most of it: introduce the story without a number, vote in secret, manage who speaks after the reveal, and stop one story's estimate from leaking into the next.

What anchoring bias in estimation looks like in a real session

Anchoring is the pull a number has on you when you hear or see it before you've made your own estimate. In his article on removing anchoring bias from effort estimates, Arto Kiiskinen of Eficode writes that "Anchoring bias takes place when we see or hear a number, and then have to make any estimates after hearing the number." He adds, "Just hearing or seeing this estimate before making your own about the size of the story, impacts your estimate."

That sounds obvious when you read it. In the middle of a busy session it's much harder to catch, because anchors rarely look like anchors. In most sessions they come from three places.

The product owner's hint

The product owner has usually spent more time with the story than anyone else, so they've already formed a view about its size. When they say "this is small, maybe a 3," they mean it as helpful context. It still lands as a number, and everyone who votes afterwards has heard it.

"Should be quick" and "probably a couple of days" do the same job, even though neither one is in story points. Any phrase that tells the team how big the work is counts.

The senior voice

A tech lead says, "Honestly, that's just a config change." There's no number in that sentence, but everyone now has a size in their head. And sometimes the senior person does say the number. Scrum Poker Online's guide to common planning poker mistakes says teams often undermine the method "by allowing senior developers, tech leads, or vocal team members to share their estimate before the cards are revealed."

Nobody does this to manipulate the vote. Senior people get asked for their opinion all day, so offering it is a habit, and that habit happens to land at the worst possible moment.

The previous story

The last story's number sticks around in people's heads too. It's the one anchor a secret vote can't reliably catch, so it needs its own fix.

In the opening scene, the anchor was the product owner's "maybe a 3." The team's 3 might well be right. You just can't tell anymore, because the vote no longer shows what each person would have picked on their own.

Before the vote: present the story without a number

Keeping numbers out of the story introduction costs nothing. According to Scrum Poker Online, "Facilitators should actively prevent discussion of specific numbers before the reveal." That job starts with whoever presents the story, which is usually the product owner.

Describe the scope, the acceptance criteria and the unknowns. Leave out points, hours, days and comparisons to stories that already have a size ("it's about the same as the search filter"). Comparisons count because the other story's number comes along with them.

A three-line intro works for most stories:

1. State the outcome. "When this is done, a user can…" (the outcome, in one sentence)
2. Name the criteria. "To accept it, we need…" (the acceptance criteria as written)
3. Share the unknowns. "What we don't know yet is…" (open questions, risks, and anything you've already ruled out)

That gives the team enough to ask good questions and gives nobody a size to lean on.

When a number does creep in, swap it for the information behind it:

• "Sounds like a 3" becomes "Here's what's in scope."
• "Should be quick" becomes "We already have the API endpoint, so this is the UI part."
• "About the same as the export story" becomes "It reads the same data as the export story, with a new file format."
• "Probably two days" becomes "The part I'm unsure about is the data migration."

If you're the product owner and you've already got a size in mind, that's fine. Write it down, keep it to yourself until the reveal, then share it. A big gap between your number and the team's vote tells you both something. Maybe you know about a shortcut, or maybe they've spotted a risk you missed.

Then open the floor for questions about the work. "What's unclear about this story?" is a good prompt. "Is this bigger than a 5?" isn't, because it's a size question with a number built in.

If someone slips and says a number, the facilitator can say "hold that till after the reveal" and move on. Keep it light. Nobody needs a lecture for thinking out loud, and a friendly reminder works better when it happens every time.

Vote in secret and reveal together

The secret vote is your main protection, because everyone has to commit to a number before they see anyone else's. Eficode calls the simultaneous reveal "a great way to counter the anchoring effect on individual stories." Scrum Poker Online says, "Enforce the simultaneous reveal as a non-negotiable rule. Remind the team that the goal of the private selection phase is to form an independent opinion."

That independent opinion is the whole point of the round. When votes stay hidden, the senior engineer's 8 and the newest developer's 3 land on the table at the same moment. Neither person had a chance to adjust toward the other, so the spread you see is the spread that's there.

A secret-vote round runs like this:

1. Read the story. The product owner reads the story without a number.
2. Ask questions. The team asks questions about the work, and the product owner answers them.
3. Pick a card. Everyone who'll work on the story picks a card.
4. Stay quiet. Nobody talks about size while the cards are down.
5. Reveal together. Everyone reveals at once.

If your team's new to the format, how to run your first planning poker session walks through each step in more detail.

You don't need special tools for any of this. In a meeting room, everyone writes an estimate on a sticky note, turns it face down and flips it on a count of three. Writing the number down before anyone speaks is the low-tech version of the same rule.

On a video call, avoid having people type estimates into the chat one at a time. The first message to appear becomes an anchor for everyone who's still typing. If you do use chat, have everyone type their number, wait, and hit send together on the facilitator's count.

If you'd rather use a dedicated room, TinyTroop keeps votes secret until the reveal and has an optional anonymous reveal that hides names on the cards. Spectators can watch without voting, so a stakeholder can sit in without adding a card.

Handle seniority and speaking order after the reveal

The reveal protects the vote, but the conversation afterwards can bring the hierarchy straight back. When the cards show a spread, whoever explains first sets the frame for everyone else. If that's always the tech lead, the re-vote tends to drift toward their reasoning, and you've moved the anchor from before the vote to after it.

A speaking-order rule helps. Ask the lowest and highest voters to explain first, since their reasons account for the spread, and have the most senior people in the room speak last. Then rotate who opens from story to story, so the same voice doesn't start every discussion.

If you're the senior person, speaking last is a favor to your team. Your reasoning still gets heard, just after the others have had their say. You'll often learn more that way, too, because people explain their own thinking instead of reacting to yours.

Watch for patterns over a few sessions as well. If one person's estimate keeps becoming the final number, ask yourself why. They might be over-explaining their position, or the others might be deferring when they don't need to. Either way, raise it in a one-to-one or a retrospective, away from the estimation itself.

For teams where hierarchy runs strong, I'd try an anonymous reveal. Names are hidden on the cards, so the team sees the spread without anyone's title attached to a number. Whether that changes who people defer to is something your team will have to judge, so treat it as an experiment you choose together and review after a few sessions.

Speaking order is only one part of what happens after the cards flip. For how to hear the outliers without the discussion eating your whole meeting, see handling split votes in planning poker.

Stop the previous story from anchoring the next, and run a bias check

Sequence anchoring is the hardest kind to spot, because the secret vote doesn't stop it. Eficode's Kiiskinen writes, "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."

Name it out loud. At the start of the session, tell your team that the last story's number will pull on the next one. Between stories, make the reset visible: clear the board and read the new story as if it were the first one of the day. If someone says "this one's like the last one, right?", ask them what's similar about the work.

Before you accept an estimate, try one question: "If this number were twice as high or half as low, would we still agree?" Quick answers with reasons from the story mean you're probably fine. If people hesitate, or their reasons point back to the last story or to something someone said earlier, take another look.

Pressure to match a number makes all of this worse. When estimates get used as promises, picking the number someone senior already said feels safer than voting your own. Scrum Poker Online says, "Reinforce the principle that estimates are forecasts, not commitments." Say it at the start of the session, and back it up when plans change: a re-estimate just means the team knows more now.

At the end of your next session, take two minutes and ask the team one question: did any estimate today feel pulled by an earlier number or by a particular person? Skip the hunt for someone to blame. Write down one change to try next time, such as holding the product owner's guess until after the reveal or rotating who speaks first, and check how it went at the following session.

A one-minute check before your next session

• Ask the product owner to introduce each story with scope and unknowns, and to hold any size guess until after the reveal.
• Agree that nobody says a number while the cards are down.
• Decide who speaks first after the reveal, with senior voices going last.
• Remind everyone that estimates are forecasts and that each story starts fresh.

Anchors get into your estimates before the cards go down, so most of your protection sits in the minute before everyone picks a card. Once you've got a clean, independent vote, the next call is whether to re-vote, split or park the story.

If you want a room where every card stays hidden until the reveal, Start a free room and try this routine at your next refinement.