Why does the Scrum Master need statistics and metrics? First, to check if his methods of working on the predictability of results and improving the effectiveness of the team are effective. But also to keep track of how their actions affect the Development Team. That is, how they shape the employee user experience (UX). So in this article, we introduce statistics and metrics the Scrum Master should track.
Statistics and metrics important to the scrum master – table of contents:
- Measuring the results of the Development Team’s work
- Monitoring employees user experience Developers
Measuring the results of the Development Team’s work
The most commonly used statistics and metrics the Scrum Master should track are those that describe the pace and flow of task execution. These are the Burnup Chart, the Burnup Chart, and the Cumulative Flow Chart. These measures both product development and team effectiveness. Each allows you to approach these issues from a different angle, so it is a good idea to show them together. They are handy tools to assess progress on different scales, during a Sprint as well as the entire product development process.
The burndown chart shows the Scrum Master and the Development Team how much work has been done and how much is left to do. The X-axis shows the time left to complete the work. The Y-axis shows the amount of work left to be done that was planned in the Sprint Backlog or Product Backlog.
This chart also helps to determine the Speed of the Development Team, which we will also devote a separate article to. Here we will only mention that it is an average amount of work done during one Sprint.
This simple tool enables the Scrum Master to not only see how efficiently the team is working. It also helps to answer questions:
- What part of the work has already been completed?
- How many tasks are left to complete?
- How long will it take to develop the Product?
When using the Burndown Chart, the Scrum Master needs to keep in mind that it is not the only tool to statistically assess the team’s progress. It works best for projects where the scope of work is fixed and known. It doesn’t perform well with creating very innovative solutions with a new Client. Then the amount of work to be done in the whole project – that is the content of the Product Backlog – can change significantly during the project, making it difficult to use the Burndown Chart.
The Burnup Chart is the reverse of the Burndown chart discussed above. Here too, the Y-axis shows the amount of work remaining to be done. The X-axis, on the other hand, shows the completion time expressed either in the number of Sprints or in dates.
However, the Scrum Master uses Burnup Chart for a slightly different purpose. This is because it not only aids you in measuring the progress of the product and the progress of the Team. This metric also assesses how the scope of work in a project changes over time. Therefore, it works well for projects with variable scope.
The Burnup Chart is also a planning tool that is becoming more effective over time. It provides answers to the question of how much work the Development Team is estimated to do in the next Sprint.
Cumulative Flow Diagram
The third type of diagram that is very fruitful in the Scrum Master’s work with the Development Team is the Cumulative Flow Diagram. It features the analysis of how stable is the pace and productivity of the Development Team. The layout of its axes is the same as the Burnup Chart, so it is often referred to as its more complex version.
However, the Cumulative Flow Diagram is not only to determine the number of tasks completed in a given time period. It also takes into account the number of tasks which are waiting in the queue for execution. Thanks to this, it enables to diagnose the so-called ” bottlenecks” – moments of the process which slow down the creation of a product.
This very diagnostic feature makes it one of the most useful metrics in the hands of the Scrum Master. This is because it allows to reorganize the work in a way to distribute the strength of the Development Team differently and avoid downtime.
Monitoring employees user experience Developers
Regular and meticulous maintenance and analysis of statistics is an essential part of an effective Scrum Master’s work. However, he/she has to keep in mind first the employee user experience of the developers, i.e., the way they perceive the work in the Scrum Team. However, it is not the quality of the metrics that decides, but the way in which the Scrum Master uses them.
If the statistics are kept in accordance with Scrum’s principles – they are transparent, public, and understandable to the Developers involved – they can be a way to motivate the team to work more efficiently or to reward them for great results. However, statistics can function as a tool to put pressure on the Development Team. Then their indications become a generator of accusations and resentments. They can contribute to deteriorating team morale and spoiling teamwork practices.
The second important factor of employee experience of Developers, which the Scrum Master working with statistical tools has to take care of, is the way of managing their time. This is because the Scrum Master needs to have enough time to take care of the Development Team. For this reason, in case of a large project, it is worth to consider including an additional person in the Scrum Team. He/she will act as a project manager and will take care of the metrics. Thanks to this, it will relieve the Scrum Master – and to some extent the Product Owner – from the tasks that distract him from working with the Development Team.
Statistics and metrics – summary
The Scrum Master should keep track of the basic statistics describing the work of the Development Team. Their skillful interpretation increases the chance of quickly spotting problems in the Team’s work and reacting to them. However, more important than keeping the charts is what the Scrum Master does with them. They should not treat the metrics as a tool to evaluate the Team, but rather treat them as a useful aid in motivating the Team and diagnosing their own way of doing things. This is because metrics will only be useful tools if they help to facilitate the Team and the Product improvement processes.
If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube.
- Glossary of basic terms, roles and notions
- What is Scrum?
- Scrum values
- How to implement Scrum in your company?
- Scrum Team - what is it and how does it work?
- Who is a Product Owner?
- The most common mistakes of Product Owner
- Who is the Scrum Master?
- Characteristics of a good Scrum Master
- The most common mistakes of Scrum Master
- What statistics and metrics should the Scrum Master track?
- Cooperation between Product Owner and Scrum Master
- Development Team in Scrum
- The most common mistakes of Developers
- Scrum artifacts
- Scaling Scrum
- Sprint Backlog
- What is the Product Backlog?
- What are User Stories?
- Creating the best User Story with INVEST
- The most common User Story mistakes
- User Story Acceptance Criteria
- Estimation and Story Points in Scrum
- Planning Poker
- Team Estimation Game
- Defining Increment
- Scrum events
- What is Sprint in Scrum?
- Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
- What is a Burndown Chart?
- How to create and interpret a burndown chart?
- Advantages and disadvantages of the burndown chart
- Kanban boards in Scrum and Scrumban
- Velocity in Scrum - Speed of the Development Team
- Daily Scrum
- Sprint Planning
- Sprint Review
- What is a Sprint Retrospective?
- Common mistakes during a Sprint Retrospective
- Product Backlog nurturing