70 Scrum Master Theses

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 hands-on practical manner. On the one side, they address typical scrum ceremonies such as sprint planning, sprint review, and the 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.

The Scrum Master Theses in Detail

The Role of the Scrum Master

This first set of the scrum master theses addresses her 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 practices that have worked before in other organizations.
Successful practices of other organizations cannot simply be copied to your own. Every practice requires a particular context to work.
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 leadership and coaching. It is not a management role.
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 be familiar with the Shu-Ha-Ri concept 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 and self-managing.
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 (for example, commitments vs. velocity) does not help.
Scrum doesn’t elaborate on the process that enables a product owner to add valuable, usable, and feasible user stories to the product backlog. Product discovery using the Design Thinking, Lean Startup, or Lean UX methodologies may help, but in any case, a good scrum master will want the scrum team to be a part of this process (whether 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 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:

Estimation and backlog refinement 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 and 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 department.
There are two essential ingredients for good scrum team performance:a) Writing user stories as a team: When something 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 corresponding and 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 defining the ‘what’), and a shared sense of ownership among team members.b) Sharing a ‘definition of ready’: To ensure a flow of well-drafted user stories for the development process, the scrum team, and the product owner should consider agreeing on a definition of ready for these user stories. This definition is an agreement about what needs to be provided for a user story to be considered ready for estimation. If one of the defined requirements is not met, a user story isn’t ready for estimation. A user story without a previous estimation is an unknown entity and, therefore, not ready to be made part of a sprint backlog because a scrum team can’t commit to an unknown entity in a sprint. Consequently, the scrum team must learn to say ‘No’. (However, beware of utilizing the definition of ready as a kind of stage-gate process. That constitutes an anti-pattern.)
A well-refined product backlog probably has user stories detailed for about two or three sprints, and probably less than half of these stories conform to the scrum team’s definition of ready. There may also be additional user stories that no one except the product owner is working on.

Download The Scrum Anti-Patterns Guide

This ebook covers over 150 Scrum anti-patterns, and it is available for free right here. Download the “The Scrum Anti-Patters Guide” now!

The download is available as a PDF delivered to your email address. Please note that downloading this content will also subscribe you to our popular, professionally-curated weekly ‘Food for Agile Thought’ newsletter if you aren’t already subscribed. (You may, of course, unsubscribe at any time.)

We respect your privacy

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 in a product backlog to the scrum team during sprint planning. The team would then turn these into more detailed user stories, and estimate the subsequent stories. There is now, however, a consensus among agile practitioners that working on these high-level user stories in separate backlog refinement and estimation meetings — before sprint planning — improves the quality of the stories and thus the outcome of the team’s work.
Sprint planning shall create a sense of ownership among a scrum team’s members by enabling them to make a valid commitment to the items in the sprint backlog. However, this only happens if a scrum team’s uncertainty about the quality of the user stories they’re receiving is eliminated. To relieve the scrum team from this uncertainty, a scrum master should support the product owner in running weekly product backlog refinement and estimation sessions, only allowing into sprint planning those user stories that meet the team’s definition of ready standard.
Sprint planning should normally be divided into two parts: a) Sprint planning I: During the first part of sprint planning, a product owner presents to the scrum team the product owner’s choice of the most valuable user stories from the product backlog as a ranked list. The team then selects from the top of the list down those stories it can commit to delivering by the end of the sprint — taking into consideration their present constraints including, for example, available capacity, or the required technical tasks such as refactoring that need to be addressed during the same sprint.b) Sprint planning II: During the second part of sprint planning, the scrum team adds detail to the user stories in the sprint backlog (e.g., splitting the stories into tasks, identifying parts of the stories that need further clarification, and agreeing on who will be working on what tasks). The product owner does not necessarily need to participate in this second part of sprint planning but does need to be available to answer questions that the team may have.
If user story preparation is handled well, an entire sprint planning session might be completed within less than two or three hours.
Productive sprint planning meetings require a healthy scrum team. Dysfunctional teams will not achieve the level of cooperation required. A 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 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.
Bugs, refactoring, and technical research require regular attention to avoid building-up technical debt. An effective scrum team allocates at least 25% of their capacity to these tasks.
Incomplete and poorly prepared user stories seriously hamper the effectiveness of a scrum team. These stories should never be selected for the sprint backlog, but instead sorted out during product backlog refinement and estimation meetings.

Please click the “clapping hands” 👏**, if you found this post useful–it would mean a lot to me!**

Standups

The fourth set of the scrum master theses addresses standups:

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.

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 regularly be changed. 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:a) Setting the stage,b) Gathering data,c) Generating insights,d) Deciding what to do,e) Closing the retrospective.
A retrospective should set SMART goals for action items (the tasks to be done):a) Action items should be specific and measurable (“do X more often” does not meet that criteria),b) A single member of the scrum team should be made responsible for each action item,c) Each action item should include an estimate of when results can be expected,d) 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 for 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:a) Agile practitioners strive for autonomy, mastery, and purpose as explained by Daniel Pink.b) 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:a) Qualitative metrics typically reveal more than quantitative metrics when applied to the scrum team.b) 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:a) Making the organization more efficient;b) Helping the organization deliver faster; andc) Improving the predictability of delivery dates.
The recognized benefits of transitioning to scrum and other agile practices are:a) Outperforming competitors by creating a learning organization;b) Creating a great workplace culture by providing room for autonomy, mastery, and purpose; andc) 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
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, organizing scrum ceremonies is just a small part of a scrum master’s job.

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

The Scrum Master Theses — Related Posts

The Scrum Master Salary Report 2017

Download the ’Scrum Anti-Patterns Guide’ for Free

Please click the “clapping hands” 👏**, if you found this post useful–it would mean a lot to me!**

Do you want to read more like this? Well:

📰 Join 11,512 peers and sign-up for this weekly newsletter
🐦 Follow me on Twitter and subscribe to my blog Age of Product
💬 Alternatively, join 1,675-plus peers of the Slack team “Hands-on Agile” for free…