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
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.
References
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.
Hi Steve,
Aren’t the ‘no-estimate’ teams actually doing estimation, since they base their theory on all work being ‘small enough’ not to need estimates, but to achieve this the team has to break the work into small chucks, so they have to have an estimate (whether stated or not) of the size of the work in order to know that it is small enough, or if they think it is ‘too big’ they split it. I see this as a form of estimating but the output isn’t a story point or man hours, it’s a list of features of size ‘n’.
For example if the backlog has 12 related features that form a larger chunk of functionality (an Epic?) all the same size, there may be 6 other features that form another chunk of functionality (Epic). In this case, if all the features are the same small size essentially you have an estimate of 12 and 6 (scale irrelevant) for the two Epics, even if the team haven’t assigned any estimates to anything explicitly.
Or am I missing something?
Chris
Chris
That is also the way I view it. One of the puzzling things about the no-estimate argument. And is the subject of a planned blog post.
Cheers
Steven
Thinking about this more, I’m definitely in the estimating camp.
Aside from the stakeholder/customer benefits I also find that having the team estimate a backlog can reveal some high risk items that need action. Just this week my team were estimating for a new project and unexpectedly I got very high estimates for one of the items (10x larger than most of the rest!!) This obviously led to a lot of discussion and resulted in us adding a spike story high up in the backlog to work out how we could split it up and better understand the work that would be required.
I also find the act if estimating helps weed out dependencies, often conversations like ‘I think it’s a 3 if story A us done first or a 5 otherwise’, which can also feed into the priority of the backlog/decision making process. This also applies for external dependencies that may need another team to complete something sooner rather than later.
If team members have wildly different views in what a story is, estimating tends to revel this with very different estimates (planning poker), so as a side benefit it helps to get the team on the same page early in the project.
Chris
Agreed that estimating can help with shared understanding and highlighting risk and dependencies. But, for me, this is a side effect rather than the reason to estimate. And there are other ways to get that shared understanding.
Hi, Steven,
I think that the no-estimate crowd DOES have an answer, but I think it’s an answer that doesn’t satisfy in many situations. Woody’s answer seems to be “let’s start building it and see.” In some cases, that’s fine. If you’ve got an internal development organization you’re paying anyway, and the choice is between one project or another, I think that starting to build the project that seems of highest value could be a viable path forward, and perhaps (with some elaboration) the best path forward.
Even then, it seems to me, it takes some form of estimation to decide if and when to cut your losses and invest in a different project. Forward looking decisions are always dependent on some sort of estimation.
There’s much to say on this topic. I’m struggling to deal with the immensity of it. I’ve written before (http://blog.gdinwiddie.com/2006/12/27/the-construction-analogy-estimation/) on ways in which the “pay me to discover if we can get what you want” answer may be unsatisfactory.
BTW, I’m neither in the estimate or no-estimate camp. I’m in the “don’t estimate if you can get away with it, but if you need an estimate to support a decision, be clear on what is that decision, estimate just enough to make that decision as cheaply as possible, and don’t forget that these are just estimates” camp.
George
Fair point on “no answer”. I was really trying to say it was an answer I found unlikely to satisfy a new paying customer.
I’m not sure the distinction is “internal development organisations”. It depends on how they are set up. I’ve run projects and programmes with internal staff and management made the same demands as external paying customers – how much will it cost or what will I get? After all money is still being spent. And if there are limited time or money then estimates are necessary.
I think it is permanent product development teams that are least likely to need to estimate. Paid anyway. No particular time constraint. Need lots of exploration to perfect the product. I wouldn’t bother estimating. I’d concentrate on perfecting the product.
Agreed on the implicit estimation of pulling in small high priority items. This is something the no estimate folk don’t seem to acknowledge.
I too am in the “don’t estimate if you can get away with it, but if you need an estimate to support a decision, be clear on what is that decision, estimate just enough to make that decision as cheaply as possible, and don’t forget that these are just estimates” camp. I call this the pro-estimate camp only because it is shorter and judging from comments in posts and tweets all of the folk I call pro-estimate would say the same. For the purposes of the post I didn’t think it would be helpful to categorise people into always, sometimes and never estimate as I didn’t notice anybody saying “always estimate”. But some people do say “never estimate” and others disagree.
Hi George,
I like your “estimate just enough” philosophy, it reminds me of maximising the work not done and yagni. Often I am asked for a rough estimate for a project so we can predict resource requirements or even if the project is viable or not, this is usually to determine if we’re talking 6 months, a year or multiple years for a project so only rough estimates are needed. In this case we usually estimate Epic size work, no order/priority and assume a large uncertainty (50% or more) but its enough for the decision that is being made.
If the project goes ahead then some Epics are split, smaller work is sized and the backlog is given an initial order as I need to produce a release plan with a rough idea of what can be achieved in the near future (3-6 months) so we can prioritise work better to maximise our value.
I also find that once a project is some way in the team are much better/it’s easier at estimating as there is usually much more knowledge about the project/product/domain in the team such that estimating becomes quite a low cost activity and gives useful information for grooming the backlog.
Chris