Smart Thinking

Focalism and Estimation Bias

Anchoring or the Focalism Effect can lead to skewed estimates. What causes anchoring and what estimating techniques can protect you from its effects?

An observation of Focalism… I was recently working on a project that had very little in the way of defined non-functional requirements. I was particularly interested in transaction volumes, scalability, predicted growth and how this impacted environment sizing and number of environments required. Estimates were discussed in technical and business focused meetings. A number of estimates were also produced ‘independently’. The estimate variation was stark, particularly when taken across the three primary groups.

Nudge: Improving Decisions About Health, Wealth and Happiness


The technologists clustered around a certain number, the business stakeholders around a different one and the ‘independent estimators’ were very much ‘left-field’ (or right-field).

Estimation is not exact by definition, but the distribution was interesting and the ‘anomaly’ led me to consider the role of cognitive bias. Could it be ‘anchoring’ (aka Focalism) set within different groups?

Focalism or Estimation Bias

The Anchoring or Focalism Effect on Estimation

During normal decision-making, anchoring occurs when individuals overly rely on a specific piece of information to govern their thought-process. Once the anchor is set, there is a bias toward adjusting or interpreting other information to reflect the “anchored” information. Through this cognitive bias, the first information learned about a subject (or, more generally, information learned at an early age) can affect future decision-making and information analysis. [source: Wikipedia – Anchoring]

The estimate becomes anchored when the product owner says something like, “I think this is an easy job, I can’t see it taking longer than a couple of weeks”, or when the developer says something like, “I think we need to be very careful, clearing up the issues we’ve had in the back end could take months”. Whoever starts the estimating conversation with, “I think it’s 50 days” immediately has an impact on the thinking of the other team members; their estimates have been anchored, i.e. they are all now likely to make at least a subconscious reference to the number 50 in their own estimates. Those who were thinking 100 days are likely to reduce and those who thought 10 are likely to raise. This becomes a particular problem if the 50 is spoken by an influential member of the team when the rest of the team are predominantly thinking higher or lower. Because the remainder of the team have been anchored they may consciously or otherwise fail to express their original unity; in fact they may fail to even discover that they were thinking the same thing. This can be dangerous, resulting in estimates that are influenced by agendas or individual opinions that are not focussed on getting the job done right. [source: Wikipedia – Planning Poker]

Anchoring is a widely used technique. For example, suggesting you make a donation of £10, £20 or £50 to a cause, anchors your perception about what is suitable differently than if the request was for £100, £500 or £1,000. A sweeping generalisation would be to assume your thinking was anchored somewhere in the middle of each, say £20 or perhaps £500.

Parkinson’s Law states that:

Work expands so as to fill the time available for its completion.

Is it not truer to say

estimates of the amount of time taken to complete the work become anchored by influential stakeholders and team members?

An interesting antidote to this bias could be the use of the Planning Poker method described in Mike Cohn’s book “Agile Estimating and Planning”, which seeks to neutralise anchoring.

Agile Estimating and Planning (Mike Cohn)

The Anti Pattern Codified

Anti Pattern Name: The Anchoring or Focalism Effect

Type: Estimation

Problem: Estimates become skewed by the anchoring effect, which can be (accidentally or otherwise) created by influential stakeholders and team members.

Context: Estimation of timescales (analysis, development, testing, management), non-functional requirements (volumetric growth, scalability, number and size of environments).

Forces: Past experience, team dynamics, influential stakeholders

Resulting Context: Inaccurate estimate skewed by bias and a tendency to ‘anchor’ on values that fit with group opinion, rather than concrete reality.

Solution(s): Planning Poker, Multiple Estimating techniques applied to same problem (analogy based sizing, function point counting, bottom up estimates etc.).

Further Reading on Agile and Scrum

By Steve Nimmons

Steve is a Certified European Engineer, Chartered Engineer, Chartered Fellow of the British Computer Society, Fellow of the Institution of Engineering and Technology, Royal Society of Arts, Linnean Society and Society of Antiquaries of Scotland. He is an Electric Circle Patron of the Royal Institution of Great Britain, a Liveryman and Freeman of London and serves on numerous industry panels. He is a member of Chatham House, the Royal United Services Institute and the Chartered Institute of Journalists.