Scrum Team Health KPI's

Context is everything.

What do you want to learn from the metrics?

There are plenty of things you can measure, but unless you can identify what the metrics are intended to show, and how they should be used, there's a risk that they'll cause more harm than good; and it's possible they'll be used in an implicit way, thereby harming transparency.

In your case, I think you need to be clear about what you consider "health", and also what the organization are trying to achieve with the Scrum implementation.

In your case, I think you need to be clear about what you consider "health", and also what the organization are trying to achieve with the Scrum implementation.

^^ Agree with Simon. 

I'd suggest challenging the team to come up with some things they'd be interested in tracking towards. What makes a high performing team in their eyes and how can they make it measurable? Some things that come to mind could be clear goals, support, quality, self management, etc. 

Thanks for the comments.

What I want to do is create a tool and/or set of metrics that all of our Scrum teams could apply in order to help them focus on their overall improvement. 

Agile allows us to focus on obtaining Customer Value and the need for fast feedback, but in the Scrum Guides defintion of Scrum, it identifies the responsibility of us making "clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.".

Although we are obtaining Customer Value while performing Scrum, the design creates a deeper rooted desire to treat continuous improvement as the most important goal. I believe that is why customer value isn't found in the Scrum Guide, and why learning and creating change is.

Below is a bit more context of what I'm thinking, but I'd rather get insight to what folks have used and have learned from already.

This is absolutely NOT intended to be used to compare one team to another, but instead be a tool for each them to use independently, in order to encourage improvement beyond just Sprint output (since the Sprint is just one of the five Events of Scrum).

For example, I'm thinking three series of metrics (product, team, and working environment).

Is there a metric that can support the identification of issues several product teams are facing?

It's become too easy for teams to make accommodations for the 'rules' they feel they have to follow and call processes, when it would be nice to expose the bigger systemic issues. Perhaps a similar trend exists with several teams, and if so there is an opportunity to align the challenges together and get the support they need? As each team improves itself, the key learnings become silo's.

Are there metrics that can be used to help a PO find opportunities to improve, in either Sprint Goal creation support, gauging useability of the Product Backlog, ability to efficiently be a Customer Proxy, etc? It's possible that a mature team can mask the need for PO improvement because of consumed dependencies are already comfortable?

Similar line of thought for the Scrum Master and Development Team.

Are there metrics to help identify improvement of the working environment?

Are there metrics that can be used to help a PO find opportunities to improve, in either Sprint Goal creation support, gauging useability of the Product Backlog

Putting on my Product Owner hat, if I were to take an initial shot at something like 'Sprint Goal' as a metric I may assign the following values and rate myself and the Scrum Team periodically. For this example the higher the points the better. 

1 - Scrum Team has a Sprint Goal

2 - Sprint Goal is visibly tied to Product Strategy / Vision

3 - Sprint Goal can be mapped to strategic direction of the company

4 - Scrum Team members can clearly articulate the customer / company benefit 

5 - Sprint Goal is SMART (specific, measurable, achievable, relevant, time bound) 

If we're able to hit all of these marks consistently then it could be time to move onto another metric or work to expand this one even further. 

Perhaps a similar trend exists with several teams, and if so there is an opportunity to align the challenges together and get the support they need?

How would the teams get the support they need? Which other parties have expressed a clear interest in the metrics you hope for, and would see them as actionable?

Great questions Ian.

I brought to the attention of Leadership that the current set of metrics they use only reflect the accuracy a team can build a Sprint Backlog during Sprint Planning, and as a result, it's become negatively viewed when it is modified during the Sprint. As you know, that metric is opposite of what a Dev team is encouraged to do as learning occurs, especially because Sprint Goals remain intact.

There are several similar metrics that exist which are counterproductive to Scrum and are used incorrectly as a tool for Leadership to gauge performance of the department. There is also a challenge within the team as individual performance goals are tied to these metrics, instead of being tied to Scrum team goals. There is end of sprint crunching because of the influence the poor performance metrics create, and by working harder/longer the team is being incorrectly rewarded as "being responsible".

In an effort to resolve Stress/Wellness issues, I am providing a solution to Leadership members as well as HR. I intend to capture what I believe are metrics that reflect correct Scrum implementation and can be used to create actions for them to take. Right now, they are willing to help in any way, but don't know what to do and weren't aware there was a problem. I was able to relay the message that this is what "being responsible" truly means.

I created this topic to help me learn from others so that I can avoid some trappings.

the current set of metrics they use only reflect the accuracy a team can build a Sprint Backlog during Sprint Planning, and as a result, it's become negatively viewed when it is modified during the Sprint

Sometimes these things are about perspective...it sounds like you're leadership is viewing it as 'they're missing things' if the Sprint Backlog changes during the Sprint. This could just as easily be viewed as 'they're learning things' that allow them to build the right increment for the customer. 

Without further inspection of what is causing the Sprint Backlog to change during the Sprint it may or may not be necessary to take action and improve. 

Pairing this metric with individual performance goals is a scary thing. I'm glad to hear your leadership and HR are open to other ideas that may be more appropriate... that's at least a huge first step.