Scrum Team Metrics

Metrics that a Scrum team might consider for evaluation:

Actual Stories Completed vs. Committed Stories

This metric is used to measure the team's ability to know and understand their capabilities. The measure is taken by comparing the number of stories committed to in sprint planning and the number of stories identified in the sprint review as completed.

Technical Debt Management

This metric measures overall technical indebtedness of the team; known problems and issues being delivered at the end of the sprint. This is usually counted using bugs but could also be deliverables such as training material, user documentation, delivery media, and others. A low score may indicate special attention

Quality Delivered to Customer

Scrum attempts to have the outcome of every sprint that provides value to the customer i.e. a 'potentially releasable piece of the product. This is not necessarily a product that is released but a product that can be shown to the customers as a work in progress, to solicit the customer comments, opinions, and suggestions i.e. are we building the product the customer needs

Team Enthusiasm

There are many early warning signs that left unchecked, can lead to loss of 'enthusiasm'. It's up to the Scrum Master to recognize these symptoms and take appropriate action for each particular circumstance. If the Scrum Master is to keep the team productive and happy, measuring team enthusiasm can be very subjective and is best accomplished through observations.

Retrospective Process Improvement

The Retrospective Process Improvement metric measures the Scrum Team's ability to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next sprint.

Development Team's Understanding of Sprint Scope and Goal

Getting a clear idea on Sprint Scope and Goal metric is a subjective measure of how well the Customer, Product Owner, and team interact, understand, and focus on the sprint stories and goal. The sprint goal is broad and states the general intention of the sprint. The Scrum Master can use the scoring from "Actual Stories Completed vs. Committed Stories" and "Team

Velocity" as an indication of problem understands the stories and goal but is best determined through day-to-day contact and interaction with the Scrum Team.

Velocity

At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This is called velocity. Knowing velocity, the team can compute (or revise) an estimate of how long the project will take to complete, based on the estimates associated with remaining user stories and assuming that velocity over the remaining iterations will remain approximately the same. This is generally an accurate prediction, even though rarely a precise one.

As an example an agile team has started work on an iteration, planning to complete stories A and B, estimated at 5 points each, and story C, estimated at 3 points. At the end of the iteration, stories A and B are 100% complete, but C is only 80% complete. Agile teams generally acknowledge only two levels of completion, 0% done or 100% done.

Therefore, C is not counted toward velocity, and velocity as of that iteration is 10 points. Suppose the user stories remaining represent a total of 40 points; the team's forecast of the remaining effort for the project is then 4 iterations.

Metrics

To summarize this

• Good metrics affirm & reinforce agile principle

• Metrics are to measure outcome, not output

• Reporting should measure trends, not numbers

• Reports should provide fuel for meaningful conversations

• This data should be easy to collect Good data which is useful in gathering feedback on a more frequent basis

• Metrics should help define Excellence vs. Good enough production