Comment by hahamrfunnyguy | Hacker News Reader

Comment by hahamrfunnyguy | Hacker News Reader

My metrics are the following:

- being able estimate how long the work will take* - being able to deliver projects on-time - effectively communicating their status - quality of the work delivered - deliverables meet all stated business and architecture requirements - being able to function effectively on the team

*If an developer comes to me with an estimate that seems really low or high then that's a good time for a conversation to see the reasoning behind their estimate so it can be adjusted if needed. This is a metric that also scales with experience, I expect more from senior members of the team.

I generally agree with those measures, but 1 and 2 (estimate and deliver on time) are only really possible when:

  * Developers and teams have quite some slack (c.f. 20% time)
  * The code and architecture are of very high quality and well documented (i.e. no accidental complication)
  * There are very few external interruptions

and probably a few other factors. So, for example, in most legacy projects, it's practically impossible to give any meaningful estimates (i.e. estimates that are correct within reasonable ranges most of the time).

I wrote a few blog posts on estimating some time ago, those also touch the issues I mentioned here. For example: http://devteams.at/a_spectrum_of_effort_estimates

Reply on news.ycombinator.com