At its core, the anchoring effect is a decision-making shortcut. Our brain grabs onto the first number or idea it sees our “anchor” and uses it as a reference point. Every subsequent judgment or estimate tends to drift toward that anchor, even if it’s arbitrary or irrelevant.
Example in IT: When estimating how long a sprint task will take, if someone first suggests “three days,” most of us will unconsciously adjust around that, rather than making a fresh, evidence-based estimate.
Cognitive Biases are mental shortcuts that help us process information quickly but at a cost. Here’s how anchoring compares:
Anchoring Effect
Relies on the first piece of info as a reference.
You might start code review thinking “this will take an hour,” then any estimate you give hovers around 60 minutes.
Confirmation Bias & Confirmation Bias Meaning
Our tendency to seek or interpret info that confirms what we already believe.
If you think a library is buggy, you’ll notice every glitch and disregard smooth performance. That’s confirmation bias meaning in action.
Dunning Kruger Effect
When novices overestimate their skill level because they don’t know enough to see their own gaps.
Pair that with anchoring, and a junior dev might anchor on a confident estimate, unaware they’re underestimating complexity.
Together, these biases can create a perfect storm: you anchor on a low estimate, seek evidence to support it (confirmation bias), and then lacking deeper expertise you truly believe it’s accurate (dunning kruger effect).
Planning Poker Gone Wrong: If the team first throws out “5 points” for a user story, everyone else tends to cluster near that number even if their personal gut says “13 points.”
Salary Negotiations: As in my story, the first salary offered often becomes the ceiling for negotiations.
Bug Severity Ratings: An early assessment of “medium severity” can make you less likely to flag related issues as “high priority” later on.
I once led a project where initial estimates were wildly optimistic. We’d all nod and say, “Sure, two weeks.” But every sprint fell behind. I realized we were anchoring on the project manager’s first estimate. To break free, I asked each developer to anonymously submit independent time estimates before any discussion. We averaged them afterward—no anchor, just fresh judgments. Our planning became far more realistic.
Delay Exposure to the Anchor. Before you hear someone else’s number, formulate your own estimate.
Use Independent Estimates. Ask team members to write down their guesses privately.
Seek Objective Data. Look at past sprint velocities, bug-fix histories, or code complexity metrics.
Play “What If?” Deliberately consider higher and lower anchors e.g., “What if this takes 20 days instead of two?”
By consciously applying these steps, you can counteract not only the anchoring effect but also reduce confirmation bias and avoid dunning kruger pitfalls.
The anchoring effect might feel like a sneaky mind trick, but recognizing it is half the battle. Next time you’re estimating, negotiating, or prioritizing, pause and ask yourself: “Am I fixating on that first number?” Then apply one of our tips to reset your thinking.
In IT where accurate estimates and clear priorities drive success breaking free from Cognitive Biases like anchoring, confirmation bias, and the dunning kruger effect can transform your career. Go ahead: challenge your anchors, gather unbiased data, and notice the difference in your outcomes.
تعليقات