Opinion: What Makes a Scrum Master an Effective One?


I’ve recently been asked:

“Would you have any pointers to any internal or external information you recommend on guiding/teaching scrum masters on how to be an effective one?”

This very straightforward question actually has a complex answer.

The main cause for this is that the role of the Scrum Master is, intentionally, not something that you can map to some of existing clear-cut roles of Project Manager, Team Lead, (People) Manager. It also has some restrictions that are required to keep the role effective.

So before I delve into dishing out recommendations, I first want to deconstruct the role that is a “Scrum Master” from my first-hand experience and point-of-view.


As said before the Scrum Master role is a hybrid. It has been intentionally crafted from different pieces of other roles and received new responsibilites. As such many people, especially if they transition from traditional roles (e.g. as a Project Manager) struggle. I’ve seen quite a few attempts at “mapping” existing processes and behaviors to the new role. My take is, if you actually “succeed” in doing that, you miss out on the chance of a profound change in the way you work and thus forfeit many if not all of the benefits this brings.

So with that in mind let’s not try to see what role is similar to a Scrum Master or how you can best map your existing stuff – let’s take a look what a Scrum Master, in my opinion, should focus on.


The Scrum Master’s responsibilites are broken up among three areas, all in equal measure.

1. Process

Knowledge and application of Scrum within the Agile Mindset. Understanding the different elements and artifacts, why they have been created and where to apply them.

2. Coaching

Enabling others to understand and implement the Agile Mindset. Understanding their issues and offering support in resolving them. Helping the team and stakeholders to achieve mastery in their craft.

3. Leadership

Offering guidance and a clear vision where needed. Ensuring organizational alignment across all levels. Establishing and maintaining communication between involved parties. Creating transparency where ever possible.

Beyond Process Ownership

The first thing that might be surprising is that the responsiblities go beyond pure “Process Ownership”. Although the Scrum Master is usually introduced as a role to whip the team an stakeholders into shape the role needs to quickly transcent that singular focus if to be able to unleash to the team’s full potential.

Just owning the process alone but not being able to foster understanding in the “Why” and communicating the results will just lead to people blindly following it “because Scrum says so”. How will you ever achive wide acceptance or continuous improvement if nobody gets why you are actually going Agile (Leadership) and addressing their concerns (Coaching)?

Providing Coaching without knowing the process can cause you to miss the realities of the business and denies you the tools to model the day-to-day work (Process). Also if people do not follow your leadership why would you even make suggestions (Leadership)?

Finally assuming leadership is not something reserved for those carrying a “Manager” title. Everybody can take up leadership if the cause is worthy and the time is right. That said a Scrum Master is the embodiment of a “Servant Leader” – working not to order people around but to offer assistance and then get out of the way as quickly as possible. To provide leadership you need to understand the issues people are facing (Coaching) and have the right tools to offer solutions (Process).

In the end it all comes together to form a whole, rounded role that goes way beyond Process Ownership.

No Discliplinary Power

In my opinion the Scrum Master cannot be someone with disciplinary power over the team members.

The Scrum Master can also not (asked to) be part of the performance review process for team members.


The Scrum Master’s goal is to unleash the power of the team. To that end the Scrum Master must work on neutral grounds and the principle of confidentiality when talking to to team members, especially on touchy subjects.

Sometimes team members may be hesitant to name issues openly if it concerns their work, mistakes or other people – especially if the person they are talking to is supposed to hand out their performance rating at the end of the year.

A first-line manager cannot be a Scrum Master. Avoid this at all cost.

No Part-Time Job

If you look back up at the three responsibilities you see topics that are as vast and diverse as can be. Many companies today are hiring people for full-time Scrum Master jobs.

And for a good reason: It is a full-time job.

To enable a Scrum Master to actually be able to fill out all of these responsibilities the time has to be available to do so.

Just adding Scrum Master responsibilities to an existing “Developer” or “Lead Developer” role might sound obvious but is also wrong.

The dual role automatically creates a conflict on time allocation starving both roles for focus and attention. With the constant context switches and lack of depth you will not see a 50:50 split – rather something along the lines of 20% and 20% is more realistic. Around 60% will be getting lost because of interruptions and the person becoming quickly overburndoned and entering a purely reactive state, working down the ever-increasing stack of “stuff to do”.

This not only increases stress but also a creates a liability for the team and the business as both cannot rely on the person to both deliver the development and Scrum Master commitments.

If you want somebody to become a Scrum Master make it a full-time job.

Also: A good Scrum Master can handle two teams. An excellent Scrum Master can handle one team.

Mindfulness Required

