Collecting some kind of metrics to show the results of your work is important, no doubt in that.
However, in the case of a Scrum Master, that may seem like a daunting task considering the type of work we do.
So how do you go about counting your “coaching points”? (I have just made up that term)
There are actually so many different metrics you can measure as a Scrum Master. You just need to know how to choose them and how to use them!
That is why in today’s video I will be sharing some tips on how to make sure your team is on the right track.
I didn’t really want to go into too much of the details of what kind of metrics you can collect. Instead, I wanted to talk about how you should use your metrics and how you can decide which kind of metrics to start collecting for your team.
When you start as a Scrum Master on a new team, your management will most likely want you to collect and start tracking different metrics to see the results of your work. And it is understandable.
Scrum Master role is kind of difficult to define and especially difficult to see the value of. So being able to present progress in what kind of metrics you start collecting and how you’re going to use them afterwards.
As a Scrum Master, your primary concern is to help your team improve. And collecting and tracking metrics can actually be very helpful in this.
But remember, there is no one-size-fits-all here, and you should pick and choose your metrics the same way you would pick and choose the approach you take when working with a new team.
Choosing the right Agile metrics
Before collecting metrics, you need to think about what metrics would make the most sense in your particular team situation. Think about these guidelines when choosing your metrics:
- It needs to bring awareness about the issue you want to fix.
- It has to be easily measured based on factual data.
- And it should have clear improvement goals relevant to your team.
Let’s talk about awareness.
As a Scrum Master, you act sometimes as an outside observer, and you might be able to spot different things that your team is not yet aware of, and maybe see different issues that prevent your team from improving.
But just bringing this information up without any data can actually be harmful because your team might lose trust in you and not listen to your concerns because you have nothing to back it up with.
So use metrics instead.
When you bring this concern to your team with specific data or a specific metric that can show why the concern is there or where it is coming from, it will be much easier to accept and start thinking about solutions rather than discussing whether it’s a real thing or not.
This is why metric has to be based on facts rather than a subjective opinion.
If your metric is based on factual data that you picked up from a tool or a system or something that actually is there, rather than just thinking it out without any data behind it, it is much more believable and it also can be easily verified and measured by the team themselves if they really want to check it.
Remember that whatever metric you collect should be based on facts and on the data that you can pick up and your team can pick up from the same place. Your metric needs to be linked back to your improvement goals, and your team should understand how improving this particular metric will help them improve as a team, or help them become more agile.
Sometimes we might say that this metric needs to be improved by 8%, or it needs to become more stable. Be sure to explain to your team how it is linked back to the general improvement plan of the team.
Also, remember that by measuring it once, it’s not going to help you actually need to go back and track it regularly, for example, every Sprint Review.
So what kind of metric should you be measuring? Unfortunately, this question does not have a straight answer. It all depends on what is your concern and what you’re trying to improve on the team. So you should really think about where do you want to focus your efforts as a scrum master and think what kind of metrics can help you do that.
Let’s look at some examples. For example, let’s say your concern is the product quality. In this case, maybe measuring the number of defects that arise after the sprint can be a good metric to measure. And in this case, your goal would be to maybe reduce the number of defects that are raised. Once again, you might not be able to get it to a zero defect, but at least you have a clear goal and you can understand how this particular metric is linked back to the product quality and make sure that the team can understand how this links back to customer satisfaction.
Another example, let’s say your team is struggling to complete the work every sprint. Well, maybe measuring the percentage of work that they are not completing every sprint can be good. And in this case, you don’t even have to say we need to reduce it, but maybe say, let’s make it more predictable. Let’s make sure that this metric is just stable.
If we do not deliver. 25 percent every sprint, that’s okay. As long as we don’t have huge spikes all of the time, because this improves our predictability as a team. Now, this examples are very good to help your team improve continuously and to actually track their progress on becoming more agile, but beware of how you use this metrics and who uses this metric and how those metrics are communicated.
Because the most important thing is that a lot of the agile metrics. Transcripts are there for the team and should generally be used internally by the team. The most important rule here is This metrics should never be used as performance assessment. And I know that sometimes management teams do want to use this metrics as KPIs and to set goals to see that the teams are progressing towards these goals.
But if you really put a lot of pressure on this metrics becoming performance metrics, then it will actually take away the most important factor of agile metrics. is transparency. It is very easy to game the system and your agile team will definitely do that if there’s someone breathing down their neck saying that they need to improve a certain metric by x percent in any number of days.
For example, if there is a manager coming to your team and says we need to decrease the number of defects on this team by end of quarter or we are not getting budget for the next release. Well, you know what the easiest thing to do is? Stop reporting defects. And suddenly, this metric not only just became useless, but also very dangerous for the product quality.
Because now, no one’s actually tracking the defects, and no one’s fixing them. As a Scrum Master, you should always keep metrics true to themselves, and make sure that they’re used for good reasons. Now let’s have a chat. Tell me about a time when you used a really good metric to help your team improve.
What did you measure? How did you track it? And what specific improvements did it help you bring? On the other hand, tell me about a time when a good metric was used for bad reasons and brought more chaos than improvement. Leave a comment in the blog at scrummaster. com. And while you’re there, subscribe to the newsletter.
As I say in the video, Scrum Masters should make sure that metrics in an agile team are used in the right way to help the team improve. That is why I am curious to know your stories, so comment below to share:
Tell how you used a particular metrics to help your team improve: what did you measure? How did you track it? How it helped your team?
Or share a story of how a good metric was used for a wrong reason that led to negative results.
I am looking foward to read your stories.
