No Estimates

Forgive me if this is a little rough, I just wanted to bash out a few words in response to some conversations that were started on Twitter. I love Twitter for helping to start these discussions, but its a terrible place to actually conduct them.

I used to get irked by it. Of course you have to estimate, it obvious isn’t it? People need to know when things will get done. And we need to make plans. And its just obvious isn’t it. But as I read a bit more and talked to people I actually started to come around to the idea that perhaps we spend a bit too much time and effort on estimating for the return we get from it.

I was lucky enough to see Woody Zuill talk at Co-op Digital in Manchester on mob programming and (no) estimation in what I found to be a very inspiring talk. No great promises or guarantees, just some experiences, some ideas and some hope that maybe we can do things differently and the world wouldn’t collapse.

Software development is a broad church, and I think a common failure mode of the discussion around it is thinking that what works for some people, in some environments is right for everyone everywhere, or conversely, that if something doesn’t work for you then it must be wrong. So I think there are probably situations and cases where investing time and effort in estimating is a good idea. But, having sat through more than enough planning poker sessions myself, I am equally sure that in a lot of cases its largely a waste of time.

So what are the pros and cons of estimation. I’m going to start with what I see as the cons, which are pretty straightforward.

  1. Opportunity cost. The time you spend estimating is time you could spend doing something else, which could be more valuable. Planning poker sessions with the whole team can be expensive meetings, could the time have been better spent?
  2. Quantity over quality. I think elevating the importance of estimation can lead to a “contract negotiation” mindset. If the team is judged against whether they hit a deadline, then they will do what it takes to hit the deadline. And lets face it, the contract is for some work to be done in a given amount of time. If those two things are fixed then the only thing that can be flexed to hit the deadline is quality. Is that the trade-off we want to be encouraging?

OK, so what are the pros. Now clearly I have a horse in this race, and I must admit I struggle a bit to think of genuine benefits. Let me offer up some of the things I have heard people say in defence of estimation.

  1. Building trust. The idea being that when developing a relationship with a client, giving an estimate and then hitting it builds a level of trust. This makes sense but I do think its a little bit question begging. Is hitting a deadline the only way to build trust? What about just delivering incremental value? It can be a small change of emphasis but it feels like a better start to a relationship to say “we’ll show you what we can deliver in a week” vs “we commit to building you x in a week”, because what if x is not finished? Is the relationship done then? Even if something good might have been delivered that wasn’t quite x? There is another angle here, where estimates are important for winning work, then there is an inherent pressure to give a low estimate which could lead to a “race to the bottom” scenario. And #NoEstimates obviously does not mean that you can never offer any prediction on how long things will take. But that doesn’t have to mean 8 developers sat in a room for 3 hours arguing whether a given story is a 2 or a 3 pointer. How about; Here is work we have done in the past. This is how long it took. These are the ways in which this project is different. This is how we will tackle the risks. This is the experiment will run to prove our approach.
  2. Co-coordinating work. This is the classic project management viewpoint. That we need estimates so we can slot all sorts of different activities into some grand plan. There may be some situations where this is the case but I think they are probably rare. And besides which, we all know that estimates are usually wrong, so surely meshing together lots of plans which rely on the estimates being right is a crazy thing to do. I think some of this comes down to the myth of efficiency, and trying to get maximum use out of resources. If we stopped tilting at that windmill and instead just focused on getting a steady flow of work through the system and into the world where it can start delivering value, we would probably be better off
  3. Team discussions. There is an idea that attempting to estimate a piece of work drives out interesting discussions. I think this is true but again there seem some obvious alternatives. If we keep tickets or stories at a high level (and we can if we don’t need to estimate them) then when the team come to pick up a new piece of work then they will have to discuss it.

OK, so you can probably think of loads more pros to estimation, and perhaps you could describe them a bit more positively than me. But its worth asking the question. Are we really getting value from this? And remember, its not an all or nothing situation. #NoEstimates doesn’t mean you have to stand tight lipped when someone asks how long you think something might take. It’s just a reminder that perhaps we don’t have to turn estimating into an industry in itself.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.