I was reading this post by Phil Haack, and I felt myself react strongly. You see, for the longest time, whenever I had to estimate my work, I felt stupid and like a liar. I had no idea! It was all guesses to me. I tried to learn from people that did this better than me, and we talked about doing the estimation in a deep enough level. I read the book that Phil talks about in his post, and it didn’t help me. It’s a great book if you want to learn about the rule of diminishing returns in estimation, and the cone of uncertainty, and the normal distribution of actual implementation times. But it’s all an awfully complicated way of guessing.

What are the problems with the traditional way of estimating then?

The first that comes to mind is that you might have experience with the technical problem before you, but has the team worked together before? That is not only the developers, but has the project manager worked with the developers? Have the QA people worked with anyone else? Change the team and you are introducing unknowns into something that is already rather unknown.

Another problem is how hard it is for our brains to try to measure something absolutely. That’s why the image above is there. Look at the two knights above, and try to see which is the black one and which is the white one. If our brains where wired to see absolute shades, you would see right away that they are the same shade of gray. But our brains are much, much better at seeing differences than at seeing the absolute shade.

The last problem I’ll talk about is how changes to the team affect the development speed. If you’ve measured in absolute time, it’s hard to predict what doubling a team will do to the deadline. Will it cut the remaining time in half? Will it double the time? Even after you have doubled the team, and worked for some time, it’s still hard to predict when you will finish.

Agile estimation and planning differs from traditional methods, because we estimate complexity and not time. We don’t talk about how long time something is going to take, we talk about how complex it is.

In an agile project we use our historic performances to show how we will perform in the future. We don’t try to guess what the future will look like – we extrapolate it from the past.

I won’t reiterate how good agile estimating and planning is done. Others have already done it. I’ll just quickly recap what I think are the most important points.

• Keep it relative. It’s far easier than absolute, and also more exact.
• Count on features signed off by the business and not on technical tasks.
• To plan, look at how you have done in the past. You’ll probably do as much today as you did yesterday.

Agile estimation is easier, less painful, and in my experience, far more accurate than the traditional ways of estimating. I’m sure your spread sheet is great, but my burn down chart beats your Excel any day of the week.

If you want to become better at planning and estimating software development efforts, you are better of buying this book instead of Steven McConell’s.

Edit:

After publishing this, I realised I should have been clear that I’m not talking about the way of agile estimation and planning, just my way. I know you can be agile and still measure time and not complexity.

Posted by Andres on Monday, April 2nd, 2007 at 00:07.