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’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:

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.

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.

The fourth edition of 2018 is now spanning seven topical categories, just a few of these questions will give you more than enough material for an engaging 60-minute conversation!

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.

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:

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.

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 all 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.

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 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 a making 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 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:

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

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

Published by

Stefan Wolpers

Stefan — based in Berlin, Germany — has been working for 12+ years as agile coach, ScrumMaster and Product Owner. He is an XSCALE Alliance XBA Coach (XBAC) as well as a member of Scrum Alliance (CSP, CSPO, CSM). He is also a certified LeSS practitioner (CLP). He has developed B2C as well as B2B software, mainly for startups, including a former Google subsidiary.

6 thoughts on “70 Scrum Master Theses”

I also think, “Being a scrum master does not entail, and should never entail, enforcing processes.” has to be further specified.

I – as SM – don’t put any value on “enforcing processes”. I don’t think I could do my job as coach/mentor, when the team thinks of me as some kind of Scrum Guardian. Also when aiming for management I would have chosen a different job – but to organization who puts the SM in place has expectations about the process.

(Really) self-organized teams could very quickly modify every aspect of scrum when not slowed down by anyone.

Exaggeration:
SM: “…then it’s not scrum”
DevTeam: “Why?”
SM: “…uhm…trademarks?”
DevTeam: “Daily Situps for the PO, Planning Poker becomes just Poker, Aggrospectives and the testers have to go. Plus: We’ll still call it scrum – sue us.”
And – the other way round:
PM: “…and I want this to be finished on friday.”
SM: “Sorry, we had a planning where this wasn’t mentioned. It’s not a small effort either, and according to scr…”
PM: “I was talking to the people who actually develop something. Go fetch the scrum police should you oppose.”

@1: That is the usual approach. To my experience, with most teams, it will work out in the end. However, some people are not willing to embrace agile practices, and they will let you know in the process. I believe that even in this case, a scrum master shall not enforce processes even if that means that the team in question in its current composition may not adapt Scrum.

@2: If the team is in control that approach might work. If the problem is a result of the organizational structure, the team will have little influence on that in the short term.

“A scrum master shouldn’t enforce, but instead demonstrate the value of upholding the empirical process control of transparency, inspection, and adaptation”.

What are your thoughts on this?

Then on: “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.”

This is often indeed the case. In my view, Scrum teams should strive to being more cross-functional in such scenario, ie. steps towards making it an integrated whole, to be able to deliver working increments. The team can list certain dependencies as DoRs and the Scrum Master could strive to resolve dependencies if they become an impediment. Given this thesis, I am wondering what stance a Scrum Team could take (according to you).