Snowing Code

Personal notes on software development

Do we need estimates?

(Publish date: 03/07/2014)

Do we need estimates? Are they helping us to deliver better software and products? Lean and the Toyota principles have a couple of tools that can help us to answer these questions. Trying to roughly calculate the effect that working with estimates have on our work flow and the value added work we produce, could help us know whether estimates actually work for or against us.

Recently, I've seen more and more people on the blogshpere expressing their despair with estimates. Even the #NoEstimates hash tag also seems quite alive and kicking. At my workplace (just like in any other company), this issue has been the subject of an ongoing, never ending war where we gain ground in baby steps- two small steps forward, one big step backwards. Since it's been an issue very close to me for some time now, I thought it's about time I'd let some steam off.

As most of the developers that I know, I too feel strongly about estimates and am dreaming of the day we will get rid of them altogether. Developers should be responsible enough to deliver features as soon as possible, deliver the best possible quality and the most maintainable and clean code. If not, there's a good chance you don't have the right team around you.

Saying that, I don't wish to let my sentiments guide me on this issue. Some of the core ideas that lean and the Toyota principles give us will come in very handy here to help us decide whether estimates are good for us and what can we do to better ourselves and our process.

Value added and Non-value added

In The Toyota Way, Jeffrey Liker is defining value added as "work that ends up actually shaping the final product" (Chapter 8), "what is the actual transformation process core to the service that the customer is paying for ?" (Chapter 21). This, in our case, would be the code that we write or remove to create new or fix existing features.

Non-value added, but required work is then defined as "what is required under today s conditions even though it does not add value from the customer's perspective?" (Chapter 21).
Eventually, Non-Value Added is "pure waste".

Liker then goes on to say that non-value added but required can only be separated from plain non-value added by looking at the process from the point of view of the immediate customer. By documenting the current state, calculating the process metrics and revisiting the objectives, teams could then go on to develop a 'lean future state'.

So let's focus on estimates as a part of our current process and state. When (if at all) should we get rid of them?

  • How much time do you spend on estimating?
  • How much time do you spend on making your estimates more accurate?
  • How much time do you spend on meetings trying to figure out what went wring with your most recent estimates and why they didn't turn out to be true?
  • What is the effect estimate have on your daily work flow and your capacity to produce value added work?
  • Do they add healthy stress or just bad stress?
  • Do you loose on quality when working against estimates? Does your code turn less maintainable as a direct reaction?
  • How do your managers define these estimates and how do they communicate it?
  • How do you, your managers and other colleagues react to unfulfilled "estimates"?

The last few points may not seem to directly raise any issues with time lost, however these points may affect you even more severely than anything else. In the worst case scenario, we get estimates that all of a sudden become commitments. The distance from there to a culture blame becomes not that far. This path can lead to the demise of the whole business, and it's very easy to fall into this trap without you knowing it.

Now, saying this I totally understand this is far from what agile and scrum meant when they were originally founded, however in many companies I've seen this situation recurring. If you are using estimates within your development team and do not see any value added loss, there is no reason you should consider stopping estimates.

If you ask yourself all these questions and you find out that you're actually losing more than gaining anything from having estimates (which is by all means not necessarily the case all the time), it's time to revisit the objectives- might be a good time to drop all together your estimates.

Small batches

Deliver the smallest possible batches of work / features, that way iterative work becomes truly feasible. Every delivery is a small chunk of work that builds on top of the last piece of work you've done. Eventually the "whole product", will be ready and delivered; every iteration will allow users to test the work and every delivery would be a small victory. We all know this.

That way you do not need estimates, every batch that is delivered is small enough, so that you do not need to estimate the amount of time it will take to finalise it. Schedule will simply happen by itself.

blog comments powered by Disqus