TL;DR: The Scrum Master Theses

The following 70 Scrum Master theses describe the role of the scrum master from a holistic product creation perspective.

The Scrum Master theses cover the role of the Scrum Master from product discovery to product delivery in a hands-on practical manner. On the one side, they address typical Scrum events such as Sprint Planning, Sprint Review, and the Sprint Retrospective. On the other hand, the Scrum Master theses also cover, for example, the relationship with the Product Owner, they deal with agile metrics, and how to kick-off an agile transition, thus moving beyond the original Scrum Guide.

Do you want to get this article in your inbox? You can sign up here and join 27k other subscribers.

The Scrum Master Theses in Detail

The Role of the Scrum Master

This first set of the Scrum Master theses addresses their role in the Scrum process:

Scrum is not a methodology, but a framework. There are no rules that apply to each and every scenario — just good practices that have worked before in other organizations.

The good practices of other organizations cannot simply be copied to your own. Every good practice requires a particular context to work.

As somebody hiring for a Scrum Team, you need to determine for yourself what works for your organization — which is a process, not a destination.

The role of a Scrum Master is primarily one of servant leadership and coaching. It is not a mere management role. (Although the Scrum Master role also has management aspects, for example, regarding the responsibility for promoting and supporting Scrum within the organization.)

A Scrum Master should recognize that different stages of a Scrum Team’s development require different approaches: some, teaching; some, coaching; and some, mentoring.

A Scrum Master should know of the Shu-Ha-Ri (Japanese martial arts) method of learning new techniques.

A Scrum Master’s principal objective should be to remove themselves from daily operations by enabling the Scrum Team to be self-organizing.

Being a Scrum Master does not entail, and should never entail, enforcing processes.

Scrum is not designed for bean counters, although some metrics are helpful in understanding the health of a Scrum Team. Generally, insisting that the team achieve specific KPI (e.g. forecasts vs. velocity) does not help.

Scrum doesn’t elaborate on the process that enables a Product Owner to add valuable, usable, and feasible work items such as features to the Product Backlog. Product discovery using the Design Thinking, Lean Startup, or Lean UX frameworks help, but in any case, a good Scrum Master will want the Scrum Team to be a part of this process (whether by participating in user interviews or running experiments).

A Scrum Team’s communication with stakeholders should not be run through a gatekeeper (e.g. solely through the Product Owner) because this hurts transparency and negatively affects the team’s performance. Sprint Reviews, conversely, are a good way to stay in close contact with stakeholders and to present the value delivered by the Scrum Team during each previous Sprint.

Product Backlog Refinement and Estimation

The second set of the Scrum Master theses focuses on the importance of the Product Backlog refinement:

Product Backlog refinement and estimation are essential tasks for every Scrum Team. Although the Product Owner (at least officially) is in charge of keeping the Product Backlog at ‘peak value delivery’, they need the assistance of the entire Scrum Team to do so.

A cross-functional — be it distributed or co-located — Scrum Team working independently of other teams is an ideal scenario. The reality is that most Scrum Teams will often be dependent upon deliveries from other teams (e.g. API endpoints ) and deliverables from the UX or UI people if those are not embedded within a Scrum Team.

There are two essential ingredients for good Scrum Team performance: a) Writing user stories as a team. When a new feature should be built, the Product Owner first explains why and provides the necessary background (i.e. market intelligence, results from experiments, user interviews, statistical data). Writing user stories, then, is a collaborative effort involving the entire Scrum Team. The process should create a shared understanding of what will be built and for what reasons (the Product Owner providing the ‘why’, the Scrum Team detailing the ‘how’, both negotiate the ‘what’), and a shared sense of ownership among team members. A good team will always challenge the Product Owner whether a proposed functionality is indeed the best use of the Development Team’s time. (Please note that not all Product Backlog items are user stories. There are, for example, also bugs, spikes, or non-functional requirements that do not fit into the user story template.) b) Keeping technical debt at bay. When a weak Development Team meets a commanding Product Owner, focusing on shipping new features, the team may end up as a feature factory, churning out new code while neglecting the technical foundation. A good Scrum Team pays attention to the preservation of an application’s technical health to ensure the Scrum Team is ready to actually pursue an opportunity in the market. (Read more: Technical Debt & Scrum: Who Is Responsible?)

