If You Found Estimates Bring No Value – What Would You Do?
I think this is a simple question:
In your software development efforts, would you eliminate estimates* if you found they bring no value? Put another way, if it costs (time, money, effort, whatever) to do estimates, and you get no return for that expense AT ALL, would you still do those estimates?
Few Are Willing To Answer This Question Outright
I’ve asked this question to about 50 people (face-to-face, in conference sessions, in “Skype” conversations, and in other forums) and here are some of the typical things I hear in response (note that these “answers” don’t answer the question at all):
- I still like estimates, even if they bring no value, because they help me think about my work
- We NEED estimates to make decisions
- I just use them to determine velocity
- My boss still requires them, even if I think they are waste
- We need estimates to be able to bid jobs – our customers require them
- It depends on the context
I rarely hear the answer I originally thought I would hear:
- Dang right I’d eliminate them! Anything that is a cost that brings no value is WASTE and I would rather spend my money some better way. I won’t keep any process, practice, procedure, policy, or plan with no pay-off. (And quit spitting, will ya?)
I hear a more reasonable answer when I ask the question like this:
Same question (more or less) without the word “estimates”: If waste is anything that has a cost but has no value, would you eliminate waste from your process were you to find it?
Most of the time the answer I hear to this is “You bet I would”.
It seems to me, for the time being anyway, that there is some sort of problem people have when I insert “estimates” into the conversation.
The question is hypothetical
Why are few willing to actually answer the question, and instead “dodge it”? I don’t know. I might be asking it wrong.
I pose hypothetical questions to myself all the time. One of my favorite “thinking tools” is to take the opposite side of some belief I have. For example: I love pair programming. It feels right, helps me work faster and stay on track, accelerates my learning, gives me confidence in my code, things like that. So, I will challenge myself and ask: What if I’m wrong? What if pair programming is a wasteful practice? How could I prove that? What would I do if I did prove it?
Exploration of questions like these help me grow my ability to do continuous improvement. At least it feels that way to me.
I’m Dedicated To Making Things Better
I am always on the alert for waste. It comes in many forms, yet it is often hidden, or disguised as something of value. It’s fun, interesting, exciting even, to find and eliminate waste. And, it is just plain good business. A penny saved is ten cents earned. If you don’t understand how that works, I’ll explain it some other time.
I find it helpful to remember the old Einstein saying about insanity, which I paraphrase here: We keep doing this, it doesn’t seem to work, we need to do better next time, we try to do better, things never get better. Perhaps “getting better at this” is failing, and “this” is not the right thing to do at all.
Once I’ve opened my eyes to the possibilities, I usually find big improvements are going to start happening. The old thinking and old practices that have been blocking me from “better” are gone, and I can allow myself to imagine the possibilities, and to start innovating.
All I ask
So here is what I ask: Think of it like debate class.
The proposition: “Estimates are waste and we must eliminate estimates in software development”.
Take the affirmative position supporting the proposition, and prepare your arguments. Suggest ways you could prove that estimates are a waste. Propose how you could replace estimates in your process. Imagine you could convince your customer to hire your company without a bidding process – perhaps something more like choosing a doctor than buying a car. Stuff like that.
We won’t really debate – this is just an exercise. Are you willing to stretch your thinking a bit? It shouldn’t take long. And you can quit any time and watch TV instead.
Some other posts I’ve written on the topic of estimating:
- Estimation is Easy and Useful: Estimate a game of Chess
- Do Estimates Do What We Want Them To Do?
- No Estimate Programming Series – Intro Post
- No Estimate Approach For End-Of-Life Legacy Support
- Notes From A Conference Session On No Estimates in Software Development
- A Comment And Response from Estimate Chess Post
- Can We Code Without Estimates?
Cheers!
NOTES:
* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.
Disclaimer: There are many situations where estimates can be meaningful and useful. This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.
#NoEstimates Part 1: Doing Scrum without estimates | neilkillick.com:
[…] If you found estimates bring no value – what would you do? – Woody Zuill […]
30 January 2013, 10:29 pmSteve Bement:
Yes I would eliminate estimates, and have. I worked on a team recently that did not estimate any stories. We had gotten good at writing stories that were all roughly the same size. So there was no longer value in the estimating – we just knew we could take in about 6 stories each sprint. It was awesome!
22 February 2013, 3:02 pmWoody Z.:
Hello Steve – I am excited to hear about your experience. Breaking things down to a similar size is a meaningful approach. Making them small is my main approach. Small is pretty much the same size as any other “small”, so they end up being more or less the same size. Almost anything we can do to get work done and into production quickly is worth trying.
9 March 2013, 1:39 pmPeter Saddington:
Sounds like a potential argument for WIP limits 🙂
9 March 2013, 9:15 amWoody Z.:
Hey Peter – I go along with that. We have a certain amount of time, and can only do so much work per tick of the clock. It makes little sense to me to pretend that we can deliever based on what we think we can deliever: We can deliver what we deliver, and that’s about it.
9 March 2013, 1:32 pm#NoEstimates Part 1 – Doing Scrum Without Estimates | My Blog:
[…] If you found estimates bring no value – what would you do? – Woody Zuill […]
6 August 2013, 10:56 pmDave Nicolette:
Interesting that you rarely hear the answer you expected. It seems obvious to me that if an activity brings no value, then we don’t need the activity. Doesn’t really matter whether that activity happens to be “estimates” or anything else. Goes to show, maybe, how deeply ingrained the assumed “need” for estimates actually is in our line of work.
I can’t help noticing: The work we do may be described as “applied logic,” and yet the knee-jerk assumption that we always “need” estimates appears to be fundamentally illogical. Maybe that’s just me.
9 October 2013, 5:10 amDavid Lowe:
Fantastic! I’ve scheduled our next discussion group’s (http://www.meetup.com/London-Agile-Discussion-Group/events/154351872/) session to debate: “This house believes that estimates are waste and we must eliminate estimates in software development. I’ll tell you how it goes …
13 January 2014, 2:33 amWoody Z.:
Hey David – Thanks! And I’m looking forward to hearing what you find. Especially if anyone gets injured during the fight. Cheers!
17 January 2014, 3:45 pmDavid Lowe:
It was pretty lively – but no punches were thrown. I thought I might have given too much of an intro, but we still had a good discussion. The title maybe allowed too much wiggle room as you don’t say don’t estimate ANYTHING; value surely has to be estimated.
27 January 2014, 8:28 amWoody Z.:
Well… First, I use “NoEstimates” to mean a very specific thing and when I am leading discussions I am quick to clarify what that is.
I don’t agree that value must be estimated. I do feel we must have a good idea of what features/work might possibly bring value. It is much less important to me to know that “this is worth more than that” than it is to know that “this will probably have value, and that will probably have value, but this other thing too interesting to anyone”. Then, pick one of the “probably have value things”, do some discrete part of it that can be put into use, and see if it actually has value… and then repeat. IMO getting good at many rapid tiny deliveries coupled with paying attention to what is actually bringing value is a good place to be.
27 January 2014, 8:53 amBruce Taylor:
No estimates seems to me to be a great end goal for teams. Personally, I think estimation sessions serve a purpose far greater than just providing a number on a card for Proj Mgt purposes.
27 January 2014, 8:11 pmIn young teams (Team form age, not team personnel) Estimation is a valuable activity in aligning understanding of the work. Estimation is as much about “This story is too big to work on” to, “Why do you think this is a five and I think it is a one?”.
Once teams have been together for a longer period of time, estimation starts to lose its value, sure. However, like most agile practice, it has it’s place and is a really valuable tool in my opinion. Much like the debate around ‘pairing’ as alluded to earlier, estimation should always be up for debate in retro’s etc. Once it’s time has passed, a team should feel comfortable stopping the practice.
I think the biggest danger of estimation is not from within the team, but rather, from outside. If estimation/commitment is used as some form of bat to beat the team with if they don’t deliver. Estimation is a team tool, a great way for a team to practice continuous improvement, and should be recognised as such.
David Lowe:
Fair point. However, it’s very difficult not to rank/prioritise/assign order of value to a group of items – even if you’re trying not to.
15 February 2014, 12:01 pmWoody Z.:
Hey David – It sure can be difficult to not rank, etc. Which is why I pay attention to that. We often do things simply because it is hard to avoid them.
15 February 2014, 2:17 pm