Measuring Scrum team performance involves assessing various aspects to ensure the team is delivering value effectively, and consistently. Here are some key metrics commonly used to measure Scrum team performance. For each metric a brief explanation and a “Trend” that helps you understand how this metric will look like over a period of time.
Velocity: Velocity measures the amount of work completed by the team in each sprint. It helps in predicting how much work the team can handle in future sprints. It also helps the Product Owner to forecast how many more sprints to be required to complete the remaining work in the Product Backlog.
Trend: Over a period of time the velocity should be naturally increased for a stable Scrum team due to their understanding of the Product, Technology, Automation and other improvements. Do not try to force the team to increase velocity, it will give negative results. It should be naturally increased over a period of time.
Sprint Burndown Chart: This chart shows the remaining work in the sprint backlog over time (Sprint duration). It helps the team track progress and identify any deviations from the sprint goal.
Trend: The actual progress line should be closer to the planned progress line. If the actual progress line is too much deviated from the planned progress line, it indicates either the team is completing work early or not able to complete the planned work. So as a Scrum Master, keep track of each Sprint Burndown chart and if too frequent deviations are observed, then highlight it in the Retrospective to help the Developers for root cause identification.
Sprint Goal Success Rate: Measure the percentage of sprints in which the team successfully achieves its sprint goal. This metric ensures that the team is consistently delivering on its commitments.
Trend: There should not be too many frequent occurrences of missing the Sprint Goals. As a Scrum Master, if you see a trend or pattern of too frequent missing Sprint Goals, then bring it in the Retrospective and help the Developers to find the root cause and get them to find possible solutions to address the root cause.
Cycle Time: Cycle time measures the time it takes for a user story to move from the “in progress” stage to the “done” stage. It helps in identifying bottlenecks and improving efficiency.
Trend: For various sizes of user stories (Story point) measure the cycle time for a few Sprints and see whether the cycle time is increasing or decreasing in the future Sprints. If increasing then find the root cause for that, and help the Developers and Product Owner to fix the root cause.
Quality Metrics: Metrics such as defect density, escape defects, defect removal rate can help assess the quality of the deliverables produced by the team.
Trend: Defect density and escaped defects should be reduced over a period of time. Defect removal rate should be improved over a period of time. If this is not happening, then help the team to find the root causes and help them to find the possible ways to address those root causes.
Team Happiness and Engagement: Surveys or feedback mechanisms can be used to gauge team morale, collaboration, and overall satisfaction with the Scrum process.
Trend: The Team happiness and engagement should be improved or stable over a period of time. As a Scrum Master you can take this metric during every Sprint Retrospective and see the trend. If the trend is showing downward, that means the team is not happy. Help to identify by doing one-on-one meetings and address the reasons for their unhappiness.
Stakeholder Satisfaction: Regular feedback from stakeholders regarding the delivered product increments can provide valuable insights into the perceived value and quality of the team’s work. You can use NPS (Net Promoter Score) to capture the stakeholder satisfaction in every Sprint Review.
Trend: If the NPS is going in downward, that means the Stakeholders happiness is decreasing. When you see a pattern or trend of going downwards, then help the Product Owner and Developers to find the root causes and address them. May be talking to Stakeholders directly and finding the reasons for their dissatisfaction is also a helpful action as a Scrum Master.
Percentage of Planned vs. Unplanned Work: Monitoring the ratio of planned work (from the sprint backlog) to unplanned work (such as ad hoc items or urgent issues such as product defects) can help in identifying disruptions and improving sprint planning and predictability.
Trend: Usually the unplanned work % value should be stable or decreasing over a period of time. If you as a Scrum Master find it increasing over a period of time continuously then it is a symptom of instability of the planned work. So help the Product Owner and the Developers to find the root cause and address that.
Team Capacity Vs Work Capacity: Team capacity represents the total available hours for the Developers (after removing the Scrum events time, product backlog refinement time, breaks, and meetings time etc). Work capacity represents the total effort estimated for the planned user stories for the current Sprint.
Trend: Usually for each Sprint the Team Capacity and Work capacity should be close to each other. As a Scrum Master, if you find a trend of the work capacity being considerably more than the team capacity, that indicates that it may increase the pressure on the Developers and it eventually leads to poor quality, and also lead to overestimation for future items. So you may talk to the Product Owner to effectively prioritize the Product Backlog items and also talk to the Developers to come up with engineering practices such as automation, that help to increase the team capacity.
Focus Factor: Focus factor indicates the portion of Developers’ capacity that is devoted to Sprint Backlog items. It shows how much focus the Developers have on the planned Sprint work versus other activities that are unplanned. Read more about Velocity and Focus factor in the article here
Trend: The Focus factor should be improved naturally over a period of time. If it is decreasing, then help the Developers and Product Owner to find the root cause for that symptom and help them to address it.
% of Adopted work: The percentage of the work added to the Sprint backlog after the initial planning, indicating changes or additions to the Sprint scope.
Trend: The % of adopted work should be zero or very minimal for each Sprint. As a Scrum Master if you find the % of adopted work is increasing Sprint to Sprint, then you need to help the Product Owner and the Developers to find the root cause of this increased % of Adopted work and address that accordingly.
% of Unplanned work: Similar to adopted work, the % of unplanned work specifically focuses on unplanned work that emerges suddenly during the Sprint.
Trend: The % of unplanned work should be zero or very minimal for each Sprint. As a Scrum Master if you find the % of unplanned work is increasing Sprint to Sprint, then you need to help the Product Owner and the Developers to find the root cause of this increased % of unplanned work and address that accordingly.
Estimation accuracy: How close the actual effort to complete Sprint backlog items was to the estimated effort.
Trend: The difference between the actual and estimated should be close to each other. If the gap is considerably high consistently for few Sprints, then you have to help the Developers and the Product Owner to find the possible root causes for this issue and accordingly help them to fix it.
Forecast accuracy (Say – Do ratio): The accuracy of Developers’ Sprint forecast (amount of work) by comparing the amount of work committed during the Sprint Planning and what was actually completed by the end of the sprint.
Trend: The committed and completed amount of work should be close to each other. Usually this will be calculated using the Story points committed vs Story points completed at the end of the Sprint. If the difference is considerably high and it is continuously happening for few sprints, then as a Scrum Master you need to help the Developers to find the possible root causes and address that accordingly.
Win/Loss record of Sprints: Tracking the number of Sprints where the team completed all committed backlog items (wins) versus Sprints where they did not (losses).
Trend: Usually the “Wins” should be consistently high. It is okay to have occasional “Losses” but they should not be very frequent. If there is a trend you find for a continuous “Losses” then as a Scrum Master you have to help the Developers to find the root cause and address it.
Cross-functional skills: The Developers’ cross-functional skills should be improved over a period of time. You can use “Star Matrix” technique to find the Developer’s cross-functional skills at any point of time. Join our Advanced Certified Scrum Master (A-CSM) training to learn such techniques.
Trend: Compared to a past date (such as 3 months back) the Team’s cross-functional skills should be improved. If the Developers have the same skills as they had 3 to 4 months back, this indicates the Developers are not focusing on the skill improvement. So as a Scrum Master help the Developers understand the need for improving their skills from time to time and get them improved.
Important Points:
- Do not use metrics to compare teams
- Do not create individual metrics as Scrum focuses on team based work
- Do not use metrics without informing the teams as it leads to poor transparency
- Do share the metrics data with the teams time to time
- Take necessary improvement actions based on the understanding of the metrics
These metrics should be used judiciously and in conjunction with each other, as focusing solely on one metric may lead to suboptimal outcomes. Additionally, it’s essential to consider the specific context and goals of the team when selecting and interpreting these metrics.
Our CSM online Training will help you to understand many real-time Scrum implementation concepts, case studies that help you to be a successful Scrum Master.