Just as the Scrum Master is not just a Process Owner the person owning the role is not just an employee – we’re (thankfully!) working with human beings. And this requires a surprising knowledge of the human self.

Mindfulness is a broad topic oftentimes stretched to cover different areas of conscious behavior, recognition of (inner) body signs, empathy and vision.

For me mindfulness starts at the self – recognizing that you are more than just your intellect and logic. Accepting that your emotions and instincts are not something to be turned-off or pushed away. And finally listening closely to what your body is very subtly trying to tell you. If that sounds like new-age feel-good mumbo-jumbo… well, let me tell you that ignoring all of this for too long could lead to you being at an all-time high stress level until you suddenly get nosebleeds in meetings and almost collapse from exhaustion. All the while being completely confused why you are all-time angry and your damned body refuses to play along.

This is not a place you want to go. Ever.

The problem with a lot of that is many people – including me – have learned to suppress their needs over so many years that the natural signals are no longer properly recognized or automatically subdued. This is not a process that happens in a few weeks or months. It takes years to manifest – or “learn” – until it has become a state that feels completely “natural”.

A Scrum Master being lodged in between many parties and having to negotiate sometimes really tough topics needs to have a lot of mental and physical buffer to take almost anything with a degree of calm and professionalism. This calmness cannot be enforced or upheld by pure will. It is something that requires the Scrum Master to ensure regular de-compression from stress and work-related pressures.

To do be able to achieve this state is is neccessary to properly and honestly understand where one currently is. How stressed am I really? What do I REALLY need now? What is my body REALLY needing now?

This requires careful approach, reflection and – especially – time.

This creates a shared responsibility both for the Scrum Master to establish practices for Mindfulness as well as the surrounding business to give the space to do so.

Failing to do so could jeopardize entire teams by subjecting them to overworked, stressed-out Scrum Masters.

It’s About Succeeding Better

You might have heard of other projects that did things that I have recommended against and still were considered successful. And I have no doubt that they were successes.

But have you ever asked yourself it there is only a binary state of Success/Failure or if there are degrees?

What if the projects you heard of where successful with only 20% of their potential realized? Where would the projects be now if they could have realized 50% or even 70% of their potential?

To come full circle with the initial question about become more effective a lot of the options here are not about “just” succeeding.

They are about Succeeding Better.

I invite you to try them out for yourself and let me know in the comments or via email how it went for you.

Further Information

Process Knowledge

Essential Scrum by Kenneth Rubin

Agile Retrospectives by Derby et al.


Coaching Agile Teams by Lyssa Adkins

Start With Why by Simon Sinek

Drive by Dan Pink


The Humble Inquiry by Edgar Schein

Influencer by Grenny et al.



In the past we treated Stories mostly like a rough idea with more details to follow as needed. Scrum states that you do not waste time on unnecessary detail and documentation. So this handling fits right? Wrong. A lot of people understand the lowered volume of documentation in Scrum as “do no documentation at all”.

The difference is on the emphasis on “unnecessary”. This means leave out anything that you do not need or will not need in the immediate future – but still do EVERYTHING else.

For Stories this means you need to look at your stories regularly to find out what they are in and if they are ready to be tackled in a sprint. If do not track this status closely you might end up with a lot of rough ideas that lack refinement or details at the time they should be put into a sprint. In the worst case you look at your backlog and marvel at all these stories and elements in there – without knowing that most of them are missing crucial refinement.

The end result is that you will spend a lot of time in your planning meetings trying to salvage the situation or –even worse – do not spend the time and have the team work on unclear requirements and scenarios. To get around this issue my teams and I developed a story lifecycle called “Story Maturity”. This lifecycle tracks the story from inception to sprint-readiness and sets ground rules for each step.

Story Maturity

So how does this work? First of all we acknowledge that stories are living documents that evolve from a raw state into an actionable item. However this does not occur automatically – a story does not ripen like good wine – it requires effort. Some stories will be a no-brainer and easy to refine some others require more attention – but either way you and your team will have to spend the time on getting them in shape for the sprint – BEFORE the actual planning meeting starts!

Story Maturity follows a set of status values and rules for their handling which are outlined below:


The story has just been discovered. It lacks necessary detail and may just be a snipped that you wanted to put in not to forget it. Stories in the initial state always go into a special backlog. This may be the overall backlog or a “fountain of ideas” backlog where new stories gather. Do NOT put them into Release Backlogs or Sprints or you might otherwise end up with a lot of clutter that needs to be weeded out.


This story has received some work but is still missing crucial information. For example the actual story is missing (“As a ….  I want to….”) or the Acceptance Criteria were not filled out. The Story remains right where it is and will have to be worked on – usually by either the Product Owner or the discoverer of the story idea.


