hi my name is Daria welcome to scrum masters video series where I give you practical tips
on how to build awesome teams in today's video I wanted to talk about metrics I know metrics
that you can collect for your team but I just really want to go into too much of the details
of what kind of metrics you can collect rather talk about how should you use your metrics and
how should you decide on which kind of metrics to start collecting for your team when you start
as a scrum master and 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 valuable so being able to present
progress in a quantitative data is important the cabinet lies 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 how do you 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 we can
choose your metrics the same way you would pick and choose the approach you take when working with
a new team so before collecting metrics you need to think about what metrics would make most sense
in your particular team situation think about this guideline 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 it's not 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 a team
from improving but just bring this information up without any data can actually be harmful because
your team might lose trust in you and not listen to your concern because you have nothing to back
it up so use metrics and instead when you bring this concern to your team with specific data or
specific metrics that can show why the concern is there or where it is coming from it won't 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 you metric is based on factual data that you picked up from a tool or system or something that
actually is there and rather than just thinking it out without any data behind it then it is much
more believable and it also can be easily verified and measured by the team themselves you don't
really want to check it so remember that whatever magic you collect should be based on facts and on
the data you can pick up a new team can pick up from the same place remember that metric needs to
be linked back to improvement goals and your team should understand how improving this particular
metric will help them improve it a teeny or make help them become more agile sometimes we might say
that this metric needs to be improved by 80% what needs to become more stable be sure to explain
to your team how it is linked back to general improvement add up a team I also remember that by
measuring it once it's not gonna help you actually need to go back and track it regularly for example
every Sprint review so what kind of magic should use a measuring unfortunately this question did
not have a straight answer it all depends on what is your concern and what you're trying to improve
and 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 zero
defect but at least you have a clear goal and you can understand how this particular metric is going
back to the product quality and make sure that the team can understand how this swing is back
to customer satisfaction another example let's say your team is struggling to complete the work at
our sprint well maybe measuring the percentages of work that they are not completing our 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 do there were
25 percent every Sprint's that's okay as long as we don't have huge spikes all of the time because
this improves our predictability as it seems now this examples are very good to help you to improve
continuously and to actually track their progress on becoming more agile but beware of how you use
this matrix and who uses this metric and how those metrics are communicated because the most
important thing is that a lot of the agile metrics 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 assess and I know that sometimes management teams do want to do this matrix at
KPI and to set goals to see that the teams are progressing towards these goals but if you really
put a lot of pressure on these metrics becoming performance metrics that it will actually take
away the most important factor of agile matrix 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 defect and no one's
fixing them at this firm answer 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 another hand tell me what a time when a good magic was used for
bad reason and brought Mulcair's than improvement leave a comment in blog it's Grandmaster calm and
while you're there subscribe to the newsletter I'm sharing practical tips and videos every two weeks
as some useful guides or scrum masters I hope you learned something new today about a scrum master
role and agile in general looking forward to seeing you next time Cheers and strum on