A well-refined Product Backlog probably has work items detailed for about two or three Sprints in various refinement stages. There may also be additional work items that no one except the Product Owner is working on.

Product Backlog refinement is a continuous process involving the Product Owner, the Development Team members, and probably subject matter experts or stakeholders.

A Product Backlog is “actionable” if the Scrum Team can organize a successful Sprint Planning at a moment’s notice.

Cannot see the form?

Please click here

Sprint Planning

The third set of the Scrum Master theses covers the Sprint Planning:

It used to be that a Product Owner would explain high-value user stories to the Scrum Team during Sprint Planning. The Scrum Team would then turn these into more detailed work items and probably the subsequent task. There is now, however, a consensus among practitioners that working on these high-level user stories continuously in separate Product Backlog refinement process — during the Sprint — actually improves the quality of the items and thus the outcome of the team’s work.

Sprint Planning creates a sense of ownership among a Development Team’s members by enabling them to make a valid forecast regarding the Sprint Goal and subsequently the composition of the Sprint Backlog. But this only happens if a Scrum Team is certain about the quality of the Product Backlog items in question.

It is the prerogative of the Development Team members to pick the Product Backlog items that compose the Sprint Backlog. No one can force work upon the Development Team.

If Product Backlog refinement is handled well, an entire Sprint Planning session might be completed within than 2 or 3 hours.

A productive Sprint Planning requires a healthy Scrum Team. Dysfunctional teams will not achieve the level of cooperation required. Sprint Planning with dysfunctional teams will only result in a futile and painful exercise.

A Scrum Team should usually avoid allocating more than 80% of their capacity to working on new tasks — including user stories, technical tasks, bugs, and probably spikes. Flow theory shows that a 90% or higher allocation of available capacity will not lead to a team achieving their peak performance. A high-performing Scrum team needs slack time to be prepared for the unexpected or share knowledge among themselves.

Bugs, refactoring, and research all require regular attention in order to avoid building-up technical debt. An effective Scrum Team allocates approximately 20 to 25% of their capacity to these tasks.

Incomplete and poorly prepared work items seriously hamper the effectiveness of a Scrum Team. These items should never be selected for the Sprint Backlog, but instead sorted out during Product Backlog refinement meetings.

Daily Scrum

The fourth set of the Scrum Master theses addresses the Daily Scrum:

Standups are meetings well suited to discuss a current sprint’s progress: is all going as planned, or does the scrum team need to adjust?

Standups are a convenient time for a scrum team to meet and communicate with a project’s or product’s stakeholders.

Standups cannot fix, among other things: a dysfunctional organization, a dysfunctional scrum team, an inadequate product backlog, a sprint planning session gone wrong, low-quality user stories, or a missing product vision.

Standups are valuable if the scrum team is already collaborating well and the basics — such as the product backlog, and sprint planning — are in order.

The more experienced a scrum team, and the better the internal communications, the more a standup will seem a time-consuming ritual of little value.

An advanced scrum team may consider virtual meetings instead of real meetings using, for example, a Slack channel.

A two-person scrum team does not necessarily need a formal standup — meeting for coffee would be a practical alternative.

There is something wrong with a scrum team whose members do not communicate impediments before each standup. It’s possible they’re acting more like a group of people being in the same place at the same time pursuing a similar goal than a scrum team.

Standups are not reporting sessions for the benefit of product owners or participating stakeholders.

Offline boards are valuable: physically taking a card and moving it instills a sense of ownership of a user story. (This is the same mental model why sales-people want you to touch the merchandise before making a purchase.) If you must let go of either an online or offline board and you are a co-located team, consider letting go of the online board.

