I am a firm believer in the age old adage 'You can not improve what you can not measure' (unrelated - here is an interesting antithesis). I believe in the importance of having the right metrics, especially in IT projects aiming to achieve continuous improvements.
Off-late i have interacted with some agile teams to get their perception of metrics in agile teams..responses have been varied, starting with outright cynicism to a mature approach towards using just enough metrics to achieve project goals. However one aspect was common through out, there is lack of awareness on various metrics options available for agile teams.
I would encourage project teams to look at all principles behind agile manifesto, and see which are the top three principles the project team values the most and consistently achieves in each iteration. Brainstorm within the team to see if the team can objectively measure progress for each of the three most important principles. Whether team velocity and burn down charts sufficiently describe team progress in each of the practices or is there a need to think about other possible ways of describing project progress?
If you see the need of looking beyond velocity and burn down charts, here are some starting points:
1. Heuristics for agile measurement: Refer to this seminal article on Appropriate agile metrics by Deborah Hartmann and Robin Dymond
2. AgileEVM : Pretty useful if you are in an organization with strong inherent PMI practices. Though AgileEVM is pretty neat in showing consistent business value, I personally am unclear on it's implementation in projects where the scope of work changes over time. Please share your experience if you have applied AgileEVM successfully in projects where the overall project scope increased during the project lifecycle.
Some metrics towards technical excellence
3. Running Tested Features: Ron Jeffries explans RTF. More detailed description
4. Static Code analysis
5. Code Coverage
What metrics do you use for your projects?