Views: Islamic Banking

Game of roulette: Software development effort estimation 

- Part I -

‘Knowing software effort estimation is more about biases and human misjudgment’ can help us make better decisions 

Software effort estimation is by definition ‘mapping the unknown’, an approximation game. There are various techniques to estimations including processes like WBS, analogy based estimation, poker planning, models like expert estimations, group estimations etc. The consensus among industry practitioners is techniques, process and tools when used well and topped with right reviews should create reasonably accurate estimations. This is far from the truth !

The role of human biases and influences on development effort estimations is accepted, but they are not widely discussed or accepted. Effort estimations are actually fertile grounds for human misjudgment. 

      "Man is not a rational animal, he is a rationalising animal” - Robert A. Heinlein

For example, it is common to see larger estimated numbers when more people are involved in estimation vs a small team doing the estimates. The probability of a company’s bid being in the range in $1-2m [a number the company has been bidding for large deals] is higher than it is; say $5-10m. The estimations could vary widely based on which team is doing the estimation, the customer budget, size of sales the salesperson has done & the most recent project executed by the same team.

In this series, I will cover Anchoring or Price Anchoring Bias in estimations. Anchoring refers to the cognitive bias or tendency to heavily rely on the first piece of information offered when making decisions. Farnam Street explains Anchoring with wide range of references and examples in our daily lives.

Let us take an example of estimating for a product development. The Company has just delivered a software application with 5000 person hours successfully for Customer X and another application for 1000 person hours to customer Y. Customer X has shared a new requirements which is similar to what was delivered to Y for effort estimation. What are the chances that the effort estimated for the new requirements of customer X is closer to 5000 person hours than it is to 1000 per hours? Yes, chances of it being closer to 5000 person hours is very high.  The fact that customer X is comfortable with efforts of 5000 hours act as an anchor; activities, deliverables and effort are rationalised to justify the numbers.

Let us look at Anchor bias at play in an agile product development: An agile team is poker-planning stories. A developer P has been struggling to deliver 8-point stories in the last two sprints. Another developer Q has delivered multiple 3-point stories comfortably in last two sprints. Assuming all are clear about the requirement, what is the probability that developer P would estimate the new story with 8 points and developer Q would estimate the same story less ? As I have seen in my experience, this is ‘very likely’.

Prof. Dan Ariely, author of ‘predictably irrational’ introduced me to this bias with his wine pricing experiment, during an online course on behavioural economics I attended.

Let us also look at price anchoring at play in a sales situation. A product company is trying to sell its software product into a new emerging market.   

We all know what happens next, product version B never works in the new market! The problem is the customer expects to have the exact same product but at a price anchored lower ! Do you remember Apple iPhone 5C, the lower priced models launched in India? 5c never succeeded. 

I have seen these patterns repeat over and over again in various situations. Deliverables, dependencies and risk are managed, rationalised to match the estimations with the anchor figure. 

So, what’s the big deal, why is anchoring important? In effort estimations, Anchoring bias in combination with authority bias can throw rationale out of the window! I will cover more about new bias in part 2 of the series.