I Promise To, Never Again, Estimate By...
* Screen Count
Leads to the idea that Google.com can be replicated in 2 days if you can knock out 1 screen per day. Not all cases are Google, but seriously, estimation by screen count is a horrible idea.
* Number of Objects/Classes
For one, it implies you know the design up front, which as we know, we almost never do. This is especially true since I tend to be writing estimates during and/or prior even to doing requirements, and therefore, speculating what classes and objects we will have and estimating them is the pinnacle of silliness. Don't do it.
* Number of Database Tables
Like the above, but even worse, unless the app is total CRUD, in which case, you should be using MOSS/Infopath of some other generator technology.
At the last Chicago alt.net user group meeting, Bobby Norton* of ThoughtWorks moderated a fantastic discussion after his presentation on Cruise. I am told we will soon have video of this conversation, but the essence was that we all have estimation FAIL on our resume, and we need to get better at it. My big question, which is what I alluded to in a previous post, is that I am curious about how people actually do agile estimation. The whole idea finally clicked for me that has been around for awhile - estimate by user stories (think use cases, only different), assign "story points" for use case complexity, and if a use story is above a certain "story point" threshold, break down the story into something more manageable.
This is different than screens based estimation because IMO it does a better job of capturing the complexity of a screen when you are talking in user understood language. One screen may happen to be the place where a user will experience a great variety of stories. It also gets away from enumerating the design prematurely - as it states things from the perspective of the user, without trying to assume what artifacts are going to be developed to meet that complexity.
The real benefit, though, is on the measurement side. The key metric is how accuratley a given estimator can pin story points to complexity. Once you are storing information and graphing it - so you have some history about how much time goes into, say, an "Aaron Erickson story point" or a "Your Name Here story point", you get better at being able to predict what you can accomplish in a given time frame.
Is it perfect? No. But remember the word we are using here - that word being estimation. By continuously improving your estimates by using evidence of accuracy in the past to guide your future estimates - you do your client a great service. You have evidence you can base your estimates from, which in turn, gives you the real "predictability" you are looking for.
Evidence based estimation is where, I believe based on, well, evidence (HA!) the world is going.
* Apologies, got my thoughtworkers confused last time