Agile teams practise a variety of techniques when estimating, but most of them are rooted in the same basic theoretical concepts, neither of which are new:
- Wideband Delphi – which depends on multiple people contributing to the final answer; and
- Relative Sizing – because humans a really good at comparing things, but relatively poor at precise guesses.
Wideband Delphi was developed in the 1970’s by Barry Boehm and John Farquhar as an evolution of Rand’s Delphi Method. It involves asking a group of informed people to independently provide an estimate, and then applying an iterative process until they all agree. Since the participants all bring unique perspective and experiences, and their estimates don’t influence each other, the process should result in an accurate result.
The process is relatively simple, and its influence can be seen in many agile techniques, such as Mountain Goat Software’s popular Planning Poker technique. In Wideband Delphi
- Each participant is given details of the problem, and asked for their estimate;
- The estimates are summarised and anonymously distributed to the participants;
- Having seen other estimates, the participants submit a new estimate, which may be the same or different from their original;
- This is repeated until all participants agree on an estimate.
This is the basis of many collaborative and iterative estimation approaches. The anonymity helps prevent estimates being influenced by particular team members (Halo Effect) – if you don’t know what the product architect’s estimate is, it can’t influence your decision – although the inability to discuss why participants chose a particular estimate can also be a disadvantage.
Relative Sizing is incredibly common, and relies on the fact that humans are very good at comparing things, but not very good at precise and accurate estimates.
For example, imagine seeing a half full jar of sweets. It’s very hard to estimate how many there are. However, if you know that a full jar contains 380 sweets, then the estimation suddenly becomes very easy.
Relative size estimation depends on having a known quantity, and then proving an estimate based on that known quantity. Some examples are:
- Whole project level – Last year we did a full stack web application with 6 main pages in 4 months. This project looks about the same level of complexity, and is for a client in a similar sector. It will probably take the same sized team about the same amount of time.
- Sprint level – The past few Sprints we have been averaging about 80 story points of delivery. We will probably do about the same, so let’s plan about 80 points in the nest Sprint.
- Story or Epic level – Stories about adding new views to the MI data are around 8 points. This story is more complex than most, so I’ll estimate 13 points.
- Task level – We know that adding writing new exam questions for the training course takes an average of about 20 minutes per question. Writing a 40 question exam paper will probably take about 2 days of effort.
However, for most real-life estimates, there will be a variety of different answers. That’s why most estimation approaches introduce some form of abstract or nebulous unit, such as Story Points or T-Shirt sizes, and than a range of possible values. Constraining the possible answers (e.g. to Small, Medium, Large, or a fibonacci like sequence such as, 0, 1, 2, 3, 5, 8, 13, 20, 40, 100) focuses estimators reaching an answer, and makes comparisons easier. It also makes it more likely that estimators can reach a consensus.
For more information on agile estimation, including descriptions of various techniques, see the Agile Estimation chapter in Agile and Business Analysis.