We earn commission when you buy through affiliate links.
This does not influence our reviews or recommendations.Learn more.
Agile metrics are measurements used to track the progress and success of an agile project team.
They might look nice on some dashboards, but they are usually useless for the team itself.
Unfortunately, it is then the team who doesnt understand why this particular decision exists.
But the output of the team is not improving at all.
Basic Metrics
There are many ways how to segregate the metrics.
Perhaps the most basic one is top-down and bottom-up.
We dont mind if you a team like them or not; this is what we want to track.
The most important property isbehavior-changing.
Then it must besimple.
A good metric iscomparableover time.
Take a results snapshot in a time, then do it again sometime later.
Place them side by side.
Lastly, better than pure numbers, wherever possible, make it a ratio or percentage.
10 new open defects during the sprint will not tell much.
It depends if you normally have one or 100.
Here are some examples of metrics I believe meet all those definition criteria.
They have specifically Agile teams in mind.
There are three main categories: Performance, quality, and morale.
It does not mean we shall not be flexible in story exchange during the sprint.
But it should always be a negotiation leading to an exchange, not an addition.
The teams capacity will not grow just because someone added new stories inside the sprint.
This builds up the reliability and predictability of the team.
Watch the history of sprint capacity vs. delivered story points (SP) content over the sprints.
Verify the sprint capacity vs. completed SP from sprint to sprint.
They can even generate that for you automatically after each sprint planning.
This is one of the metrics probably most of thescrumteams have somewhere hidden on the dashboard.
I agree that this might even look like a useless thing to have.
The team rarely takes it into consideration.
Agile management tools likeAsanacan generate a burndown chart for you automatically for each sprint.
This tracks the percentage of Sprint Goals that you completed during each sprint.
You document the Sprint Goals separately, e.g., on theConfluence page/Jira Software, for each sprint.
Status shall be assigned whether they were met or not within the sprint.
We shall aim for 100% Sprint Goals completion each sprint.
If that is not the case, find out what the team is preventing.
Code Quality Metrics
This shall track how good the code is over time.
It helps to maintain healthy development processes and decreases the time spent on resolving issues.
Or the developers idle time resulting from waiting on the code execution during dev and test activities.
Create automated unit tests by developers for each change they do.
Evaluate unnecessary complications the code is obtaining over time and actively fix it by technical debt stories.
Or prevent them from happening if possible.
Define code standards and guidelines to educate developers to follow them.
double-check they stick to the coding rules so that minimize the unreasoning increase in code complexity.
Regularly updated the guidelines based on the experience of the team.
Peer reviews shall ensure code standards are applied to the newly created code.
Use tools like Azure Ado or SonarCloud dashboards and reports to discover code problems.
Track how many manual steps the team has to do to release the code into test or production environments.
it’s possible for you to track how many action items were actually completed in the next sprint.
Project management tools contain ready-to-use templates for sprint retrospective activities.
Here is an example frommonday.com:
Track pair programming.
Track Code reviews from peers initiatives.
The metric can be extracted from the monday.com/Asana/Jira Software board from the subtasks.
At least 50% of stories in the sprint shall be shared by team members.
If it is less, investigate the reasons and take actions where it makes sense.
For voluntary peer reviews, track the stories with dedicated subtasks.
In the beginning, 20% of code stories reviewed in this way is a good start.
Giving the team the opportunity to resolve their own debt stories will increase the teams satisfaction with their work.
Such stories have the biggest impact on the dev team itself.
For the stakeholders, they might be invisible.
And while doing that, check that you always go for behavior-changing metrics above all.
Next, check out unhealthy processes that can ruin your sprint.
