Some people think estimating is “crystal ball gazing” (@agilemanager, 2 Nov 2012) leading to “bad decisions” (@WoodyZuill, 2 Dec 2012). I’m not one of them.
I don’t always estimate. Nor do I necessarily estimate everything. But I find estimating helpful when considering investment proposals. This is true whether picking the next user story or commissioning an entire project.
Admittedly estimating is not an exact science so I think George Dinwiddie (@gdinwiddie, 27 Feb 2013) summed it up nicely when he tweeted that “estimates turn the unknown into the unsure, based on someone else’s expertise”.
I believe that even estimates with caveats help the business make better investment decisions.
My ‘Ideal’ world
Woody Zuill lives in my ideal world. His team don’t estimate because they don’t need to. This tweet summarises Woody’s approach to development (@WoodyZuill, 23 Feb 2013):
Lets explore, code, ship, amplify learning, steer, repeat. Gotta discover the path. No guarantees.
Woody’s approach is the epitome of Agile product development. The approach is particularly applicable to his situation. He has a small team of well understood capability in a situation of high trust.
Woody’s team pulls a small user story off the product backlog based on the priority set by the product owner. The product owner trusts the dev team to deliver the user story in a timely fashion. The business is happy pay the development team to deliver a series of these user stories even when some of those stories are completely exploratory.
I have, at times, been in a similar situation to Woody and not needed estimates. But there are other times, quite a lot of other times, when I have very much needed them.
Why I estimate
Although understanding is a nice side effect of estimating I disagree with Mike Cottmeyer who believes shared understanding is the real reason we estimate.
I estimate because I need to know how much the software development effort will cost. Conversely, if I know how much money I have (i.e. cost is fixed) then estimating lets me know how much stuff I’ll get for the money. Of course it is usually the customer that is driving these questions. They want to know what it will cost; what they will get.
In fact there are two points when the customer wants to know the cost. When:
- Prioritising work
- Commissioning work
Prioritisation is a fundamental of Lean-Agile. Teams take the top priority items and deliver them. The pro-estimation and no-estimation camps are agreed on this. Where they differ is whether estimation helps in this process.
The no-estimate guys dodge doing estimates by only taking on small items. Other teams do put an estimate on items in the product backlog – whether days, ideal days, story points, T-shirt sizes or whatever. Either way the business ends up with what they need, an idea of cost on which to base their prioritisation decisions.
No estimate – No sale
Reading the tweets and posts on Agile estimating I get the impression the “pro” and “no” camps live on different planets. This difference is particularly evident when talking about the commissioning of new work.
Ron Jeffries (@RonJeffries, 22 Feb 2013) condensed the commissioning issue down to a single question:
I have $N to spend for new product idea X. Can we get a profitable product X with only $N?
To answer this question some folk, myself included, advocate estimates. Estimate the work. Cost the work. Put a price on the work. Give the business the choice whether to invest or not. Mike Cohn, the guy who wrote the book on Agile Estimation (Cohn, 2006), thinks estimates are useful for exactly this kind of investment decision and uses an overheard customer conversation about estimates to illustrate this.
In contrast the no-estimation folk think that estimates don’t help. Not ever. And not for investments decisions. For example Woody Zuill tweeted “Estimates mislead and result in bad decisions” (@WoodyZuill, 2 Dec 2012). When addressing Ron Jeffries’s investment question Woody Zuill said: “I suggest we need something better than estimates. Estimates are faulty. Why do you trust them?” (@WoodyZuill, 25 Feb 2013).
That might be Woody’s experience but not mine. I trust the estimates I use because I can back them with data (which is also my counter to David Anderson’s accusation of “crystal ball gazing”).
Ignoring the fact some people can get trustworthy estimates, what isn’t clear is where we find the “something better than estimates” that Woody is proposing. So far the no-estimate guys don’t have an answer.
This leads some to believe the no-estimate camp is incapable of dealing with an investment situation:
- “its is /really/ hard for someone with a heavy bootstrap bias [like the no-estimate guys] to construct an investment style pitch” (Adam Goucher, @adamgoucher, 24 Feb 2013)
- ‘Cust: “About how much will this cost me?” You: “You shouldn’t ask that question.” Cust leaves. Is that it?’ (George Dinwiddie, @gdinwiddie, 25 Feb 2013).
So, for the moment at least, if you need to pitch to a customer then you’ll need to estimate.
Cottmeyer, M. (2011, 18 Sep). The Real Reason We Estimate. Leading Agile.
Cohn, M. (2012, 30 Nov). Overheard during Customer conversation about estimates. Mountain Goat Software.
Cohn, M. (2006). Agile Estimating and Planning. Prentice Hall.
Zuill, W. (2012, 10 Dec). No Estimate Programming Series – Intro Post. Life, Liberty, and the Pursuit of Agility.