Skip to main content

How to Track Agile Metrics


Why Track Them?​

Tracking Agile Metrics provides value in understanding the productivity through the different states of a software development lifecycle. This is especially important as it assesses the quality of the product and track team performance. Whether it is the Scrum Master, Engineering Lead, or Product Lead, reporting on team metrics will allow leadership to identify bottlenecks within the team and provide solutions to continue to increase development speed, expand collaboration, and foster the ability to better respond to client needs.

Typical Agile Metrics to Track​

SPRINT BURNDOWN:​

A sprint burndown report then tracks the completion of work throughout the sprint. The x-axis represents time, and the y-axis refers to the amount of work left to complete, measured in either story points or hours. The goal is to have all the forecasted work completed by the end of the sprint.

VELOCITY​

The average amount of work a scrum team completes during a sprint, measured in either story points or hours, and is very useful for forecasting. The product owner can use velocity to predict how quickly a team can work through the backlog, because the report tracks the forecasted and completed work over several iterations–the more iterations, the more accurate the forecast. New teams can expect to see an increase in velocity as the team optimizes relationships and the work process. Existing teams can track their velocity to ensure consistent performance over time, and can confirm that a particular process change made improvements or not. A decrease in average velocity is usually a sign that some part of the team's development process has become inefficient and should be brought up at the next retrospective.

CYCLE TIME​

The time from when a work item gets from one workflow to another, in other words: from "in progress" to "complete". They can track progression, task completion, and see how they compare. If a work item is taking longer to complete, the team should think about other factors that may be affecting the completion of a work item. Such factors can include: skills gap, understanding of the product, unrealistic/poor goals, burnout. The team will need to reassess the work item or initiatives so that the team is aligned on expectations.

Empower Specific Metrics​

UNPLANNED WORK OR SPRINT INJECTIONS​

Unplanned work is any work that is not part of the sprint backlog, the set of work items that the team commits to deliver in a sprint. Unplanned work can come from various sources, such as bugs, defects, emergencies, customer requests, stakeholder feedback, technical debt, or new ideas. Unplanned work can be classified into two types: urgent and non-urgent. Rule of Thumb: If an unplanned work item is needed to be added to an active sprint, the individual MUST communicate to the Scrum Master and Product Manager so that a "tradeoff" can happen or be prioritized. Failing to tradeoff or not communicating to the team will result in a skewed velocity.

QA SCORECARD - AUTOMATED TEST EXECUTION​

As a team, we would like to review the pass/fail rates of our automation tests. Automation Test Dashboard

BUG TRIAGE: HOTFIX AND PRIORITY 1&2 TICKETS​

Similar to tracking Sprint Injections, when a bug ticket is created, the team will need to review the priority level and how critical it is to be added into the sprint. The queries that have been created will allow us to understand how many hotfix tickets have been created due to an issue, the priority level of the ticket, and the time from active to completion.