How to Measure Scrum Master Performance

The Scrum Master is accountable for the Scrum Team's effectiveness, so that is what to look at. Measuring the individual directly, through velocity, events attended or actions logged, produces numbers that move without anything improving. The useful measures are all indirect, and most of them are questions rather than metrics.

Key Highlights

• The Scrum Guide makes the Scrum Master accountable for the team's effectiveness. That accountability is the only sound basis for assessment.
• Velocity is the worst possible measure. It is relative, self reported, and inflates the moment it becomes a target.
• Most useful signals are about capability building: can the team now do things it could not do before.
• The strongest single question is what the team resolves without the Scrum Master.
• Any measure reported upward changes behaviour, which is why the honest ones work best inside the team.
• A Scrum Master in an unchanged organisation can be excellent and still show flat numbers.

What the Accountability Actually Says

Before choosing measures, it is worth being precise about what is being measured.

The Scrum Guide makes the Scrum Master accountable for establishing Scrum as defined in the Guide, and for the Scrum Team's effectiveness. That second phrase is the operative one. The accountability is not for output, delivery, velocity or process compliance. It is for how effective the team is.

That has an awkward consequence for anyone wanting a performance metric. Effectiveness is a property of the team, and the Scrum Master influences it without controlling it. A Scrum Master with a capable team in a supportive organisation will look better than an equally skilled one working with a new team inside a company that will not change, and neither difference is about them.

So the honest framing is that you are looking for evidence of contribution rather than a score. Everything below is built on that. The wider role is covered in our guide to Scrum Master roles and responsibilities.

If you are assessing your own grounding in the accountabilities, our free CSM practice test takes a few minutes.

Measures That Do Damage

Worth covering first, because most organisations reach for one of these.

Velocity. The most common and the most harmful. Story points are relative and estimated by the team, so any target attached to velocity is a target on a number the team controls. Velocity rises, delivery does not, and estimation stops being useful for planning. Our guide to story points covers why the imprecision is deliberate.

Events run on time. Measures attendance and punctuality. A Scrum Master can score perfectly while every event produces nothing.

Number of impediments removed. Rewards the exact behaviour the accountability warns against. The Scrum Guide says the Scrum Master causes the removal of impediments, so a high personal count usually means a team that has learned to escalate everything.

Retrospective actions raised. Counts suggestions rather than improvements. Actions completed would be a better measure, and even that is a team property rather than an individual one.

Team happiness scores. Easy to game unintentionally. A Scrum Master who avoids difficult conversations produces a comfortable team and a stagnant one.

The pattern across all five is that each measures activity that is visible and easy to count, while the accountability concerns something that is neither. Once any of them becomes a target, it stops describing what it used to describe.

Signals Worth Watching

Six indirect measures that hold up better, because they describe capability rather than activity.

What the team resolves without you. The strongest single signal. A team that clears most of its own impediments has been coached well. A team that escalates everything has been served rather than developed.

Whether Retrospective actions complete. Not how many are raised, how many finish. A team completing most of what it agrees is a team that believes improvement is real.

Whether difficult things get said. In the Retrospective, in refinement, in the Sprint Review. A team that raises uncomfortable problems has safety, and safety is largely built by how the Scrum Master responds when someone does.

Whether organisational impediments move. The outward facing half of the role. One genuine constraint raised and resolved per quarter is more valuable than fifty team level blockers cleared personally.

Whether the team can run without you. Take a week off. What happens to the events, the escalations and the boundaries tells you more than any dashboard.

Whether the Definition of Done has strengthened. A team that has raised its own quality bar over a year has internalised something. This is slow, visible, and difficult to fake.

None of these produces a number, and that is not a flaw. They produce evidence a reasonable person can weigh, which is what assessing judgement work requires.

Team Level Measures That Are Legitimate

Some team metrics are worth tracking, provided nobody attaches them to an individual.

The middle column is why these are worth watching. The right column is why they should stay with the team.

The distinction that matters: these are diagnostics for the team's own use, not performance indicators for a manager. The moment one is reported upward with a name attached, its behaviour changes. Our guide to agile maturity levels covers the same dynamic at the level of a team's overall development.

The Measurement Problem in One Sentence

Anything you can count about a Scrum Master is either not the job or is a property of the team.

That is uncomfortable and it is accurate. Facilitation, coaching, noticing what is unsaid, and holding a boundary with someone senior are the work, and none of them has a unit. The things with units, events held, tickets moved, impediments logged, are the administration around the work.

This is why organisations that install Scrum Master metrics tend to get worse Scrum Masters rather than better ones. The metric selects for the countable part, people optimise toward it, and the uncountable part is quietly deprioritised because nobody is asking about it.

The organisations that do this well ask different questions. Not what did you deliver, but what can this team do now that it could not do six months ago. That is answerable, evidenced and hard to game.

Why Counting Fails Here Specifically

Worth understanding rather than accepting, because the same reasoning applies to other judgement roles.

A measure works when it is causally connected to the thing you care about and difficult to influence except by improving that thing. Cycle time works reasonably for a delivery pipeline because shortening it genuinely requires the pipeline to improve.

Scrum Master measures fail both tests.

Weak causal connection. A team's effectiveness depends on its members, its product, its codebase, its Product Owner and its organisation. The Scrum Master influences a portion of that. Attributing the outcome to them is attributing a system's behaviour to one input.

Easy to influence without improving. Every countable Scrum Master metric can be moved directly. Events attended, impediments logged, actions raised, velocity. None requires the underlying capability to change.

There is a third problem specific to this role. Much of the job is preventive. A Scrum Master who notices a Product Owner drifting toward committing externally before planning, and quietly heads it off, has prevented a problem that will never appear in any measure. The best work in this role frequently leaves no trace, which is uncomfortable for anyone who needs a number and is simply true.

