Estimation sessions dominated by the most vocal team members
Why do the loudest voices win? What my teams do to fix this?
“Estimation sessions usually get hijacked by the loudest developer(s).”
Raise your hand if you have seen this happening:
One or two senior engineers speak first and at length
Other team members (often juniors, testers, UX, etc.) defer, nod, or stay silent
Story points tend to favour the loudest voice over the collective intelligence of the team
Sessions feel longer and less productive.
Participants leave thinking, “Why am I even here?”
Have you seen this?
I bet you have!
And when this happens, the result is regular under or over commitment of user stories for the Sprint Backlog and more meetings to “fix our estimates,” which, to be honest, no one likes.
Why does this happen so often?
And more importantly, what can you do about it?
In today’s post, I will share some techniques that have proven effective with the teams I have worked with in the past.
Let’s get started.
If you’re new to Winning Strategy, here’s what you missed in the past few weeks
Why do the loudest voices win?
“If you know why the fire starts, you can choose the right extinguisher.”
— Fire-safety rule that also applies to meetings
Below are the most common drivers of this kind of dominance.
Recognizing these drivers will help you as a Scrum Master or Product Owner design targeted interventions.
Driver #1: Anchoring Bias
Humans use the first piece of information they hear as a mental “anchor,” even when the anchor is arbitrary.
How it shows up in estimation
Senior dev shouts out, “That’s an 8-pointer.”
Everyone else’s internal range instantly narrows around 8 (e.g. 5–13 instead of 1–100)
Further debate will sound like micro-haggling rather than a genuine exploration of effort
Research
Tversky & Kahneman (1974) showed that merely spinning a “wheel of fortune” with random numbers swayed people’s numerical estimates.
In software teams, studies by Moløkken-Østvold found a 40% reduction in estimate variance when anchors were removed. I highly recommend reading the linked PDF. It’s pretty insightful.
So…
If you consistently see clustered story-point spreads after one voice speaks, you’re watching anchoring in action.
Driver #2: Hierarchy
We often look up to high-status individuals, like architects, principal engineers, or the loud, confident person.
Why?
Because our evolutionary wiring states:
Status = Survival.
Here’s how this shows up
“She has written most of the code. She must know”
Junior devs fear they’ll look uninformed
Product Owner quietly rewrites backlog items mid-meeting to match the architect’s view, instead of clarifying requirements
Driver #3: Lack of structure
Any meeting without clear facilitation turns into a free-for-all conversation, where airtime is determined by personality and not by purpose.
Symptoms
No time-boxes, no speaking order, no visible agenda
People talk over one another and drift into solutioning
Estimates emerge via social negotiation (“Can we agree on a 5 and move on?”) and not discussion
Driver #4: Time pressure
As time becomes more limited, social risk becomes more significant than estimation error.
Under time pressure, most teams tend to quickly come together to maintain harmony rather than focus on accuracy.
You can see this happening when there are:
Late-afternoon refinement when everyone wants to leave
Release train boundaries (“PI Planning ends at 4 p.m. We have to decide now!”)
Facilitators asking, “Can we move on?”
Under time stress, the brain shifts to System 1 thinking (fast, heuristic-based). Disagreeing requires System 2 effort, so silence feels like the rational shortcut.
Driver #5: Blind spot in virtual meetings
In remote settings, (usually) non-verbal cues disappear, making it hard to claim the floor unless you’re already confident.
Here’s how this usually happens:
A slight microphone delay causes people to yield when they start speaking at the same time as a louder teammate
“Mute inertia”: person has a thought, but unmuting feels like an interruption risk
Chat messages are ignored
So…how do we fix this?
Before we jump into “tips & tricks” (that my teams have been using), I think it is important to note what we’re really trying to fix:
1. We want to re-balance airtime, not egos
The goal IS NOT to silence senior engineers; it’s to make sure everyone else can be heard just as easily. A good fix will raise quiet voices without muting experienced ones.
2. We want to replace accidental influence with intentional structure
When dominance arises from randomness, such as the first speaker, loudest mic, or shortest deadline, our fix must introduce deliberate guardrails to level the playing field.
3. We want to surface the information and then let the team decide
Things like estimation should be an information gathering activity first and a decision activity second. The fix must help the team explore the unknowns before they decide on a number.
4. We want to optimize for “Psychological Safety” AND “Speed” simultaneously
Most people think you must choose between “inclusive” and “efficient.” The best practices, however, do both. The meeting time decreases because everyone knows exactly when and how to contribute.
5. We want to make bias visible and then make it boring
Once a team can see what’s going on, i.e. who speaks first, how estimates cluster, etc., they quickly normalize better habits. The fix, therefore, must focus on exposing, not shaming.
With these principles in mind, let’s look at the process my teams follow to fix this problem.
Using Silent, Simultaneous Techniques
Why do we call them “Silent, Simultaneous Techniques”?
Silent because…
Each participant makes their decision without speaking first.
The initial act, i.e. choosing a card or placing a dot, is done privately, so no voice can anchor the group using their tone of voice, confidence, or seniority.
Simultaneous because…
All individual choices are revealed at the same instant: cards flip, dots appear, boards unlock.
Since every vote surfaces together, nobody can “wait and see” which way the wind is blowing before committing.
Bundling these two neutralizes the two distortions below:
Anchoring bias (first number rules)
Status bias (highest status voice rules)
Prep work before the estimation session
“Preparation removes the oxygen that lets one loud voice set the room on fire.”
1. Slicing stories until they “could finish in ≤1 (or 2) day”.
Why ≤1 (or 2) day?
When the size is small, anchoring bias becomes less effective and consensus forms faster.
If a story resists slicing (it is difficult to split), park it for a structured Backlog Refinement meeting. Don’t try to hash it out inside estimation.
2. Attaching the Definition of Ready checklist to each item in the board.
Definition of Ready = a contract that says, “We won’t waste time estimating half-baked work.”
Example Definition of Ready
☐ Business value statement present
☐ Acceptance criteria (Gherkin or bullets)
☐ UI/UX link (Figma, screenshot, or ‘N/A’)
☐ API / contract link (OpenAPI, protobuf, etc.)
☐ Non-functional constraints (perf, a11y, i18n)
☐ Dependencies listed & either resolved or scheduled
☐ Story sliced to ≤1 dev-day of effort
☐ Test strategy sketched (unit/integration)
☐ “Unknowns” section empty or converted to Spike ticketsScrum Master (or PO) can enforce the rule that says: A ticket cannot move into “Estimating” unless every DoR box is checked.
3. Sending the context to everyone
The PO or a Senior Developer usually does this.
Share the context information 24h (or more) in advance, which includes links to design, spikes, PoC notes, etc.
This helps quiet thinkers come to the meeting well prepared. Extroverts can’t dominate with surprise info.
Here’s how my team’s flow looks:
PO (and the team) slices backlog items until each satisfies the ≤ 1 day rule (we keep the window extra narrow)
Each ticket must show a green “DoR” label to enter the Estimation column
PO publishes the Context information on Wednesday 10:00 am
Team reviews asynchronously, comments by Thursday 10:00 am
Estimation session Thursday 14:00 runs with blind voting, high/low explain, and rarely exceeds 20 minutes.
Facilitation tips for Scrum Masters
Here’s what I see them using:
#1: “Parking Lot”
When two voices duel for more than 1 minute, they park the detail for a spike ticket. Decide on size now, and explore the solution later.
#2: “One Breath Rule”
Each speaker may talk until they need a second breath. This forces concise articulation and ALSO levels the seniority gradient.
#3: “Fist of 5”
After the discussion, everyone uses the fist of 5s technique to indicate confidence in the estimate.
Low confidence? Schedule a follow-up instead of endless debate.
#4: Working Agreement
They added “All voices matter” and “Challenge ideas, not people” to their Team Working Agreement.
#5: “No-Anchor” Rule
They start the meeting with:
“Quick reminder: we operate under a No-Anchor Rule. No one voices a number or size until we all reveal together. If it slips out, I’ll interrupt and we’ll reset. No blame, just process.”
The second somebody says a number, the facilitator says,
“Hold that thought. Remember, no anchors. Everyone choose privately first.”
#6: Separating Size from Complexity
The team first lists complexity drivers (like integrations, unknown tech, test data, etc.) in a shared doc. Only after this is done does the team start sizing.
Separating the discussion about complexity drivers from the act of assigning a number forces the team to surface facts first and opinions second.
Listing complexity drivers = divergent thinking (brainstorm risks, unknowns).
Sizing = convergent thinking (collapse to a single number).
Mixing the two confuses the brain and rewards whoever speaks loudest.
This is facilitated in the following manner:
Example
Story: “As a user, I can reset my password via email.”
Complexity brainstorm produces:
SMTP integration (new)
Token encryption key rotation
Rate-limiting on endpoint
Data-retention check
Team privately votes. And then simultaneous reveal: 3, 3, 5, 2, 5
Outliers (2 vs. 5) debate discovers the 2-pointers missed Data-retention nuance. Final call = 5
Complexity drivers list (brainstorm risks, unknowns, etc.) is pasted into Jira for future reference
That’s how they do it…
The most effective Scrum teams ARE NOT free of loud voices. They put guardrails in place so every voice can be heard.
They engineer silence into the process (simultaneous reveal)
They codify expectations up front (working agreements)
They split backlog items until any single one could be finished in less than a day
They don’t estimate anything that hasn’t met a visible Definition of Ready
They arm every teammate with the same context 24 hours in advance
They run estimation as a facilitated experiment (blind votes, time-boxes, high/low first) instead of an open mic debate
No guesswork.
Just shared understanding and a forecast that the whole team owns.
Show your support
Every post on Winning Strategy takes ~ 3 days of research and 1 full day of writing. You can show your support with small gestures.
Liked this post? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone who would find this helpful? Make sure to recommend it.
I strongly recommend that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.
Further Reading
Connect With Me
Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America's largest banks.
