Posted on July 22, 2009


Yes, it’s about due time for another anti-Agile post. In this case, it’s a story about velocity. In theory, during the first few iterations the team isn’t that good at estimating. You don’t understand relative size of stories, so you don’t get a whole lot done. Over the iterations you learn more about your team’s capability and your estimating gets better and better… or does it? What does it mean for an estimate to get better?

I think a lot of people believe a good estimate is one with low variance between estimated effort and actual effort. That’s an ok definition, except I don’t think it is what your customers necessarily mean. When I ask, say a home repair person for an estimate, not only do I want the estimate to be accurate (don’t tell me it’ll be $500 and then charge me $2000 at the end), but I also want it to be cheap (don’t tell me $2000 when you could reasonably do it for $1000). A “good” estimate in my mind, isn’t one that’s just right, it’s also one which meets my needs (both in terms of requirements that will be delivered AND what it costs to deliver those requirements).

The former definition (low variance), creates a problem which I observed on a pseudo-agile project we’ve been working on. The team is trying to estimate stories and (like all early estimations) didn’t do so well. We didn’t deliver very much. However, what’s not clear (because we didn’t study it) is what our issue was. Were we really underestimating our work or were we just not working? In fact, most people on the team are part time allocated to the project (I know, bad no-no for Agile projects). Anyway, we got dinged for not delivering, and not knowing what was really wrong, we just decided the (more or less) halve our velocity for the next go-round (or I should say, double our estimates). Again, we’re really not sure what was wrong with our estimates, but adding more time to do work seemed like a reasonable thing to do.

So now, in order to get a story completed, we estimate twice as much work as we once did. And the stories aren’t getting done still. So maybe twice again is the right number? The thing is, that it is very easy for us to just say “oh, we estimated badly, let’s allow more time for this work.” And while at some point we’ll have so much effort allocated to a single story that Parkinson’s Law will take over and make sure our variance between estimates and actuals is low. The work will simply expand to fill the time allotted.

Velocity, just like any form of estimation, does nothing to account for sand-bagging. A happy customer is not one who just has low variance, but good anticipated value from the estimate (read: the estimate has to be cheap enough to be appealing). In this case, like with waterfall projects, the fact that we got called out for missing estimates created an undesirable behavior where we compensated (or I should say over-compensated) in a less than ideal way. Rather than eliciting a work-smarter reaction, it created a make more time to work the same way reaction.

You can’t just change the way you estimate and expect it to solve human nature. Calling it velocity doesn’t eliminate the issue at hand; only changing the way an estimate miss is viewed does. It has to become an opportunity to learn how to work smarter, not an opportunity to ding someone for not delivering.

Posted in: Anti-Agile