Should I use developer estimations as a performance metric?

Question

Have to admit this, but I am trying not to be a pointy haired boss!

My developers tell me when they think stuff will be done and how long it takes. They then can do it when and where they like. As long as they are within project timescales +/- a percentage of time.

All is good, they get freedom and the sense of shipping on time most of the time.

However, when doing projects - it feels great to ship, I get all warm and fuzzy as they have shipped to the business and the business just gets on and does the job - hopefully a little faster and hopefully better. But this is very long cycle for us - typically around 9 months to a 1.5 years....

SO I am left as the manager wanting to get (shorten) the postive reward vibe to help in postive motivation....

So should I use estimations and performance on those estimations to get a short positive reward vibe going...

Answer 1

The only reliable estimates are the estimates of the people who are actually creating the application. I am talking about the whole team here, that should include your analysts, architects, developers, testers, UI designers, DBAs etc.

Saying that it is important to remember that the developers sometimes lack the experience and knowledge to do the estimates properly. For example the coders could give you an estimate without adding any time for bugfixing, or hoping that they will be able to learn a new ORM framework in a day.

It is therefore very important that the team have someone on board who has solid experience with estimations and a good knowledge of the software development process.

You also have to consider that it's almost always impossible to give a precise estimate at the start of the project work. My recommendation is to follow the Agile software development process and work in short (2-3 weeks) iterations. Only expect a rough guess from your team about the project end date before the iteration 1 (something like we'll ship during Winter 09). After the iteration 3 you could get something more (we'll try to get a January launch date). After the iteration 5 ask for the estimation to be refined etc.

Answer 2

Joel's written on this a couple times, too: obsolete version & new version

Answer 3

Be careful of the piece of folk wisdom that says that all metrics can, and will, be 'gamed'.

Think about: "if I wanted to be rewarded on this metric, without actually improving what it measures, what would I do?". Whatever that answer is, people will do it -- not necessarily even maliciously, but to game the system and get over a hurdle, especially if they feel that succeeding at it is beyond their control (hard to estimate stuff that's poorly specced, for example).

In this case, "what would I do to game this" would be "estimate 4 days, then say 8. If I run late I'm still fine; if I run early, I can play Quake for a few days before handing over to make my estimates accurate".

This may be subconscious but it will happen with any metric. Not saying it's a bad idea, but it's always good to think about metrics from the 'other side'.