Agile Software Development

5 Principles for Using Agile Team Metrics Responsibly

If you know a lot and the people around and above you do not, then many devious opportunities for swindling will arise. Your agile team must however stick to its principles and resist gaming the metrics. In an article for AgileConnection, Joel Bancroft-Connors shares five basic principles for using agile metrics that will ensure the measures collected actually matter:

  1. Start collecting early and often.
  2. Be consistent.
  3. Stay focused.
  4. Measure the project and the teams separately.
  5. Measure responsibly.

Measures That Matter

You want to start measuring your team’s performance as soon as possible—from the first sprint, but also even using past data on performance if it exists. The earlier this data collection begins, the faster the data will paint a picture of how the teams function. Trends should start to appear in how one team performs compared to another.

This will only be true though if teams are consistent in what they choose to measure. Bancroft-Connors recommends measuring teams according to the metrics of “cycle time, escaped defect rate, planned-to-done ratio, and a team happiness metric.” Do not go overboard with how many metrics you track, because people will not be able to divide their attention meaningfully between all of them. Focus on a few to which the team will be able to meaningfully react.

Whatever you measure, make sure to keep project and teams measure separate:

In my old command-and-control project management days, I used to say that any project manager could ship a product on time, on budget, and in scope—once. Your project can be in awesome shape, only to be in trouble when half the team quits after the launch. Keep your project and people measurements separate from each other. Failure to do so runs the risk of corrupting all your data and wasting all your measurement efforts.

I recommend setting up three separate focuses: team-based metrics, project-tracking metrics (to monitor progress), and agile health metrics (to track the adoption itself).

Then you just have to remember to use the data collected responsibly. For instance, it is an awful idea to compare teams’ velocities. You also do not want metrics to be attached to punishments; metrics should show people the staircase up, not the door to the exit.

You can view the original article here:

Show More

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.