Estimating comes at a cost

Tom Breur

3 August 2014

“When will this be ready?” sounds like such an innocent question. And it’s certainly a reasonable question. After all, your colleagues have a right to know. Their work planning might depend on it, and/or they might be genuinely interested.

However, the answer to that question “when will this be ready”, if you need to know this with a modicum of accuracy, is a (little) task in and of itself. If you have ample comparable User Stories finished already, the empirical data are readily available. Without these reference Stories, you revert back to guesstimating…

Mike Cohn, in his seminal book on Agile Estimating and Planning (2005), makes a strong case for estimating based on empirical evidence. Which perforce is retrospective in nature. For the same reason, some Agile practitioners prefer to talk about analyzing rather than predicting the size of a Story.

Estimating should ideally be a team effort. Together you assess the appropriate reference Stories, and look at all the angles. But since we can only do one thing at a time, this eats into development time. Often of the best, and most experienced developers.

From my own experience, I have acquired the impression that excessive insistence on “estimates” almost always comes from low trust. Which in turn runs the risk of triggering an unhealthy and defensive dynamic. Pressure to come up with “good” (short…) estimates, and pushback form developers, pointing to all the bells and whistles that need to be included. Not good.

If you find yourself caught in this dynamic, I don’t envy you. It behooves the team to be fair, and transparently point to the costs involved with coming up with estimates. And to remind management, that these costs are expended at the expense of development. Couldn’t it be that the answer to: “tell me what to work on next?” adds so much more value?