16

I'm interested in learning what types of metrics can be used in the following areas:

  • Productivity
  • Quality
  • Responsiveness
  • Customer Satisfaction
  • Employee Satisfaction
  • Predictability

...and what makes agile metrics different from other standard cost/quality/etc. metrics?

Improve this question
4

2 Answers 2

Reset to default
12

Scott Downey has a lot of work on metrics and good information on his site. For productivity, the standard measure of velocity is a great one. Scott adds in another of work capacity that is very useful because you can then use the ratio of work capacity to velocity for more comparisons. One important thing to make sure you do here though is to ensure you set a "keystone" card so that your scale is anchored (a two is a two now and will still be a two in a year). If you don't set a keystone card that you always reference your scale can tend to drift.

The other items are much more difficult to measure. If you are calculating any sort of "value" measure on user stories, than tracking the amount of value delivered per sprint similar to velocity would be a good metric to ensure not only are you developing faster but you are developing the correct things.

Improve this answer
6
  • Not a problem. We hired Scott as an Agile Coach and are using his RoboScrum spreadsheet. It is pretty nice. Do you mind up-voting the answer if you found it helpful?
    – Matt Block
    Commented Jun 3, 2011 at 20:13
  • I would love to, but I don't have a reputation of 15 since I just started using stackexchange. I'll come back to it... Thanks for the input.
    – Jason M
    Commented Jun 3, 2011 at 21:08
  • 1
    For those of you still interested, I found a great link to multiple sources of Scrum Metrics. This includes metrics for the development team, management team, and execs. agilehelpline.com/2011/03/agile-metrics.html
    – Jason M
    Commented Jun 17, 2011 at 5:48
  • Hey Jason, that's a good link, you can post it as an answer and get upvoted for it. It is ok to answer your own questions.
    – Huibert Gill
    Commented May 4, 2012 at 8:10
  • 2
    I would be very cautious using velocity as a measure of productivity. See this article on estimation is evil - pragprog.com/magazines/2013-02/estimation-is-evil While I don't necessarily agree with everything there, there are traps you can fall into to be aware of. In fact, if the team is being judged by management on their velocity you will lose reliability in estimates because they will pad to make themselves look good - it's just human nature. Also associated reddit comments are useful - reddit.com/r/programming/comments/1806nm/estimation_is_evil
    – Jody
    Commented Mar 11, 2013 at 23:09
0

Here are some of the Metrics we track Sprint to Sprint

  • Release Burndown ( Gives a good indication of work remaining and changes in scope and velocity)
  • Defect Trends ( Gives a good indication of incoming rate, outgoing rate and the backlog of defects remaining)
  • % of Test Automation ( How many test cases were run and what % were automated)
  • % of Code Coverage ( How may lines of code, classes etc were covered in the test cases)
    • Defect MTTR ( What is the mean time to resolve a defect from the time it was reported)
    • % of Escaped Defects - # of defects reported by customer for GA'd products to the total defects (Internal + Escaped Defects).

These metrics give us a holistic view of the scope, the agility and the quality of our deliverables.

Hope this helps

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.