Great article by David Anderson on project estimation – he is an agile guy so he tends to a be a little harsh on the traditional PLC estimating techniques – he talks about alternative methods to estimating based on Agile and FDD (Feature-Driven Development). My experience with project estimation is that most of the teams (myself included) don’t know how to do it really well and so we guess and then work ourselves to death because we always estimate optimistically (or get surprised by the extreme amount of process that gets in the way and slows us down). David speaks to the waste of effort from a customer perspective and a developer perspective in estimating effort because the end result is numbers that don’t mean a whole lot. On the other hand he says working the requirements and breaking them down into pieces that gives us a work detail as well as helps us in understanding more completely what the customer is asking for. So focus on analyzing the requirements and outputing information surrounding them rather than focusing on some number that your are supposed to give.
There is one thing from what David says that I don’t understand in relation to Agile (specifically XP) development efforts – don’t you buy definition when you go through planning games – identify how many tickets (or whatever you call them) are available and how much each use case (feature) defined by the users will cost in tickets? To me that seems to be the same form of estimating that David is denouncing.
I drill down into David’s previous post on agile estimating as well as the comments (which you should also read because it has some good stuff in it as well) – he expounds a little more that his estimating should be more lightweight and should deal in terms of number of bugs that someone can do in a specific window (what he calls velocity I think) with an accounting for variation in velocity. I suppose that maybe this speaks back to the goal of the FDD model and XP to break things down in pieces and interate quickly over the smaller pieces of work thus supporting a lighter weight estimating cycle. I am certainly not an expert on any of this – but I am learning more and more all the time which hopefully helps me long term – one of the challenges is changing the culture (or adjusting to use a less negative term!) to be more software oriented and leveraging the software development knowledge and best practices within the teams that I work on.