We are programmed as people to visually estimate many things, for example the length of a timber beam or the distance to a goal. We can count a number of objects up to a limited quantity, after that we use an estimate or a guess, or the mix, namely a guesstimate. This is based on an assumption that we are never exact and the estimate is an approximation.
Estimating how long something takes or how much effort is even less an exact science. The classic example of unreliable estimates is building a new home. Almost invariably we are over budget and over schedule.
Interestingly, the more we do something, the better we are at estimating. For example a skilled carpenter can 'eyeball' something, that is make a visual estimate, and make a cut or plane a level in wood to fit pieces of timber together very accurately, something I envy as a strictly amateur carpenter. I have found ways to overcome my inability to visually determine the correct fit, which as an engineer rely upon methods that can be repeated. For example I created cutting templates when I built my unique dining table. Better would have been to fine-tune my visual acuity to estimate, but I did not have the opportunity to repeatedly practice. That is a clear difference between an amateur and a professional.
Quite simply, to get better at estimating something, we therefore have to practice estimating.
One of the advantages of following a method with many delivery cycles, each of a short cycle time, for delivering a product is the chance to practice the techniques repeatedly. This includes estimation of what work can be done within a cycle.
In Scrum or XP, the team makes an estimate and a short time later, e.g. days or weeks, they see if their estimate was right. They review and supply improvements to the estimates and to the way to do the work (see STARS for a description of the simple improvement cycle) so that both estimation and the delivery result are improved.
One of the frustrations many people have when using this approach is that the people not involved doubt the efficiency of this approach to repeated estimation and delivery. They default to make anything unknown a risk, thereby further loading the people doing the work with unnecessary (waste) work to track risks.
It is important to understand the challenges that estimation for short cycles have. These include:
- Breaking the work into 'doable' pieces of work that can be completed with a short time
- Making sure the 'doable' pieces actually bring a valuable outcome
- Balancing the effort to break the work into 'doable' prices versus the effort to track them versus the effort involved in completing them (in other words if it takes an hour to break the work in 'doable' pieces, but the work can be done in two hours, does it make sense to break the work down?)
- Making sure that we do not apply the same level of accuracy to each estimate (see the Estimation bubble)
- Keeping an overview and how to reach the overarching goal
- Sensing impediments to estimating and doing the work versus finding out that the work actually required much more effort
All proper Agile methods use a time box for estimation to handle the third point above in the large, but it is also up to the people participating to manage their own time within the timebox.
Keeping a holistic view of how estimation interacts with performing the work so that an improvement feedback loop helps the people over time.