Browsing Jeff Patton’s blog, I read this entry about story estimation that illustrates some points that we’ve all instinctively felt but not had the words (or the courage, more on that in another entry) in which to frame those instincts. As developers, we are always forced to give estimates for the work that we’re going to complete in any given timeframe, and we’re almost always wrong. Occasionally, there is the perfect storm where:
- The customer and developer both have a clear idea of what is needed
- The problem is small and well understood
- We are conversant with the domain
- We know the implementation technology like the back of our hand
And in these cases our experience allows us to build meaningful estimates.
Far more often, however, we’re in the middle of a windless sea, and in the absence of landmarks we wet our thumbs and throw out a SWAG estimate so that the PM has something (anything!) to enter into his Gantt chart. And that’s where we run into trouble. Jeff’s advice (and a new favorite quote) is to
Treat estimates given at the outset of a project as a budget for some possible solutions, not as a bid for one specific solution.
When we’re writing stories, measuring velocity, and planning our iterations, we feel confident in calling ourselves agile…but those stories stop being launching pads for clarification and start being bullet points in a distributed requirements specification document. Why are we so afraid to be honest about what we can reasonably take on, and why is there always some point at which we stop embracing change? Is the mere idea of Agile Estimation an oxymoron?
I believe passionately in the theoretical underpinnings of Agile, but I’ve yet to see it play out in practice. I’m willing to offer the fallibility of mine and my team’s in bringing these theories to life, but I don’t see this as a problem easily solved with a bit of coaching. How deep and how wide can we manage customer expectations? How long do we overschedule iterations while saying “trust me” before it’s all gone Pete Tong and we’ve failed? How many under-implemented projects will be burned at the stake in the name of projected velocity being written in stone and married to hopeful estimates too early in the budgeting cycle. Where is the Herculean PM that can manage not only the client expectations but his own to see this through?
Or is Agile another idea that’s great on paper but cannot be both pure and effective when it hits the real world? I would love to be proven wrong.
 Shitty Wild-Ass Guess