The Three Most Important Metrics For Agile Teams

When I work with Agile scrum teams, I’m surprised at how often they do not rely on any performance measures (particularly when most Agile tools provide many metrics at no additional cost).

Among the various options, there are three metrics I encourage all Agile scrum teams to monitor:

1) Burndown

2) Velocity

3) Iteration (cumulative) flow

Let’s walk through each one.

1) Burn Down Chart

What is it? A burn down chart is a graphical representation of work left to do versus time. The outstanding work (measured in hours) is often on the vertical axis, with time along the horizontal. It is a run chart of outstanding work. It is useful for predicting when all of the work will be completed.

Why does it matter? One of the benefits of teams delivering via Agile is being able to consistently and routinely meet their commitments to their stakeholders, customers and other team members. A burndown enables a team to see whether they are on track (and likely to deliver on their commitments) during a sprint or iteration.

Key coaching points:

• Make sure data is accurate.  If the team is not updating their tasks and estimates daily, the burn down will not be useful.
• Review the burn down daily to inform progress.  If you don’t look it until after the sprint, its value is diminished.
• If total work remaining (vertical column measured daily) is more than 20% above the trend line, consider stopping work on the lowest priority story or stories in the sprint.  Reassign team members to the highest priority stories to ensure they are delivered.  Better to deliver 100% of some stories than 80% of all stories.
• If total work remaining is more than 20% below the trend line, ensure all stories committed to will be completed.  Then, celebrate meeting your commitments early and/or consider bringing a new story from the product backlog into the sprint (as long as the team can commit to completing it in the current sprint)

2) Velocity

What is it? Velocity is an extremely simple, powerful method for accurately measuring the rate at which teams consistently deliver business value. To calculate velocity, simply add up the estimates of the features (user stories, requirements, backlog items, etc.), typically measured in story points, successfully delivered in an iteration.

Why does it matter? One of the benefits of mature Agile teams is their ability to deliver a stable or consistent amount of work over time.  Velocity allows us to understand how much a team is delivering sprint to sprint. This allows them to reliably make commitments to themselves, product owners, stakeholders, and customers, both in the current sprint, as well as over a longer period of time (next release, next quarter, next year).

Key coaching points:

• Is velocity consistently accelerating?  If yes, great!  But note that at some point teams will plateau.  That’s okay and, in fact, expected.  If the team is dedicated and persistent, then we should see velocity stabilize sprint over sprint.
• How reliably does the team complete (and accept) their user stories each sprint?  We like to see teams consistently deliver on their commitments, so a “commit/accept” ratio of 100% is ideal.  For new Agile teams this is unrealistic, but is something they should achieve  over time.

3) Iteration Cumulative Flow

What is it? Iteration Cumulative Flow allows you to view the states of work in the iteration.  Typical states are “defined,” “in progress,” “completed,” and “accepted.”  This chart provides a visualization as to how work flows from one state to the next.  It is helpful in analyzing the trends in lead-time for delivery of working code.

Why does it matter? Understanding how work flows through a team can be very powerful.  It provides an indication of how well the work is defined, how quickly work is completed, how the team “swarms” and completes work rapidly, and whether we are minimizing risk of non-delivery by producing increments of value early and often throughout the sprint.

Key coaching points:

• Minimize work in progress (WIP).  Does the team “divide and conquer” with each team member working on a different user story?  Or do they “swarm and deliver?”  Successful teams will minimize the amount of work in progress throughout the sprint.  Teams that don’t often fall short of meeting their commitments, getting much of the work 80% complete, but little or none of it 100% complete.
• Complete work early (and often).  How soon after the start of the sprint does the first user story get completed?  Ideally every 2-3 days the team finishes yet another increment of work.  This builds momentum and minimizes the risk of non-delivery.
• Accept work early (and often).  If the team is completing work early and often and they have close working access to the product owner, then the product owner should be able to accept work throughout the course of the sprint.  Don’t wait until the last day and the team demo if you can review and accept work as the team goes – it’s good for the soul!

• Saikat Paul who is a PMP and Certified Scrum Master (CSM):  “If you want to get mathematical, I was reading about Little’s Law the other day. Lead Time = WIP (units) / ACR (units per time period).  ACR is basically Throughput. So mathematically, Lead Time (time to deliver value or complete a story) is inversely proportional to WIP given a stable throughput. Math doesn’t lie. Keep your WIP balanced with your throughput and your lead time will be reliable.”

What are your favorite Agile metrics?  Please add a comment and share.

[For more tips on Agile, see the blog post that outlines a five (5) ingredient recipe on how to suck at Agile!]