What metrics should you track?

Today on the Agile Project Management forum a question relating to metrics was asked. It was a rather lengthy question, but to paraphrase, he wanted to know what metrics typical organizations use to track projects and should they be tracking metrics such as: Average cycle time committed to UAT (Days), Average cycle time committed to done/Live (Days), Velocity per person etc.

My opinion on this is that the more one spends time tracking metrics, the less time there is for development. I think that tracking team velocity is all that a team really needs.  Tracking individual velocity is counter productive and generally hurts morale. All these other metrics won't help the team move any faster. I would rather focus the team on increasing the engineering discipline on the project like unit test code coverage (you can track that metric if you want - somewhat more meaningful), automated functional testing, pair programming etc. Don't over think this. You'll just end up spinning your wheels.

My 2 cents,

Jack

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[Derek Mahlitz]

Thank you Jack. I get so many comments and digging into metrics by corporate folks that its a real waste of my time.

[Wayne Allen]

I think it depends why you are tracking the metric. In my "No More Iterations" post I mention that we were looking for a single departmental metric (throughput) to express the fundamentals of what we were producing like the sales and support departments have. It was (and is) a communications device. Additionally it takes less time to track throughput than velocity (which we used to do).

[Konia]

I get these information is very useful. I like these information.

[Konia]

I get these information is very useful. I like these information.

[Gil Anderson]

Collecting and disseminating metrics will reduce the probability that the team or the scrum master will be interrupted from their work by requests for status reports. I remember learning in my Lean class that some muda (waste) is unavoidable. Status requests from higher ups certainly fall into this category.

I like to pull the data from the CM system at the end of the day so that the developers are not affected. The granularity of 6 of 10 requirements developed, 6 of 10 requirements peer reviewed, 5 of 10 requirements coded, 4 of 10 requirements unit tested, 2 of 10 requirements functional tested, etc. is sufficient to satisfy most people. If the planned velocity over a two week period is one requirement per day, these metrics give the managers (and the scrum master) a warm or cold feeling regarding the probability of sprint success.

[Chris Davies]

Measuring cycle time is only valid if you are using a Lean approach in which you have no iterative timeboxes or sprints.
The principle I follow is this: "What do I need to know to ensure that progress and quality criteria are being met with the least amount of overhead for the team?"
As a project manager, I measure story point burndown, defects raised and resolved, and acceptance test cases passed. My technical team leader also checks that unit tests are being passed and one or two other code quality checks.
That's it.

[Debby Binns]

Jack
I like your 2 cents and totally agree! I particularly agree that tracking individual velocity is counter productive and in my opinion is extremely bad for morale. We all need ways to motivate teams to reach their objectives and anything that dents moral generally slows down effort to reach the end goal!