Get certified - Transform your world of work today


Key Metrics for Agile Teams

15 March 2016

Agile teams generally use velocity as their primary metric. Here are a few metrics that I feel are important to Agile teams for improving efficiency.

Value velocity

During the preparation of user stories, the product owner assigns points to stories in terms of their value (perhaps by consulting the stakeholders). If it is a technical refactoring story, the product owner should consult the team to get the value for such a story.

In general, the effort put forth in user stories is estimated by using story points. In a similar way, value is estimated by using value points. At the end of the iteration, the cumulative value points delivered (that have adhered to the Definition of Done) can be calculated, which will help us to know the value delivered per iteration.

Gauging velocity in value points delivered per iteration rather than in story points will help the Agile teams know the effective value delivered to the stakeholders.

Value velocity per iteration = ∑ value points done in the iteration

Value momentum

Value momentum is a metric that provides teams with insight into how they are delivering value over the team's original value velocity. The value velocity of the team can be derived in the same way that story points velocity is derived for the team.

Value momentum = Current iteration's value velocity / Team's value velocity

With this metric, teams can determine whether they are increasing the value delivery per iteration. Gauge this metric after a few initial iterations, because the team needs time to determine its rhythm.

Velocity factor

The velocity factor metric will help you determine how much of the work in the iteration was actually done or was delivered.

Velocity factor = Story points done / Story points worked per iteration

This metric indicates whether teams have completed the majority of the work they have worked on. If the velocity factor is continuously falling below 0.5 over several iterations, it means that teams are working on more stories than can be done, or that the team is facing impediments. The impediments may be external dependencies on other teams, defect creep, or some other factor. This metric will help coaches identify impediments that are not being explicitly conveyed by the teams.

If value points are taken into consideration using this metric, then it is termed thevalue velocity factor.

Value velocity factor = Value points done / Value points worked per iteration

Happiness index

Apart from the other metrics of the iteration, the team's happiness is one of the crucial aspects that should be checked regularly. This index shows whether the team is happy or stressed by the work environment.

This metric can be derived at the end of the iteration or during the retrospectives. You can ask team members to indicate "Yes" or "No" on a sticky note. Asking the teams to choose on a numerical scale will not convey how happy they are. It is difficult to understand why a team member is only 80 percent happy if the team member chose 4 on a scale of 5.

This metric should lead to a discussion about obstacles that are in the way of the team's happiness and how to overcome them. An organization or the Agile coach should aspire to achieve 100 percent of the team's happiness, because happiness is one factor that drives the team and any other metrics!

Impediments value index

Impediments are the real threat to a team's progress, and they should be addressed as soon as they are known.

Besides logging the impediment in the impediments index or roster, I recommend that you log a value against the impediment. For example, an impediment is causing a delay on the completion of two stories of 8 story points each, so the impediment value is logged as 16.

Impediments value Index = ∑ impediments value / ∑ story points of the iteration

Use this metric to determine to what extent the impediments are obstructing the team's progress. Check this metric at daily meetings and retrospectives. The coach should address and resolve the impediments at the earliest opportunity.

These five metrics, in addition to the more common ones, can help teams thrive.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 2.3 (4 ratings)


Tim Baffa, CSM, 3/17/2016 11:08:56 AM
Venkata, I unfortunately do not see either the value in your proposed metrics or agree with how they are derived in the first place.

Story value can already be identified through the functional points of a story. Taking additional time to discuss "value points" and come to a consensus around them seems a wasteful activity that requires additional, unnecessary maintenance to reflect an accurate "value" point. A much simpler approach is to have the Product Owner simply prioritize their stories top to bottom based on value. This way, the team is assured each sprint of accepting the stories most valuable to the organization.

I don't understand how the velocity metric, by itself, will "help coaches identify impediments that are not being explicitly conveyed by the teams". It is just a number. Carryover situations (incomplete stories) can be discussed by the team without this metric.

A team member's happiness cannot be truly expressed as "yes" or "no". The gray areas (ex: happiness as a 4 on a 1-5 scale) invites questions and discussions around team and sprint issues and concerns.

Regarding the Impediments Value Index, if the Scrum Master and the team are aware of the impediment, why is the metric necessary? And why does it need to be discussed at the team stand-up? If it is mentioned that the IVI is 16, then next question is - "What does that mean?", at which time the discussion will be about the stories being impeded. So, why not start the conversation with the stories, instead of at a generated metric that simply tells us that one or more stories are in trouble?
Hi Tim,

Value points are not given by the entire team but by the Product Owner. As you said, PO can prioritize the stories as per the value perceived. If this value perceived can be put on the story while writing the story or during prioritization, this can also be seen by the team and management. This will help the complete teams understand how they are also faring on value delivery. (Value points and story points do not convey the same. For a story of low value, efforts may be high. For example data migration stories)

Carryover situations can be discussed without velocity factor. But over the course of time we do not have any data to look for such situations. Velocity factor determines how many stories worked on are actually done. If the number is 0.5, which means that team might have worked on 6 user stories but only 3 are actually done. This means that team is taking either more stories than they are capable of or the stories might not have been accomplished because of any factor.

Happiness Index can be taken on a likert scale (1-5 scale for example) or a Yes/No. Depending on the context we need to use these. For a newly formed team, I would like to use likert scale and for an established team I may go with Yes/No as team constantly giving 4/5 and not mentioning any issues clearly will be avoided.

IVI refers to the percentage of impediments blocking the stories. This metric is conveying the extent to which the stories can be worked on among the chosen stories of the iteration. In the example quoted, impediments value is quoted as 16 and it is not IVI. so if impediments value is 16 and user stories points for the iteration are 24, then IVI is 0.66 which means impediments are blocking 2/3rds of the work. Conversations of the stories are encouraged infact during the standups. Just before daily standups we generally update our storypoints done. In the similar way this will also be updated before the meet and no additional efforts are required during the meeting.

These metrics will convey more information to the entire team and will bring more visibility to the teams work. These are advised to be used after the teams settle down as they make more sense then.

Thanks for your time.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up