What are some of the most useful metrics for a scrum master to measure and why?
When I’m asked this question, most people go straight to ‘velocity’ as a measure of a scrum team’s success, so let’s tackle that first and we will move onto some other useful measures after that.
Velocity
According to the Agile world, velocity is about speed. I want you to ignore that and think about velocity in terms of speed AND direction.
You can go as fast as you like in a circle and your velocity will remain zero. It matters that you combine speed with direction to get an accurate measure of progression and achievement.
In scrum, when we speak about a team’s velocity, we are measuring how much value a team is contributing to each sprint. We use ‘effort’ as a proxy for value because it is notoriously hard to estimate time in a complex environment.
It can be a useful measure if your organisation doesn’t weaponise this metric and use it to beat your team up with.
We definitely want to look at velocity as a useful metric to keep an eye on but it does come with a bit of a health warning.
Ask yourself how the organisation is going to use the number that your provide them with at the end of each sprint. If they don’t take into account the complexity of the work that is being done, a total number of points achieved in each sprint can be used against the team and erode morale.
So, use this metric with caution because it does have great potential to be abused or misunderstood.
Rate of change – Velocity
Sticking to the velocity theme, a useful metric is to measure the rate of change in your team’s sprint velocity.
Are the team improving over time or are they stagnating?
It could be that in this sprint, the work delivered was fairly straightforward and well within your team’s capability, whilst in the next sprint fewer points are delivered because the team were solving incredibly hard, complex problems and overcoming skills gaps to deliver the product.
This metric will allow you to explain changes in velocity to product owners and product stakeholders and it will also prove valuable when you evaluate the team’s performance over time.
You can distinctly measure how effectively the team are consistently achieving their sprint goals and targets, and how they have improved in their capacity to deliver over time.
Ideally, we want a stable velocity because that gives us the element of predictability in forecasting, but we don’t want the team to get caught in a rut and deliver the same amount of points week in and week out.
We want to see an improvement in the team’s capacity to deliver more effort within the same time frame as previous sprints. This demonstrates that the team are learning, acquiring new skills, and mastering complex problems more effectively than before.
Predictability
Part of scrum’s mission is to create a predictable delivery tool within a complex environment.
It isn’t easy to achieve. A team that consistently achieves 100% predictability is either very lucky, not very truthful, or gaming the system to ensure that the metric makes the team shine.
To measure this, we take the number of story points delivered in a sprint and divide that by the number of story points that we planned or anticipated we could deliver within that sprint and convert it into a percentage.
100% predictability happens when we achieve everything that we planned in the sprint and that’s great if we see this happen once or twice in a row, but we don’t want to see this too often.
Are the team challenging themselves? Are the team seeking to improve in each sprint or are they simply coasting along, well within their capabilities and capacity? Are they simply making a number up because somebody has asked them to report a measure of their effectiveness?
We want to see the team challenging themselves and falling short of the mark is often a great sign that the team are seeking to progress and improve. It’s great for morale when the team hit the mark because it demonstrates that the team really came together and delivered a solid win in that sprint.
Predictability should fluctuate around the 100 mark. Sometimes it will be under 100 and at other times, it will be over 100 as the team get through more work than they anticipated was possible.
Team Satisfaction
In the Agile world, you will often hear about the team’s ‘happiness’.
Happiness isn’t a reliable or solid metric for me personally because there are way too many variables that could impact someone’s happiness, especially over time.
Satisfaction is a far better measure of how the team are feeling and whether they are genuinely satisfied within their working environment, with one another, and with the organisation.
Happiness is also not necessary for a great team to perform but satisfaction is incredibly important.
The team need to know that they have a purpose and that they have the autonomy to solve the problems they encounter and create the solutions that move the needle on customer satisfaction.
You can measure this however you want, what we are looking for, however, is that this number that represents satisfaction is stable. If there’s a dip, is it explainable and understandable?
If you’re measuring on a scale of 5, it’s fine if the team are at 3.
They don’t need to be at 5 for the team to be high-performing and deeply engaged in their work.
If the number slowly increases over time, that is a great measure that the organisation are developing policies that lead to employee satisfaction and a measure of the team’s environment succeeding in creating both satisfaction as well as an opportunity to excel.
Measuring team satisfaction enables you as a scrum master to understand who your team are and where they are. It provides you with insights into what raises employee satisfaction and what leads to dissatisfaction within the team environment.
Once you’ve established a baseline, it’s easy to address issues that may be affecting satisfaction as soon as the number dips below the line, and it becomes easy to celebrate factors that drive team satisfaction above the baseline.
Interrogate the factors either way and learn from them.
Is the new thing that escalated satisfaction sustainable or is it simply a random event? Is the thing that increased dissatisfaction temporary or is it likely to breed discontent and fester unless it is addressed and removed immediately?
A satisfaction index is a useful measure because it tells us how the environment impacts our team and which elements to pursue to ensure that the team feel satisfied, productive, and creative.
All of which lead to the creation of better products and increased customer satisfaction.
If you like the idea of becoming a scrum master, visit our Certified Scrum Master course page.
If you are already a scrum master and want to upskill, visit our Advanced Certified Scrum Master course page.
If you have several years’ experience as a scrum master and want to both validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master course page.
If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy.
If you have identified coaching as a valuable skill to develop, visit our on-demand Introduction to Coaching course page.
For more information on John McFadyen, visit https://www.growingscrummasters.com