3 ms·
My metrics are the following: - being able estimate how long the work will take* - being able to deliver projects on-time - effectively communicating their sta
by hahamrfunnyguy 10y ago
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.
- struppi 10y agoI 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 http://devteams.at/a_spectrum_of_effort_estimates