Let me pose a question to you.

Let’s imagine we have a developer who estimates that a task will take 10 days and delivers in 9 days. We also have another developer who estimates 4 days for the same task and delivers in 6 days.

If we assume that they deliver to the same level of quality and the task is exactly the same of course this makes this somewhat a contrived example), who is best? Which developer do you want on the project: developer A, who estimates 10 and delivers in 9; or developer B, who estimates 4 days and delivers in 6.

I’m going to say that I have a different answer depending on the type of project. If I am managing a waterfall project I am going to want Developer A – I want the confidence that we can deliver in the estimated time. However, if I am on an agile project I hope I can have developer B.

I’ll come back to why I say ‘hope’ a bit later. First of all let’s consider a few realities of estimation.

What would you think if a developer estimated 10 days and delivered in 1 day? I wouldn’t mind betting that the majority view would be that this developer was a poor estimator; not that he was a great developer who delivered good quality working software in 10% of the estimated time. (Throughout this entry I am always making the assumption that the developer delivers the right level of quality – a fundamental principle for Agile.)

A smart developer knows this. They often won’t say that they are finished in 1 day. Instead they will ‘improve’ the code until it is closer to the estimate so that they simply look like a good developer who delivers on or just ahead of their estimate.

What about developer B in the above example. You could say that this developer is 50% over estimate. I am sure that this won’t go down well with the powers that be. This doesn’t look like the profile of a ‘good’ developer. Again, smart developers know this, which is why estimates are often ‘adjusted’ by the developer to make sure that they aren’t going to exceed them – better safe than sorry.

To top all of this, an experienced project manager will know this happens and will ‘counter-adjust’ their view of developers’ estimates. All in all, you could say that estimates sometimes aren’t worth the paper that they are written on.

There is one final spanner in the works that is thrown in on an agile project. On an Agile project we expect change, we embrace change and we even encourage it (yes, we do!) to make sure we deliver the most value to the business, all in the shortest possible timeframe. In this ever-changing environment, how can we expect a developer to come up with an accurate estimate when we are potentially moving the goalposts on a daily basis?

Sounds like estimating on an agile project is an impossible task? In my opinion, that’s not the case. We can produce good estimates but we estimate to a different level of accuracy depending on where we are in the project.

Most importantly, we need honesty when it comes to estimating on an agile project. We know things are likely to change so it is totally impractical to play the blame game.

What do we want on an agile project? We want to deliver as much working software as quickly as possible in an order prioritised by the business – we want to deliver real value.

This is where I can come back to my original question and where I say I hope I can have developer B on the project. This developer clearly delivered working software in a shorter period, thus maximising the associated business value. We need to take away all the politics on estimating to ensure that we encourage developers to work at pace –we don’t want to fall into the trap of identifying as a ‘good’ developer someone who simply delivers
to their own (possibly over-cautious) estimate.

I am going to cover a lot more ground on estimating over the next few entries but I hope that this gives some food for thought until then.