There has been a “buzz” going on for a while about the last update of the Scrum Guide, announced back in November 2020.
If you happen to be involved or simply interested in Scrum and Agile in general, it is probable that you will gain value from reading the Scrum Guide, at least once (more).
The Scrum Guide
Remembering the first time I read it, before starting to work with Scrum, it felt that the text was so full of information that I definitely needed to go through it again to be able to process and absorb it; or as much of it as I could at the time.
Reading it again this year, after having worked for a few years in and with Scrum Teams,
I felt that the text is so meaningful that I definitely need to share it with my colleagues and friends.
Hence, I am going to write here what I would like to call “the sweet points” of the Scrum Guide, taken just as they are published in it.
Hopefully, these will sweeten you a bit too; meaning that they will somehow make sense and trigger your curiosity to deep dive into Scrum and the Scrum Guide.
#Scrum Definition
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
- A Product Owner orders the work for a complex problem into a Product Backlog.
- The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
- The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
- Repeat
#Scrum Theory
Scrum is founded on empiricism and lean thinking.
Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
Lean thinking reduces waste and focuses on the essentials.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk.
#Scrum Pillars
1. Transparency
The emergent process and work must be visible to those performing the work as well as those receiving the work.
…low transparency can lead to decisions that diminish value and increase risk.
2. Inspection
Transparency enables inspection. Inspection without transparency is misleading and wasteful.
3. Adaptation
Inspection enables adaptation. Inspection without adaptation is considered pointless.
If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted.
The adjustment must happen as soon as possible to minimize further deviation.
#Scrum Values
- Commitment,
- Focus,
- Openness,
- Respect, and
- Courage
#Scrum Team
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.
Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals; they focus on one objective at a time, the Product Goal.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
They are also self-managing, meaning they internally decide who does what, when, and how.
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development; and anything else that might be required.
They are structured — and empowered — by the organization to manage their own work.
#Developers
Developers are always accountable for:
- Creating a plan for the Sprint, the Sprint Backlog;
- Instilling quality by adhering to a Definition of Done;
- Adapting their plan each day toward the Sprint Goal; and,
- Holding each other accountable as professionals.
#Product Owner
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
The Product Owner is also accountable for effective Product Backlog management, which includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.
#Scrum Master
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
#Scrum Master service to the Scrum Team
The Scrum Master serves the Scrum Team in several ways, including:
- Coaching the team members in self-management and cross-functionality;
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
- Causing the removal of impediments to the Scrum Team’s progress; and,
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
#Scrum Master service to the Product Owner
The Scrum Master serves the Product Owner in several ways, including:
- Helping find techniques for effective Product Goal definition and Product Backlog management;
- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- Aiding the establishment of empirical product planning for a complex environment; and,
- Facilitating stakeholder collaboration as requested or needed.
#Scrum Master service to the Organization
The Scrum Master serves the organization in several ways, including:
- Leading, training, and coaching the organization in its Scrum adoption;
- Planning and advising Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
- Removing barriers between stakeholders and Scrum Teams.
#Daily Scrum
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.
If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal; and produces an actionable plan for the upcoming day of work. This creates focus and improves self-management.
#Sprint Review
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint; and what has changed in their environment. Based on this information, attendees collaborate on what to do next.
The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
#Sprint Retrospective
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.
The Scrum Team identifies the most helpful changes to improve its effectiveness.
The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
#Closure
I consider it rare to find a text that describes in such an open and sensible way what one actually has experienced.
Having worked on applying Scrum and learning from those attempts (mainly gained from my mistakes of not actually doing Scrum to be honest), I find that Scrum Guide is one of these texts. It involves these experiences, and it keeps doing so as it evolves.
Hence, if you are just starting with it, keep in mind that the Scrum Guide is a big batch of highly-refined experiences of more than one professionals; they’re packed in only a few pages and described in an abstract way. As you work with Scrum, these experiences will unravel in front of you; as they do in front of most of us who are already trying. Think big, start small, and it won’t be long before it starts to make sense.
