Agile Team Health

Document ID : KB000047680
Last Modified Date : 14/02/2018
Show Technical Document Details


How can you determine the agile health of your team and is it improving? If you understand the key values that Agile looks for then you can start to monitor and grow your team's health and maturity.


The focus of this is not at the business level (product and above) this is for teams to assess current Agile practices. ?Maturing Agile teams have certain behaviors we want:

  • Accepts 80% or more of work by the end of the sprint

  • Stable Velocity or improving velocity

  • Has less than 25% WIP at any given time in a sprint

  • Cycle/Lead time

    • Defects

    • Stories

  • Throughput should be stable or increasing as velocity does

  • Team Status/Availability

If we know that these are successful measurements of a healthy agile team, then we can use various apps to see if teams meet these or not and, if not, where not. ?Root cause of the failing behaviors aren?t known until conversation can be had to support or mitigate the findings these apps can present.


Accepting over 80% of work in an iteration is a good sign that the team is productive, the stories sized properly, and that the team isn?t subject to too many shifts in priority. ?We also want to see that the work is being accepted soon after it?s been completed. ?If all the work is being accepted in the last two days? that?s very risky also.

What can I use to see who how the team may be doing on their Accepted work as it related to this? ?The Velocity apps (standard and enhanced) are the perfect snapshot to tell you if the team is hitting the 80% or not.

A healthy velocity chart looks somewhat like the one from our help, where we can see the team has been increasing its velocity sprint after sprint. ?We can see where work was accepted after the iteration and where work wasn?t accepted at all.

Looking at this example we can see that the team may have tried to stretch to a new velocity in the last iteration and couldn?t do it. ?What other possible reasons for the above chart are there?

  • Scope increased over planned velocity

  • PO not available

  • Unable to complete scope of work due to uncovered dependencies

The reasons are near endless and you won?t know the real reason until the conversation occurs. ?This chart gives you the data you need to start the conversation.

Be suspicious of a Velocity Chart that?s all green all the time. ?Most likely the team isn?t accepting all the work by the end of iteration (if they are they can be doing more and should be) rather they may just be moving all the work not finished to the next iteration without splitting or copying the unfinished items.

Another view into how well the team is doing at accepting work is the Cumulative Flow Diagram. ?This shows us the progress of work over the course of the iteration by state; from this we can also see the WIP the team carried across the sprint, when work was accepted, if scope was added in, etc.

Here we can see that all work was accepted at the end of the sprint and that acceptance was happening throughout the sprint. ?We can also see in the yellow band the WIP the team carried through the iteration. ?Were there any spikes or falls in the data those would indicate where scope was brought in or removed.

So now, from this one chart we can see information as it pertains to Acceptance and WIP. ?If I saw the green starting later in the sprint then I know work is not being accepted in a timely fashion. ?If I see a wider band of yellow than the other colors, I know that the team is doing too much all at once. ?

We never expect to see a perfect CFD and it?s those imperfections that illuminate where improvements may be able to be made?

From the Velocity chart and the CFD we can get insight into the Acceptance Rates, Velocity, and WIP. ?

The Burndown chart is another multipurpose chart that gives visibility into the same areas as the others as well as giving insight to the progress of the team day-by-day.

Looking at the Burndown for a sprint in flight can tell me if work is being accepted early enough, if the team is progressing at a rate to Accept all the work, if scope is added in, or if no development was tracked that day.

A completed sprint?s Burndown tells other tales as well.

Looking at this one we can tell that work gets accepted late in the sprint, that the team is completing work easily, and that greater than 80% was accepted. However, it?s the work getting accepted late that should prompt a conversation as that puts too much risk at the end of the sprint.

We also want to look at the Cycle/Lead Time for the work items to get an understanding of how long it takes for stories or defects, on average, to pass through the development cycle.

This one app can show the average time it takes stories and defects to pass through all states to accepted. ?On average, for this team, stories are taking 35 days on average to move through the full cycle of development. ?

You can use the setting of the app version to see the to show how long it takes from any given schedule state to Accepted to better understand where the process could be improved.

Lastly we want to look at Throughput to see what the constant or trending volume of accepted stories/defects the team is producing.

We want to see the same type of behavior here as with Velocity; stable or increasing.

When you add all of these together on a custom, iteration filtered, page, then you gain immediate insight into how a team may be performing.