Six Attributes of a Great ScrumMaster

Six Attributes of a Great ScrumMaster:

Become the Scrum Master Your Team Needs

Are you thinking about becoming a Scrum Master and wondering if you have what it takes to do the job? Are you already a Scrum Master and asking yourself, What are the characteristics of an effective Scrum Master? Or are you perhaps looking to hire someone and want to know what Scrum Master skills and traits to look for?

If you answered yes to any of those questions, this article is for you. I’ve identified six Scrum Master characteristics and behaviors that are essential for success. I've even included a seventh, bonus Scrum Master quality, for those who want to take their success to the next level.


Being responsible is an essential characteristic of Scrum Masters. While a ScrumMaster is not responsible for the success of the project—that remains with the team—a ScrumMaster is responsible for the team’s adoption and practice of the Scrum process.

A Scrum Master takes on this responsibility without assuming any of the power that might be useful in achieving it. They are instead a servant leader to the team.

A Scrum Master’s role is similar to that of an orchestra conductor. Both must provide real-time guidance and leadership to a talented collection of individuals who come together to create something that no one of them could create alone.

Boston Pops conductor Keith Lockhart has said of his role, “People assume that when you become a conductor you’re into some sort of a Napoleonic thing—that you want to stand on that big box and wield your power. I’m not a power junkie, I’m a responsibility junkie.”

In an identical manner, ScrumMasters thrive on responsibility—that special type of responsibility that comes without power.


A humble Scrum Master is not in it to pump up their ego. They know that it’s not a job that comes with ego-boosting perks like a company car or parking spot near the building entrance.

Humble Scrum Masters take pride in their achievements but know that they look good when their teams look good. So they do whatever is necessary to help the team achieve its goal. And when the team achieves something extraordinary, they make sure everyone in the organization takes note and celebrates that success, including the team members themselves!

Humble Scrum Masters are quiet and wait for others to weigh in. They embrace the effectiveness of the all-important pause, the enabling power of silence. When they are tempted to speak, they wait first first for others—serene in that awkward stillness that follows a complicated question or thought-provoking comment.

They are comfortable not being the one with all the answers. They know that to become a fully autonomous, self-organizing team, the team needs silence more than it needs insightful comments from the Scrum Master.

Part of being quiet is listening. Humble Scrum Masters resist the temptation to begin forming a mental reply before a team member has finished speaking. Instead, when someone else is talking they give their full attention. They recognize the value in all team members and, by example, they lead others to the same opinion.

Being humble is one of the most effective Scrum Master traits.


Scrum Masters nurture a collaborative culture within the team. They ensure team members feel able to raise issues for open discussion and that they feel supported in doing so. They establish collaboration as the team norm and call out inappropriate behavior (if the calling-out isn’t already done by other team members). And they ensure the development team is working together effectively throughout each sprint.

They are aware of what’s happening with the team without crossing the line into micromanagement. In short, they check in without making it feel like they’re checking up.

While checking up and checking in may seem similar, they are actually quite different. Scrum Masters who check in don’t just ask about progress; they offer real help in removing any obstacles or distractions that are impeding that progress. They avoid blaming individuals at all costs. And, perhaps most importantly, they ensure the team is given complete autonomy to solve whatever problem the team’s been given.

Checking up is very different. When you check up on someone, you are looking for conformity to a plan—did the programmer finish the changes last night as she said she would? Did the tester automate the tests as promised or just run them manually “one more time” again?

Checking up is about getting status-type information. That’s fine. But checking in goes beyond that to include offering to help remove any impediments to progress.

Collaborative Scrum Masters check in often, to ensure the team can move together toward their sprint goal.


While the Scrum Master role does not always require a full-time, eight-hour-a-day commitment, it does require full commitment to the role for the duration of the project. The Scrum Master needs the same high level of commitment to the project and goals of the current sprint as team members.

Committed Scrum Masters have a daily goal to resolve all known impediments. That doesn’t mean they can necessarily clear every impediment by the end of every day—some impediments take some time and maneuvering to remove. But they make some progress every single day.

