Estimations in the Face of Psychology: The Anchoring Effect
Estimations play a central role in every commercial software project. Whenever a feature is discussed, planned or scheduled the need for an estimation is not far.
In this blog entry, I want to investigate one bias in particular and its effect on estimations in software development: The Anchoring effect.
Unknown biases distort our relation to reality [1], and lead to misconception and failure. While we can not always avoid these biases in every situation, being aware of them is the first step to work against them.
Anchoring effect
An anchor is the first number or idea that comes up in a discussion or around a topic, and it deeply influences and sometimes dominates the remainder of the discussion.
Answer these two questions for yourself:
- What do you think, is the tallest redwood more or less than 400m of height?
- What is your best guess about the height of the tallest redwood?
In an experiment with visitors in the San Francisco Exploratorium these questions where asked with 400m as high anchor and 60m as low anchor. The answers to the second question then had a mean value of 281m and 94m respectively.
This is an example of the anchoring effect. In countless similar experiments it was made visible.
Traders and sales people know that of course and make plenty use of it, as can easily be observed on any bazaar or many advertisements. 600$ looks like a good deal if the item “before” cost 800$, right?
Everybody entering a negotiation should be aware of the power of the anchoring effect. It is so deeply engrained in the human mind that some psychologists suggest to leave a negotiation alltogether if an outrageous anchor has been set. [2]
Anchoring effect during development
The normal story that goes along with an estimation tells it includes all related work, including code cleanup and tests and so on. In reality, the estimation is just part of a plan, and no plan survives the first contact with reality. Only during development the accuracy of an estimation becomes visible.
The following figure shows what happens when developers meet both the estimation and the real world. The x axis represents time/effort. The estimation is shown in the yellow line. The blue ranges show the effort that is needed to implement the feature in reality. The lower end of the range represents the minimal code changes that make a feature work at all, the upper end includes code clean-up, refactorings and tests. The black cross is the time that is reported by the developer for a particular feature.
On tasks 1 and 2, the estimation is somewhere in the range where a feature can be implemented and some code clean-up and tests can be done. When the invested time meets the estimated time the developer stops working on the tasks and calls it done. Only fellow developers see that more work should be done in terms of code clean-up and tests. But the estimation anchor is set and the time is used up, so everybody agrees that the task should be ended. Task 3 was clearly underestimated, so the work is stopped when the feature barely works. The developer is not proud at all about this feature, but it “took long enough” and he is happy to have not overshoot the estimation by too much. The team proceeds to hold this feature like a hot iron, nobody wants to really touch it. Luckily, task 4 was overestimated. The developer takes the chance to do some of the clean-up that was missing in task 3.
On a construction site nobody would get away with only partially cleaning up after himself or leaving out important quality assurance tasks. But in code these things are mostly only visible to developers, and when the pressure of the estimation anchor takes hold, everything is up for negotiation.
In this figure, tasks 1, 2 and 3 were underestimated. The overestimation of task 4 was barely enough to make up for the worst sins committed in task 3. The developers did not have to admit that however and delivered something somewhat on time. The effects will only be visible in the cumulative effect called technical debt.
This is disastrous for the project, and because it happens everywhere it is disastrous for the reputation of software development. The reason why construction sites can be kept to much higher clean-up and quality assurance standards is because many of these things are plainly visible. The reason why they are held to these standards is because of regulations in the face of obvious safety hazards. Robert Martin fears that such regulations will be imposed on software developers by society if we don’t get it right ourselves. [3]
I have witnessed the described behaviour in this figure multiple times. In my opinion there is actually not only the anchoring effect at work, but also another effect called “loss aversion”, but I leave that topic open for another blog entry. Many projects even add other types of pressure on top of that, thus making sure that almost no task is ever completed correctly.
So, one part of the solution is straightforward. An implementor should not know the estimation of the task he is working on. Instead he should be encouraged to do the work right. It also may help to remove the word estimation altogether. Andy Hunt has suggested to use the word projection instead, and he has given some advice on how to work with them [4]. It is worth to note that projections are necessary for project planning, but do not affect the daily work of the developers.
Anchoring effect and Planning poker
The best practise for gathering estimations in many agile workflows is planning poker. In planning poker, the participants of an estimation decide on a number without telling each other verbally. Instead, they pick a number from a defined deck of cards. When all cards are concealed on the table, they are turned around. If all cards show the same number, it is taken as the estimation. If they differ, a discussion is necessary.
Be aware that planning poker protects from the anchoring effect only during the first round. After the cards are shown the first time the anchoring effect can take hold, especially with but not limited to acquiescient participants who will regress their next estimation towards that of their more self confident peers.
The first round of a planning poker can give valuable insights by highlighting where discussion is necessary. When two people with hugely different cards explain their reasoning, a second round can limit discussion time to see whether a common understanding of the topic has been found. If this was not the case, there exists a disagreement. Further discussion may resolve misunderstandings in some cases, but most of the time the most efficient way is to accept a disagreement. Some teams end a planning poker game for a given story only after all cards show the same number. The team dynamics that lead there show more about the power structure within the team than how long a particular task will take to be implemented.
I recommend to note down an estimation range and get on with the stories to not waste time.
TLDR; The anchoring effect is a powerful psychological effect that can seriously harm software projects. Project stakeholders should be aware of this effect and take measures to remove it.
[1] “Thinking, Fast and Slow”, Daniel Kahnemann (Penguin) [2] “Thinking, Fast and Slow”, Daniel Kahnemann, Chapter 11 [3] https://blog.cleancoder.com/uncle-bob/2015/11/27/OathDiscussion.html [4] An article about Estimates in GROWS: https://growsmethod.com/articles/about_estimates.html
