How to Measure Team Agility

If you have led, coached, or participated in an organizational transformation to Agile, it will be just a matter of time before someone asks “How do we know if we are truly Agile?” or “How do we know if our Agile teams are healthy and doing well?” Good questions often coming from leadership.

I have recently been working on answering these questions for our company and I quickly realized there is a challenge to measuring how “agile” a team or an organization is. It’s probably similar to measuring how “in love” someone is. You just know it when its right. It’s great when you are in a positive relationship and painful when you are not.

Measuring how “agile” a team or an organization is can be a little like measuring how much in love you are.

So measuring Agility in absolutes seems close to impossible but I feel there are some symptoms and danger signs we can be looking for. These symptoms could provide enough data to begin coaching teams before they fall out of Agility.

What should we look for:
Is the team self-healing? A team will never be perfect but they should be learning, improving, and adapting.

Is the team composition effective? A team may grow to be too big, not have enough of the roles filled, or may have people spread across multiple teams.

Is the team working well together? A team should be gelling and forming natural bonds with each other.

To measure these symptoms, I began building a small dashboard updated after every sprint to decide if there is any coaching I should follow-up with the Scrum Master on the team.

The dashboard consists of:
Completed / Committed Stories. There will be a temptation to track team velocity but refrain from doing so as there is too much variability. To gauge a teams ability to plan effectively, we started tracking the percentage of stories they are completing vs. the number of stories they committed to in each sprint. In the spirit of self-healing, we have set up a scale to determine how well the team is able to correct themselves.

Below 75% or above 125% would be flagged as poorly planned.
During the past 4 sprints:
0 poorly planned sprints = Excellent
1 = Good
2 = Average
3 = Watch
4 = Bad

Team Composition. For our Agile teams, its important to have all of the Core Discovery roles filled. Anytime this number dips below 3, it is flagged.

Team Size. Over time, the inclination will be to add more people to a team as this is easier than starting a new team. Any team over 9 would be flagged as being too big.

Team Member Dedication. Another inclination leaders may have is to split people across multiple teams. As we all know, this is very frustrating for the team but more so for the person being split. While we can never get rid of this entirely, let’s track it to make sure it doesn’t get out of hand. Anything over 33% is flagged.

Family Fun. We would like our teams to be celebratory and have a sense of togetherness. At least every 2 months, we want the teams heading out of the office for food, drinks, and fun.

This is our first pass and I’m sure we will adjust as we go along. Again, these metrics should just be used to sniff out any symptoms possibly leading to bigger issues. As leaders, we ultimately want to staff teams appropriately and coach teams to be self-healing and self-accountable.

Agile Team Health Metrics and Dashboard

UPDATE: You can download a copy of this template here:

UPDATE 2: You can receive version 2 of this dashboard (seen below with more features and metrics than the first version) by becoming an Illustrated Agile subscriber. Existing subscribers can find a link and password in the latest email from Illustrated Agile.


Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

19 thoughts on “How to Measure Team Agility

  1. Useful post Len. Thanks. I like your approach of tracking % of stories completed instead of velocity – I can see how this can be more practical, especially when working with teams relatively new to agile.

    Can I get a copy of your ‘agile health dashboard’ template please as it looks like it might be very useful too?


  2. This is great – I thought to write you an e-mail and ask you to get the excel – but you where faster. Even if I have not used it yet ist already feels like a great tool to measure agilty. Maybe (surely) it needs to be adopted but it’s a great base to move on… thanks a lot!

  3. When working with outsourced teams the agility is an interesting aspect of differentiation. If a customer needs to find a strong agile team, how can they tell? We are currently exploring some ways to do this based on the behaviour and practices among outsourcing suppliers and our approach is similar but maybe more into details. What do you think of this approach?

  4. Good post Len…..Thank you. I agree with you wholeheartedly, I tend not to track or get fixated on velocity but to focus on stories committed to and stories delivered in teh sprint….lots of lessons can be picked up just from observing this particular aspect. The business does not care about velocity (points), it cares about user stories that deliver value. They invest in software and not velocity or points per story.

    On a related issue, I notice that in a number of organisations I have worked with, many of the Scrum Teams experience Scrum pain. The pain is usually caused by factors external to the teams – impediments-blockers – e.g. raising service request tickets to support desk requesting for a fix or to install an app and the process to resolve might take 3 -4 weeks and you may have a 10 day Sprint so the team will carry over stories and or structures and processes that work against a teams ability to Sprint…..Soft Development Department Vs Service Delivery/Operations etc.

    I have also been looking at how we measure Organisational Agility to support the Teams Agility. I find many organisations adopt Scrum and think they’ve magically become agile without doing some deeper and wider thinking on organisational design, product development and continuous delivery.

    So a few questions I throw at some of my clients…..How do we measure value and progress or even success? How much have we invested in Agility? What is our return on the investment? How do we maintain a competitive advantage through Kaizen (Continuous Improvement)? How do we know where to focus our efforts to improve on our practices?

    Team Agility can be enhanced or supported and or enabled if we take a more joined up view of the corporate organisation and its software development/delivery department.

  5. I really enjoyed this post. Until now I have always believed I delivered my projects following a true PRINCE methodology but reading this I realised that I’m more agile than I thought. Now all that remains is to educate myself it the agile techniques that will benefit my team and my projects.

  6. Useful and very interesting post Len.

    I have used similar approach to measure the agility or the degree of agility. The underpinnings of the model which I have used are agile practices and their importance in achieving agile values.

    For every project/program, I have identified agile practices and created simple four levels (Level 0 – Not Agile Level 1 – Basic, Level 2 – Good, and Level 3 – Excellent)

    For every agile practice, I have defined 4 levels as mentioned above.
    For every level, I have defined appropriate questions to get the response in Yes/No/Not Applicable. Based on the response, I am deciding, how the team is agile right now at particular agile practice(s).

    I work with team, management to move team (s) to next level of all their project specific agile practices. This framework is simple, lightweight, can be scale or shrink by adding appropriate agile practices to the nature of project work. This framework calculates the agile degree or agile index at team, project, and program and organization level. It mainly focuses on agile practices and highlights the importance of each Agile practice in achieving Agility.

    Your post helps me to add few more questions in the framework. Thank you for the nice post….