The response is not to give up on assessment. It is to assess the way you would assess any judgement work: evidence, examples, and the trajectory of the thing they are accountable for.

A Practical Review Structure

For anyone who genuinely has to assess a Scrum Master, this works better than a scorecard.

Ask the team, not the metrics. Three questions: what does the Scrum Master do that helps, what would you notice if they left, and what would you want them to do differently. The answers are specific and difficult to fabricate.

Ask for one organisational impediment they pursued. What it was, who they raised it with, what happened. This tests the half of the role most people skip.

Ask what they stopped doing. Good Scrum Masters hand work back to the team. Someone who has taken on more each quarter is building dependency.

Ask about a time they were wrong. Judgement work involves misjudging things. Someone who cannot name an instance has either not reflected or is not taking risks.

Look at the team's trajectory, with context. Improvement matters more than the absolute state, and a team that started badly in a difficult organisation may show less progress than one that started well. Understanding the starting conditions is part of a fair assessment.

Do not compare across teams. Different products, different constraints, different maturity. Comparison produces a ranking and no information.

When the Numbers Are Not the Scrum Master's Fault

A necessary caution for anyone doing the assessing.

A Scrum Master's effect is bounded by what the organisation permits. Someone working with a team whose scope is fixed by contract, whose funding is committed annually, and whose members are reallocated every quarter can do excellent work and show very little movement in any measure.

Three questions separate a performance problem from an environmental one.

Has the Scrum Master identified the constraint? If they can name precisely what is limiting the team and who owns it, they are doing the diagnostic part of the job.

Have they raised it? With whom, and how often. Raising it once and stopping is different from pursuing it.

Was it within their power to change? Frequently it was not, and holding someone accountable for an outcome they cannot influence is the fastest way to lose a good Scrum Master.

Recognising which of the three is in play requires understanding the role properly, which is a substantial part of what CSM Certification Training covers alongside the framework itself.

Self Assessment

For a Scrum Master assessing their own contribution, six questions about the last quarter.

What did the team resolve without me? If very little, the coaching has not landed.

How much of my week was mechanical? Board updates, status assembly, room booking. Above a quarter suggests drift into administration.

Which Retrospective actions actually completed? Not agreed. Completed.

What organisational impediment did I raise, and to whom? If nothing comes to mind, the outward half is being skipped.

What did I coach someone on, specifically? Coaching disappears first under pressure and produces the most durable capability.

When did I last disagree with someone senior? Never, across a quarter, usually means boundaries are not being held.

Answer these honestly every three months and the pattern is more useful than any manager's review. Two answers pointing the same way is the thing to work on, and it will be more specific than any score.

If You Are Being Measured Badly

A practical section, since many Scrum Masters are handed a metric they did not choose.

Find out what the number is for. Usually someone senior needs evidence the investment is working. That is a legitimate need badly expressed, and it is negotiable in a way the metric itself often is not.

Offer a better answer to the same question. Rather than refusing to report velocity, propose what you will report instead: carryover trend, Retrospective actions completed, one organisational impediment pursued. People asking for a metric usually want reassurance, and a more honest set of evidence frequently satisfies it.

Report the team's measures, not your own. Effectiveness is a team property. Framing the report that way is accurate and it removes the individual comparison that does most of the damage.

Say what the metric will do. Not as an objection but as a prediction. If velocity becomes a target, it will rise and delivery will not change. Saying that in advance, and being right, is more persuasive than arguing in the abstract.

Escalate once, properly. If a genuinely harmful measure is imposed anyway, raise it with evidence, then work within it. Continuing to object after a decision makes you the obstacle without changing anything.

The situation worth naming honestly is a Scrum Master judged on team output in an organisation that will not change how it funds or governs delivery. That is being held accountable for something outside your influence, and it is a reason people leave the role. Recognising it as structural rather than personal matters, and being able to articulate it clearly is part of what CSM Certification Training prepares people to do.

What Improvement Actually Looks Like

Since the aim is evidence of contribution, it helps to know the shape of it over time.

Months one to three. The Scrum Master is doing a lot personally. Events run, impediments get cleared, and the team leans on them heavily. This is normal and it should not persist.

Months three to six. The team starts handling its own blockers. Retrospective actions begin completing. The Scrum Master's calendar has more coaching in it and less chasing.

Months six to twelve. The team runs its own Daily Scrum without facilitation. Difficult things get raised without prompting. The Scrum Master spends meaningful time outside the team boundary.

Beyond a year. The team could function without them for a fortnight. The Scrum Master's remaining value is largely.
organisational: pursuing constraints, coaching other teams, protecting the conditions the team needs.

That trajectory is the measure. A Scrum Master whose team depends on them as much in month twelve as in month two has been serving rather than developing, however competently. The direction matters more than any point on it, and it is visible to anyone who looks at the team rather than at a dashboard.

Closing Thoughts

The honest answer to how you measure a Scrum Master is that you largely cannot, not in the way organisations usually mean. The accountability is for a team's effectiveness, which is influenced rather than controlled, and the parts of the role that matter most have no unit.

What works is looking for evidence of capability built. A team that resolves its own problems, completes what it agrees to improve, says uncomfortable things out loud, and could function for a fortnight without its Scrum Master is evidence of someone doing the job well. None of that fits on a dashboard.

The thing worth avoiding hardest is installing a metric because something must be measured. Velocity targets, impediment counts and event attendance all produce movement in the number and no improvement underneath, and they select for the administrative version of a role whose value lies somewhere else entirely.

If you are building the judgement this depends on, CSM Certification Training covers the accountabilities and the coaching that produces capability rather than dependency. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to check where you stand.