Sprint Retrospectives

The fifth set of the Scrum Master theses deals with Retrospectives:

Retrospectives should encourage self-expression, thereby making it easier for a scrum team to uncover the concerns and frustrations that its members may be harboring so that strategies may be devised to overcome them.

Retrospectives will only improve a team’s collaboration and performance if the team considers these meetings a safe place to provide honest and constructive feedback.

The blame game is not helpful. During a retrospective, the members of a scrum team should focus on how to improve a situation — and avoid blaming one another.

Some scrum teams always include the product owner in their retrospectives, while other teams insist that the product owner should be expressly invited.

It’s best not to hold retrospectives at a team’s workplace. Distance makes it easier for team members to reflect on the sprint. It’s also helpful to regularly change locations for the meeting. Being in a new locale helps to prevent boredom (and team members ‘checking out’).

The format for a scrum team’s retrospectives should be changed regularly. The same format should not be run more than twice.

Smartphones, tablets, and laptops should not be permitted at retrospectives so that the members of the scrum team are not distracted, and can focus on contributing to the meeting.

All issues, concerns, and frustrations, should be documented — even if just temporarily using sticky notes. Though it’s always better to keep a formal document or file.

According to Diana Larsen and Esther Derby in their book “Agile Retrospectives: Making Good Teams Great,” there are five stages to running a retrospective: Setting the stage, Gathering data, Generating insights, Deciding what to do, Closing the retrospective.



A retrospective should set SMART goals for action items (the tasks to be done): Action items should be specific and measurable (“do X more often” does not meet that criteria), A single member of the scrum team should be made responsible for each action item, Each action item should include an estimate of when results can be expected, Action items should be placed on a board to make tracking progress visual and more prominent,



Every new retrospective should start with reviewing the status of the action items decided upon during the previous retrospective.

Agile Metrics

The sixth set of the Scrum Master theses addresses on agile metrics:

The purpose of metrics, generally, is to understand a current situation better and gain insight on how it’s likely to change over time.

A metric is a leading indicator for a pattern, providing an opportunity to analyze the cause of change — and act appropriately in due course.

Metrics in an agile context are not used to manage, and certainly not micromanage, an individual (particularly the creative worker) — contrary to traditional command-and-control management structures.

Metrics in an agile organization should be used to provide the scrum team — agile practitioners all — with insights on how to continuously improve, helping them achieve their goals: Agile practitioners strive for autonomy, mastery, and purpose as explained by Daniel Pink. Agile practitioners address personal development with metrics by applying methods like Objectives and Key Results (OKR).



The experienced agile practitioner realizes that autonomy and accountability are equally important for self-organized scrum teams. Without metrics, both autonomy and accountability are limited.

The metrics most suitable to agile reflect either a team’s progress in becoming agile or the organization’s progress in becoming a learning organization.

Both qualitative and quantitative metrics are used: Qualitative metrics typically reveal more than quantitative metrics when applied to the scrum team. Quantitative metrics provide more insight than qualitative metrics when applied to the organization.



Any metric used for agile must be tailored to the organization.

The metrics that the scrum master should be tracking are only those that apply to the scrum team. Metrics that measure the individual should be ignored.

A metric’s context should always be recorded to avoid misinterpretation.

Parameters that are easy to follow should not be measured for that reason alone — especially if a report is readily available in the project management software being used.

How to Kick-off a Transition to Scrum

The seventh set of the Scrum Master theses covers agile transitions:

There is no checklist or master plan readily available, or that could be made readily available, that would ensure a successful transition to agile practices such as scrum. This also applies to SAFe, LeSS, Nexus, DAD, XSCALE, or the so-called ‘Spotify methodology.’

The ‘best practices’ of and ‘lessons learned’ by other organizations during their transition to scrum may indicate a direction to take when transitioning, though the context of their transition may not be comparable: what worked for Spotify may not work for General Motors.

