70 Scrum Master Theses, Part 1
70 Scrum Master Theses, Part 1
In the Scrum Master Theses, you'll learn A LOT about being a Scrum Master from an Agile thought leader. In this article, we cover Sprint Planning and Product Backlogs.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
Editor's Note: The original article was divided into two parts due to its length. Tune back in for Part 2!
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 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 (e.g. 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 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. But 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 needs 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 requires 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.
Published at DZone with permission of Stefan Wolpers , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.