I occasionally participate in some of the discussions on Scrum/Agile where questions are posed and answered by experts. I have noted that there is a pretty strong contingent that see estimating as ‘waste’ and advocate against estimating, there are various techniques proposed that involve not estimating. I will state upfront that I am not one of them, and although I do understand and agree with many of their reasons, I feel that in some situations they may be missing out on a number of subtle and not so subtle benefits that the process of estimation brings.

Do it my way.

My first counter argument is that I object to anyone saying ‘their method is right and yours is wrong’. In my experience every team, every organisation and every project, is different, suggesting a one size fits all is ludicrous. I believe a good Agile Coach will assess each situation and seek to find a suitable framework for that particular situation. Blindly proposing changing a situation to fit your preferred method is hubris – in my opinion.

I will refer to my experience of ‘estimation’ and how and why I feel it is not waste and does actually add both direct and indirect value to a software delivery framework.

How can you assess ROI – without knowing the I?

First and foremost, it is very simply often necessary. Some are fortunate to be in situations where direct ROI (Return on Investment) is not scrutinised. But I have nearly always worked in situations that are commercially driven or commercially motivated. A feature is prioritised based on its value to the customer (the R in ROI) but not in a bubble, if the cost of providing that benefit is high (The I), the priority changes, often the feature can be assessed as not viable. A Product Owner or a business cannot make a judgement on ROI without an estimate of both R and I, if the team isn’t providing that estimate then the Product Owner or BA is doing the estimating themselves on some level and an estimate of work taken outside the team is highly likely to be less accurate and therefore less useful than if provided by the team.

Whose waste? Are you eliminating waste or dumping it on someone else?

So if ROI is a factor and someone IS doing an estimate somewhere, then calling it waste and not doing it within the team is just pushing it out to somewhere else, you are not eliminating waste you are moving the work elsewhere and to somewhere where the results are less accurate or reliable. This is not ‘lean’ it is not eliminating waste, it is actually just pushing a problem upstream and adding risk.

How much waste?

Even if you still believe that the act of estimating is waste – just how much waste are we talking about? I find story refining vital, one of the biggest hindrances to flow of getting stories to delivery is not having them refined in advance, if a story is well prepared the team can pick up and go. So assuming you agree with refining stories then estimating a story is simply a couple of minutes tagged on to the end of a refinement exercise – we are talking minutes – the waste(if you still believe it is waste) is tiny and yet the commercial value of the estimate to those outside the team is high. If you push it back on the PO or BA their effort will be much greater, you may even be creating waste by refusing to estimate.

Subtle benefits.

But even ignoring the commercial need for estimating, there are other benefits too. As part of the refining process a story is discussed and assessed until the team feel they have a common understanding. But how can you be sure they have sufficient understanding, when does the conversation end? In Scrum at some point they are able to estimate the story this is a natural destination of the conversation. In this situation the very act of estimating is a tool for focussing a discussion and reaching a consensus, the readiness to estimate is a measure of the conversation concluding.

Is an estimate a Barometer of consensus?

But it can also be a barometer of a consensus of understanding. If when estimating there is a wide distribution of estimates or a single estimate that differs from the others this is immediately an indicator that common understanding has not been achieved and that the requirements may not have not been universally understood, I say May as we do not know the reason for the difference without further discussion, but without an estimate this discussion would not have occurred. A consensus and narrow distribution of estimates is an indication that there is a common understanding, the fact that there is a relative size estimate that can be used for other purposes is a bonus. In this example the value in measuring that you have a common understanding of requirements and agreement that a story is ‘ready’ is hugely valuable to promoting flow.

Is an estimate a conversation starter?

But there is more, an estimate is a conversation piece, it may throw up suggestions of quicker solutions or ways to combine stories or breakdown stories. Without an estimate there is no focus for these discussion, without an idea of scale or scope there is no incentive to find a smaller solution or a more efficient solution.

An estimate is a conversation not a number.

In essence what I am saying is that an estimate is not just the number, it is the result or the output following a conversation and whilst you may debate the value of the output, the value of the conversation is considerable and is so often underestimated.