Every transition should start with understanding the ‘why’: why should the organization become agile?

Reasons typically given by management for transitioning to scrum and other agile practices include: Making the organization more efficient; Helping the organization deliver faster; and Improving the predictability of delivery dates.



The recognized benefits of transitioning to scrum and other agile practices are: Outperforming competitors by creating a learning organization; Creating a great workplace culture by providing room for autonomy, mastery, and purpose; and Mastering continuous product discovery and delivery (thus minimizing risk).



Agile practices’ benefits need to be sold to an organization before beginning a transition — agile is not everybody’s darling, and personal agendas will be affected by a successful transition.

A transition will encounter inertia and resistance to change directly proportional to the size of the organization.

How an agile transition should be undertaken depends upon many factors, including an organization’s industry, regulations and compliance rules, the size and age of the organization, workplace culture, the maturity of an organization’s products and services, team sizes and the number of teams, and current project management practices.

How a transition is undertaken should be determined by the goals of the organization — what is hoped to be achieved.

A successful agile transition requires the backing of C-level executives; a bottom-up approach is futile.

The first step of any transition to scrum is the creation of the first scrum team.

Transitioning to agile practices requires training and educating of most members of an organization — not just future scrum team members — in agile practices and principles. Training and education are essential for a successful transition. Read more : Prototyping with Absolute Beginners

: Prototyping with Absolute Beginners There is a huge difference between ‘doing Agile’ and ‘being agile’. Transitioning successfully means becoming — and being — agile.

In an organization transitioning to scrum, future scrum masters should be agents of change rather than drill sergeants — this is by design, given their lack of proper authority.

Creating a ‘happy agile island’ for the product and engineering department is a valid objective. However, in comparison to breaking up functional silos and creating a learning organization, it is likely to deliver a lesser return on investment.

The Scrum Master Theses — The Conclusion

To be a successful Scrum Master, you will need to have a holistic understanding of the product creation process. You will need to be a part-time agile coach, too, dealing with organizational impediments and constraints, while training other members of the organization and looking for prospective change agents that may join your course. You need to sell ‘agile.’ You need to win hearts & minds within the organization to overcome its inherent resistance to change. Hence, facilitating Scrum Ceremonies is just a small part of a Scrum Master’s job.

Which relevant scrum master theses are missing to describe the role in a better way? Please share with me in the comments.

Update 2018-12-15: The Replay of the Webinar Scrum Master Anti-Patterns Is Available

The video of the webinar is available now:

Scrum Master Anti-Patterns — (Hands-on Agile Webinar #8)

Watch this video on YouTube

Note: If the browser will not start the video automatically, click here to watch the replay of the webinar Scrum Master anti-patterns directly on Youtube.

📕 Now Available: ‘How to Get Hired as a Scrum Master’

Scrum Master Career: How to Get Hired as a Scrum Master: From Job Ads to Your Trial Day — Learn How to Pick the Right Employer or Client details how Scrum Masters and Agile Coaches can systematically identify suitable employers or clients to avoid mismatches and disappointments at a later stage. If you are planning a career move into the Scrum Master profession, don’t miss out on these tips.

Scrum Master Career: How to Get Hired as a Scrum Master is currently available as a Kindle ebook. Shortly, the paperback version will be available, too.

✋ Do Not Miss Out: Join the 8,000-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join, all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.



The Scrum Master Theses — Related Posts

The Scrum Master Trends Report 2019

The Scrum Master Salary Report 2017

Download the ’Scrum Anti-Patterns Guide’ for Free

Scrum Master Anti-Patterns — 20 Signs Your Scrum Master Needs Help

Peer Recruiting: How to Hire a Scrum Master in Agile Times

22 Scrum Master Anti-Patterns from Job Ads

Lipstick Agile — 15 Signs You Probably Need a New Job or to Roll-up Your Proverbial Sleeves

Speaking Truth to Power 2.0 — Taking A Stand as an Agile Practitioner