Should we re-estimate?Posted: July 31, 2012
“Our estimates were wrong, should we re-estimate?” It seems like a fair question and it is certainly a common question among teams I consultant with and coach. However, this apparently uncomplicated questions hides a concept that is not nearly as clear as it should be, that is, what do we mean when we say an estimate is ‘wrong’.
On the surface, most people seem to mean that an estimate was wrong when completing it took longer than estimated. However, this presupposes a traditional form of estimating user stories based on elapsed time. And, as always, when we ask a person how long it will take to complete something, we are actually asking them two unrelated questions. First, what is the effort associated with completing that task? Second, how many delays will slow or interrupt working on the task? For example, how much context switching between this task and other tasks will the developer need to manage? How much downtime will they have waiting for feedback from others? And how many times they will be interrupted by completely unrelated items?
One of the secrets of effective estimation is the realization that people, particularly developers, are very good at answering the first question (what effort?) and terrible at answering the second questions (how many delays?). The reason is simple. The effort question asks about something knowable, at least in a relative sense, prior to starting work. The second question asks about something that is nearly completely unknowable prior to starting work.
So rather than worrying about whether our elapsed time estimates are wrong in this sense, we should ask whether our relative estimates are useful. What is a useful estimate? One that allows me to project the pace my team will complete a scope of work.
So, if we decide to re-estimate, it should only be because our estimates on the completed user stories are ineffective in projecting future progress. And any re-estimation needs to be holistic across the entire scope of work we are projecting across in order to maintain the relative scale.
Of course many teams ask is it even useful to project completion? Some teams find they do not get useful information from estimates at all, so simply stop doing them. But that is a blog post for another time.