They know that Scrum Master strengths are not about doing the work—but about making the work easier for the team to accomplish.


An essential trait of Scrum Masters is the ability to influence others, both on the team and outside it.

Initially, team members may need to be influenced to give Scrum a fair trial or to behave more collaboratively; later a Scrum Master may influence a team to try new technical practices such as test-driven development or pair programming. A Scrum Master should know how to exert influence without resorting to a command-and-control “because I say so” style.

Scrum Masters can also be called upon to influence those outside the team. A traditional team may need to be convinced to provide a partial implementation to the Scrum team, a QA director may need to be influenced to dedicate full-time testers to the project, or a vice president may need to be convinced to try Scrum at all.

While all Scrum Masters should know how to use their personal influence, the ideal ScrumMaster has a degree of corporate political skill. The term corporate politics is often used pejoratively, but it’s an asset to a team to have a ScrumMaster aware of things like how decisions are made in the organization, who makes them, and which coalitions exist.


The best Scrum Masters have the technical, market, or specific knowledge to help the team in pursuit of its goal.

LaFasto and Larson have studied successful teams and their leaders. They have concluded that “an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed.”

LaFasto and Larson note that the knowledge may be broad rather than deep but that team leaders (such as Scrum Masters) “need to be conversant around the key technical issues.”

Knowledgeable Scrum Masters understand enough about key technical issues to be able to explain the problem to others in the organization when necessary. They also have a general understanding of the market and the opportunities and challenges surrounding the product.

Scrum Masters who don’t yet have all of these skills must work to acquire them. They don’t need to become expert developers or product marketers. But they do need to know enough about these areas to assist the team in resolving problems.

Bonus Trait: Know When to Break the Rules (And When to Hold Firm)

The rules of Scrum are minimal but they exist for good reasons. Each helps a team be agile and increases the likelihood of success.

Scrum Masters are unbending when it comes to certain rules and uncompromising in their confidence in the team’s ability to find a way forward. At the same time, they use common sense when a rule doesn’t work for their situation.

Here are some rules Scrum Masters should enforce almost all the time: 

  • Don’t let the team get away with taking partial credit for a story (with one notable exception).
  • Don’t allow the team to honor only the agile principles they find the most enjoyable. (For example, many teams incorrectly interpret the Agile Manifesto to say that no documentation is needed.)
  • Encourage participation from every team member in daily scrums and retrospectives.

And an unbreakable rule for the Scrum Master is to refrain from solving problems for the team that they should solve themselves. Sometimes working together to solve a problem (such as too many bugs) helps a team identify ways to make sure the problem doesn’t recur (such as test-driven development, pair programming, or continuous delivery).

But, as the saying goes, rules are meant to be broken.

Successful Scrum Masters learn to recognize those situations in which it’s appropriate to break the rules.

  • Never extending a sprint is a great rule. Usually. Can it be broken? Yes—not often and always for a good reason (such as a holiday that makes a longer sprint sensible).
  • Working software at the end of each sprint is a great goal. Is it reasonable to expect it every single sprint? Not necessarily.
  • Three hours is the maximum duration of a sprint retrospective. And 99% of my retrospectives are done in less time, usually far less time. But have teams I’ve coached broken this three-hour rule? Yes, occasionally, when a really hot topic was being discussed and it seemed better to continue than to postpone a crucial conversation.

Qualities of a Good Scrum Master

To sum up, Scrum Masters share at least 6 traits: They are responsible, humble, collaborative, committed, influential, knowledgeable. And the best Scrum Masters also know when to abide by the rules and when to break the rules.

All the Scrum Master Advice You'll Ever Need

All the Scrum Master Advice You'll Ever Need

Sign up for Mike’s Weekly Tips and receive this PDF: Ten Sentences With All the Scrum Master Advice You’ll Ever Need

Sign Up Now!
Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at If you want to succeed with agile, you can also have Mike email you a short tip each week.