When making decisions, our thought process is continuously tainted by cognitive biases[1]. The process of effort estimation for software development is not shielded from this problem, especially the form of estimation called Expert Estimation[2] at the base of the majority of Agile estimation methods. Here we will look at 4 biases in particular; the anchoring bias, the framing bias, the curse of knowledge, and the well travelled road effect.
Although you should always be mindful of those 4 biases, we will look at them from the perspective of estimating using references and estimating completed work.
Using Estimation References
When applying Agile relative size estimation methods, many teams tend to use reference items to kick-start the estimation process. For example, a team is starting a new Planning Poker session and has nothing to compare the first story against. Often, this results in asking "What is 1 point worth?". This question is loaded because many people will interpret this as "How long, in hours or days, does 1 point take?" which will create, in the mind of the team members, a fix relationship between the Agile points and time. But let's leave this point-vs-hours discussion for another post and look at how the teams often answer the problem of estimating the first item. They look for one or more reference items and those will trigger some of our biases. Let's look at two.
Anchoring Bias
"It's hard to move away from the references"
This is the tendency to relate too much to the reference item when trying to estimate the size of a new item. If a similarity is found between the new item and the reference, the estimators often inflate the importance of that information and perceive the two items as more similar than they are. As a result, the estimations value will tend to cluster near the reference(s) value(s) and not be distributed properly across the size scale.
Framing Effect
"Different conclusions from the same information"
This happens when the context(frame) in which an item is presented impacts the estimation, even though the item's information is the same. Here are some possible situations; new information is presented while framing (why is this new information not part of the item's description?), the emphasis is put on one aspect of the item's information, pressure or emotional arguments are used to steer the decision, or a cognitive bias or logical fallacy is used to set the context.
How to avoid this
Instead of looking for a singular estimation number, look for a range in which the estimation will fall. Start by looking for the two extreme cases of the lower range and the upper range. This will give the team a wider selection of estimations based on the different arguments supporting the lower and upper range.
Present the information in an impartial way. Let the known facts speak for themselves. If you detected that there is a framing effect present, try to also present the item from the opposite point of view. If you do arrive at two different estimations based on the framing, ask yourself if some of the framing information should be officially added to the item description.
On the other hand, you could avoid introducing reference(s) in the estimation process you are using. Find ways to make your current estimation method work without the need for references or switch to a method usable without references (e.g. Bucket Estimation) or, even better, a method designed to work without references (e.g. CrumbScale)... shameless plug.
Estimating Completed Work
It is very difficult, if not impossible, for our brain to disregard known information while making a decision. This is a double edge sword since, on one hand, experience increases experts' precision and accuracy in their estimations. On the other hand, This can be problematic when trying to estimate incomplete and completed work at the same time and can result in having similar backlog items with different estimations. Here are the 2 biases linked to this problem.
Curse of Knowledge
"Inability to look at an item from a different perspective"
Future work is full of unknowns and potential dangers. As we contemplate the effort needed for new work, we assume that many scenarios are possible. On the other hand, if we already completed this work, it is hard to imagine a possible outcome other than how it actually unfolded. Hindsight only gives us 20-20 vision on one scenario and makes it very difficult to give similar weights to other possibilities.
Well Travelled Road Effect
"Underestimating known items and overestimating unknown items"
If the team has experience on a type of work needed for a backlog item A and no experience on the type of work needed for another backlog item B, this bias makes it hard not to underestimate item A and overestimate item B. This disparity in estimation get amplified if item A is a current item of the backlog and item A is completed while no item of type B is completed.
How to avoid this
Estimate all backlog items during backlog grooming sessions, well before work begins on those items.
Do not reestimate items once they are completed. This 'reestimation' subject also deserves a separate post but let's say that this will lead you down a domino cascade of reestimation throughout your backlog.
One last trick: Read the Wikipedia List of cognitive biases[1] once a year, identify your worst personal biases, and work on improving those during the year.
References
[1] List of cognitive biases, Wikipedia
[2] Szwed, P.S. (2016). Expert Judgment in Project Management: Narrowing the Theory-Practice Gap. Project Management Institute, Inc.
image by Jose Navarro, CC BY 2.0