This story has the necessary filling but something is still unclear. Perhaps the requirements are not properly measurable, perhaps the goal is not clear. This state is usually set if during planning a lot of questions or conflicting views were raised. You put this story under close watch and get the responsible people together to make it more precise. The story remains in that state until the responsible people have agreed that the story is clear enough to be estimated.


The story is clear enough to run through a quick estimation. This means it has the actual story, description and acceptance criteria filled and can easily be understood by all team members. A story in this state can be PROMOTED by the Product Owner (and ONLY the Product Owner) to move from the “Fountain of Ideas” into a regular Release Backlog. The creator of this story should either pitch the story before the sprint planning meeting or do an impromptu elevator pitch of no more than 60 seconds to get a story promoted.

 The next step is to do a short poker session of about TWO MINUTES. Yes, two minutes. No longer. Do a quick poker session and if you have estimates that are very close together (no more than one step apart, like 5,5,8,8) you either take the majority or the higher number. If you see a discussion breaking out or if the estimates are wildly distributed the story many not be as clear as it should.
The team should then decide if they want to spend the time now to make discuss the story or if it has to be put to “Unclear” and will not be part of the sprint being planned.

Depending on the situation a team might immediately continue with the Pre-Estimated step if the story is likely to be tackled in the current sprint. If it goes back to the backlog this is where you can stop and move on to the next item.


This state means that the story has passed through a pre-estimation session with all the requirements for it. The story is usually in very good shape and can be plucked from the backlog. To get it “Sprint-Ready” the team has to do two simple tasks:

  • Check if the story is still applicable and clear in its current state
  • Do a final poker session

If both of the above tasks are completed the story can now be set to “Sprint-Ready” and put into the backlog of the upcoming sprint.


This story is good-to-go!  🙂

Story Promotion

The Product Owner is accountable for both a project’s success and failure. He or she should therefore be the only person that can have a final say on what gets in a release and what does not. Therefore newly discovered stories do not just waltz into the release or sprint backlog – they have to be pitched to the Product Owner.

The Product Owner should regularly look into the separate “Fountain of ideas” backlog and be open to people trying to pitch their stories. However at the end of the day the Product Owner has the final say on the contents of the release backlog.

That way you can ensure harnessing the full creative force of your team and stakeholders while not diluting your backlogs with unrefined ideas.


What this story lifecycle called “Story Maturity” gets you is transparency on the work necessary before a story can be tackled and a clear indicator if you can dare put it into the next sprint or not. By following these indicators closely and being very honest while doing so you can cut down the time necessary to spend in the planning meetings.

We went from three days planning to less than three hours following that lifecycle.

The Bottom Line

By acknowledging that User Stories are a living document that evolves with the right amount of effort you can create a meaningful easy-to-use backlog that will show you exactly what is ready to be tackled and what needs additional work. You also reduce the time spend in planning meetings feverishly trying to cobble together work items.

In the end your team will spend a lot less time sitting in meetings and a lot more time doing what they love: Creating meaningful software.

Scrumerfall (or: You’re Problably Still in Waterfall)

The transition from classical project management and development to Agile & Scrum can be quite drastic, turning the way work is done on it’s head (TDD) or even doing away with some things altogether (long isolated phases).

A lot of teams struggle through the transition – especially while working with legacy code that did not see the light of day on the green fields of Agile development but was created under the unyielding whip of crunch time.

Leaving all that – and the accumulated habits –  behind is difficult.

It’s therefore all the more compelling to map existing structures and workflows and plug them into the “new way of doing things” – and then call it “Agile”.

During every single Scrum training I received over the last years the trainers always issued a stern warning to be vigilant for signs that you are not really Agile but just pretending to be.

This creates (at least) two problems:
– You are not reaping the benefits of doing Agile & Scrum
– You are stuck with the issues of your old processes & habits

The first step to address both is to realize if you are deviating from the Agile path and then carefully plot your way back.

This blog post is based on my own experiences and understanding of the Agile & Scrum processes and intended to give you a few pointers and suggestions.
It’s not an attempt to declare what is “the right way to do it” – that is ultimately left for each team to decide on it’s own.

Without much further ado – let’s get started!

1. Stabilization / Hardening Sprints

Have you ever added Sprints at the end (or in regular intervals) where code changes are reduced to a minimum and all efforts are focused towards ironing out the bugs & integration issues?
If so you have probably created something like a Stabilization Sprint.

