Demian L. Neidetcher| book review Agile Estimating and Planning

I saw Mike Cohn speak at the No Fluff Just Stuff conference. He's a great speaker. This should be required reading. Every team I've been on we have kinda 'winged it'. Mike lays out how to plan your project.

The paradox of estimating in my opinion is that it's difficult to estimate doing something new and anything worth doing is something new. Be it a new domain, a new customer, a new technology. Either way, if we've done it before then we'd just re-use our previous work.

The book covers estimating, the un-spoken gray area in software engineering today. Something we do regularly but rarely do well. Before reading this book, the sane among us say that estimating new work cannot be done, we roll our eyes and pull a number out of our heads. The audacious among us either analyzed the proposed system into irrelevance or lie through our teeth.

After this book we are left with a methodology for projecting progress. It's not a silver bullet as nothing ever is. There's no magic here, just some proven ways of tracking your progress (velocity) and projecting a completion date from that.

One point from the book I'd like to cover is unit-less estimating. Basically developers assign "story points" to "user stories". The points don't have any units at all. At first this sounds stupid as hell but here's some justification.

We are better at estimating things relatively as opposed to absolutely. We can see that the goal-post from 20 yards away is 4 times the height of the person standing next to it as opposed to saying arbitrarily that the goal post is X feet high.
Managers can't coerce us into giving lower estimates if there are no units to the estimate. They can't say, "a code slinger like you should be able to finish that in 4 hours, when I was a coder I could've done it in 2 hours." The units just don't matter.
Without units we can't let our ego take over. Developers are driven by, among other things, the respect of their peers. Without units developers are more likely to give straight forward estimates.

So you end up with arbitrary points associated with user stories. Sure, you can take a swag at when the project is gonna be done after that. But it gets really interesting when you finish your first iteration or so. After this you get a feel for your 'velocity'. Velocity is how many story points you finish in an iteration. Based on this you can begin to extrapolate when you will finish all of your story points. Now you can start giving meaningful feedback to management. After which they can decide to either drop features or push back the date.

Another important point from the book is looking at our definition of success in software development. The traditional definition is "completing the project in the specified time while meeting all of the original requirements." Mike goes on to say how this is a very dangerous view of software. At the beginning of the project you know as little as you ever will about what your users want and about the technology you will be dealing with. Rigidly defining success in those terms is horrible.

To sum it up I can say that I wrote lots of comments along the lines of "Yes!", "Aha!", "This Rocks!" in the margins. The world needs to be approaching software this way, it's that simple.

Agile Estimating and Planning (Robert C. Martin Series)