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