This kind of Sprint is more-or-less a direct equivalent of the Waterfall end phase where all QA testing and bug fixing is applied to the project. It’s where all the big integrations happen.
It’s also the time where things (latest) go south. Issues crop up like crazy, the integration fails and a storm front of crunch time is headed straight for you.

When following the concept of Scrum that only code that is covered by exhaustive, automated tests and accepted by the Product Owner is allowed into the release code how can that happen?

Well in theory it should never happen. And here’s where theory ends.

Stabilization Sprints and integration issues are a sign that automated, isolated quality control (TDD, Continuous Integration) is lacking.
This is an issue most often found with legacy code that wasn’t written to be properly tested. It could also hint at a team relying a lot on manual tests.

Either way you are highly vulnerable to unexpected stability issues and late-game deal-breakers.

To address this issue is to ensure high unit test coverage, deploying a fully automated CI system and doing a full test/integration cycle daily if not more often.
Some teams automatically integrate & test code every 15 minutes.

If you already have all that implemented find out what is causing the need to spend two or more weeks on hunkering down and squashing the bugs & quality issues.
Because you should be release-ready at the end of each sprint.

2. Sprint Zero

Have you ever added a Sprints with the number zero to your planning? Or even multiple ones (Sprint 0.1, Sprint 0.2)?

This kind of Sprint usually comes up when a project is something requiring a lot of upfront research and preparation. It includes clarifying the requirements, researching on technologies, setting up the development environment and so on.
Sprint 0 is an equivalent of the Plan/Design phases of Waterfall.

Now here’s where it gets controversial:
I think that spending time on research and preparation is time well-spent and it seems, depending on who you ask, the Scrum world is undecided if Sprint 0 is okay or not.
However let’s think about what Sprint 0 actually symbolizes: No customer value delivered. (That’s why it’s not Sprint 1).

And that – in my opinion – is not a good idea.

The goal of Agile & Scrum (and especially XP) is to get you writing code and generating value as fast as possible. Sprint 0 gives up on the focus on delivering customer value entirely.
It turns the entire time spent into sunk costs – essentially forcing the Product Owner to commit resources & time for Sprint 0 and at least another Sprint before value is created.

Instead of doing a Sprint 0 try a regular Sprint and use the time for prototypes and to implement the brutally simplest thing to do – even if it’s just a big fat hack.
Initiatives such as Hack Days yield mind-blowing results in just a single day. And they show what is possible and what is not by creating code that you can run and toy with.

And if you now think “Ah, but Hack Days are different” – what’s the difference? If you can be highly productive in a single day, what keeps you from doing the same in your regular project?
What can you change to enable it?

3. Sprint Length

How long are your sprints? 8 Weeks? 3 Months? Do your “Sprints” look more like a month-long death march?
Also did you ever extend the length of a Sprint because not all Stories could be closed at the regular end date?

If any of the above rings true you might be still working with the time scale & behaviors of regular project planning.

Scrum defines Sprint lengths to be exactly 30 calendar days.
Agile in general is more flexible depending on methodology used – going from seven days (XP) to six weeks (RUP).

With Agile teams can deliver smaller increments a lot faster than using regular project planning.

Both of the teams I guide as a Scrum Master are on two-week sprints. Both deliver solid customer value at the end of each sprint.
We had a lot of discussions on the right Sprint length and also tried out one week and three weeks but in the end two weeks were the ideal time frame.

Before that? Well … we were taking months between deliveries.

If your team is at the very limit of four/six weeks and still struggling – it’s not time you’re fighting, it’s most likely code quality (see 2.)

Lastly one personal remark on sprint extensions:
Do not extend the length of a sprint after it has been started. I did this once with one of my teams and it confused the hell out of people (“The sprint ends this week – right…?”).
We also de-synced from other teams leading to even more confusion down the road. While the underlying reason (a lot of people where away on holidays then) was sound the course of action was not.
It would have been better to look at the time frame ahead of the planning and check with the other stakeholders to see if there are any unexpected side-effects.

The Bottom Line

The transition from traditional project planning to fully embracing Agile & Scrum is long and can sometimes be difficult as it forces you to break with established processes & habits.
Not allowing this break to happen can cause you to be stuck with the worst of both worlds.

Three common signs that your team is still in the transition phase are Stabilization Sprints, Sprint 0 and Overlong Sprints.

If you consider yourself “doing Agile” and encounter any of these signs – it might be wise to check where you actually stand.

Do you deliver customer value quickly? Can you ensure that after every Sprint you have something stable? Something created to easily find the acceptance of the Product Owner and Stakeholders?
Concepts such as Test-Driven-Development, Continuous Integration and ultimately DevOps show a way to be ready. Every time. All the time.

So what’s holding you back?