Understanding Scrum

The Two Scrum 3–5–3s

Within the context of helping teams get started with Scrum, I have sometimes employed a construct that many practitioners know as the Scrum 3–5–3, where the first “3” references what have historically been known as three Scrum roles, the “5” references five Scrum events, and the final “3” references 3 Scrum artifacts, as articulated in the Scrum Guide. I’m extending this notion to include a second 3–5–3: another “3” to represent the 3 pillars of Scrum; another “5” to represent the Scrum values; and one more “3” to represent commitments which were formally articulated in the November 2020 update to the Scrum Guide. I’ll start with the 3–5–3 that I’ve added, then cover the original 3–5–3:

• 3 Scrum pillars
• 5 Scrum values
• 3 Scrum commitments
• 3 Scrum artifacts
• 5 Scrum events
• 3 Scrum roles (accountabilities)

Scrum Pillars

The three pillars of Scrum are:

• Transparency
• Inspection
• Adaptation

Transparency

Transparency is vital among the members of a Scrum Team and with the team’s stakeholders. Scrum’s Artifacts help ensure that there is transparency about the work that the team is doing, and how that work supports the improvement of the product.

Artifacts that have low transparency can lead to decisions that diminish value and increase risk. Transparency enables inspection. Inspection without transparency is misleading and wasteful.

Inspection

Through consistent inspection of Scrum’s Artifacts, on a regular cadence, via Scrum’s Events, it’s possible to make deductions about progress toward goals, and the extent to which progress is in line with expectations.

To help with inspection, Scrum provides cadence in the form of its five events. Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.

Adaptation

Scrum Teams learn more via every Sprint, both by discovering more about the product and customers’ expectations, and about how they can most effectively work with each other. In Scrum, adaptation means applying what teams have learned.

Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.

Scrum Values

The five Scrum values are:

• Commitment
• Focus
• Openness
• Respect
• Courage

Based on my experience, any team that does not model these values is unlikely to get much benefit from Scrum. Indeed, teams that lose sight of the values are likely employing a cookie-cutter approach to Scrum where they go through the motions of adopting some practices but really don’t change how they’re working in any meaningful way. Let’s touch on each of these values one by one.

Commitment

The Scrum Team commits to achieving its goals and to supporting each other.

The notion of commitment is directly linked with the three commitments that I describe in the next section. Notice how the importance of supporting each other is given equal weight with goal achievement. Also, it’s important for us to be careful to avoid traps associated with the term “commitment,” which have persisted for years, as I write about in The Difference between a Forecast and a Commitment.

Focus

Their primary focus is on the work of the Sprint to make the best possible progress toward these goals.

Making tangible, meaningful progress toward goal achievement has a lot to do with being able to stay in a state of flow, and is one of the many reasons that Scrum teams employ Kanban practices such as making work visible and Work-In-Progress (WIP) limits. See my blog post Improving Flow for additional insights.

Openness

The Scrum Team and its stakeholders are open about the work and the challenges.

If I were to be invited to observe a Scrum team’s Sprint Retrospective, where I’ve never worked with the team before, within the first five minutes of the retrospective, it becomes apparent to me whether the team has the transparency and trust that enable success over the medium to long term. For more about openness and trust, see what I wrote about the Trust-Ownership Model (based on a book of the same name by Polyanna Pixton, Paul Gibson & Neil Nickolaise), along with the usage of a Team Canvas.

Respect

Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work.

Arethra Franklin expressed it better than anybody else has when it comes to having r-e-s-p-e-c-t for one another. This sense of respect needs to flow freely not only among the members of an individual team, but also across teams, and from the leadership level.

Courage

The Scrum Team members have the courage to do the right thing, to work on tough problems.

The Cowardly Lion waxed eloquent about courage in the Wizard of Oz, and courage is indeed an important value for Scrum team members to demonstrate. Courage can take many forms, from speaking one’s mind when a team is about to make a choice that feels inconsistent with the team’s values or goals, to making the case to management that inattention to technical debt is making it increasingly difficult for the team to obtain its objectives.

To sum up, this is the concluding paragraph from the Scrum Guide about values:

These values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them. The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts. When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.

Scrum Commitments

The three Scrum commitments are:

- For the Product Backlog it is the Product Goal

- For the Sprint Backlog it is the Sprint Goal

- For the Increment it is the Definition of Done

One reason I’m devoting a separate category to the commitments is that unlike the pillars, values, events, artifacts, and roles, the commitments hide in relative obscurity, since there is no heading calling them out separately in the Scrum Guide. Another reason I’m choosing to give them emphasis is that they anchor the three Scrum artifacts to the three Scrum roles. Let’s touch on each of the commitments.

Product Goal

The Product Goal was just introduced in the most recent Scrum Guide update:

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal…The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

It seems to me that the addition of the Product Goal has a lot to do with the fact that there has always been a tacit understanding that it’s important for Scrum teams to articulate a high level vision or goal (what some people might call a North Star). Further, I think the notion of a Product Goal helps solidify the importance for the team to be able to succinctly articulate what they seek to achieve, ideally including a measure that helps them be able to demonstrate that they did in fact achieve the Product Goal.

Sprint Goal

Just as the Product Goal is the commitment for the Product Backlog artifact, the Sprint Goal is the commitment from the perspective of the Sprint Backlog.

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

A key thing for us to keep in mind when it comes to the Sprint Goal is that achievement of a business-centric and realistic goal for a Sprint places the emphasis where it belongs, on achieving a particular business outcome — not on hitting a target Velocity.

Definition of Done

The Definition of Done is the commitment associated with the Increment.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product…

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

In previous versions of the Scrum Guide, one could get the impression that even though the Definition of Done was part of Scrum, the way that it was articulated made it feel a bit like a “bolt-on;” as in, here’s something (else) that’s important that you need to pay attention to. Articulating the DoD as an accountability at the Increment level gives the DoD added importance, in that it sends a stronger signal to the team, and to stakeholders, that the team takes seriously the importance of delivering a working solution that is free of quality problems and meets a baseline set of expectations.

Scrum Artifacts

The three Scrum artifacts are:

• Product Backlog
• Sprint Backlog
• Increment

Product Backlog

The Product Backlog includes potential work items (user stories) at varying levels of granularity and refinement. Items at or near the top of the Product Backlog have the highest business value, and hence the highest priority, and it is these items that the team focuses on fully elaborating before and during Sprint Planning.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

Note: The Product Backlog is not intended to be an all-you-can-eat buffet, but rather, a selection of the most desirable things that could be on the menu, based on customer feedback. When a Product Backlog gets to be hundreds of items deep, it increases the likelihood that we can’t see the forest for the trees.

Sprint Backlog

The user stories selected for inclusion in the Sprint Backlog are the result of team collaboration on how much work they can complete, in pursuit of a Sprint Goal that realistically reflects their capacity:

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

Note: One of the most common mistakes I see teams make is selecting too much work for a Sprint, which has numerous potential negative consequences, including a higher amount of simultaneous Work-In-Progress (WIP), a higher likelihood that there will be unfinished work at the end of the Sprint, and a negative impact on team morale. I cannot overstate how important it is for teams to feel empowered to select just enough high-priority work items that they feel reasonably confident that they can complete.

Increment

An Increment represents a moment in time when one or more units of value are available to customer(s), helping them achieve one or more of their business goals:

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Work cannot be considered part of an Increment unless it meets the Definition of Done.

Note: Technical practices such as Continuous Integration and Continuous Delivery (CI/CD) are must-haves when it comes to enabling teams to release functionality early and often. The book Accelerate — The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, by Jez Humble, Gene Kim, and Nicole Forsgren offers a broad perspective on the types of attributes and practices that separate high-performing organizations from the rest of the pack.

Scrum Events

The five Scrum events are:

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Note: for the Scrum events, artifacts, and roles, and I’m not adding much commentary above and beyond what is in the Scrum Guide, because so much has been said and written about these aspects of Scrum.

Sprint

A Sprint in Scrum is a container for all other Scrum events:

Sprints are the heartbeat of Scrum, where ideas are turned into value.

They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.

Note: a synonym for a Sprint is an iteration. For example, eXtreme Programming (XP) uses the term iteration, rather than Sprint, which helps emphasize the iterative nature of Agile planning and delivery.

Sprint Planning

As its name implies, Sprint Planning is an opportunity for a team to collaboratively make decisions about which high-priority work items are the best candidates for inclusion during a Sprint that is about to begin:

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning focuses on three aspects:

• Why?
• What?
• How?

Where …

Why = “Topic One”

Question to answer: Why is this Sprint valuable?

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

What = “Topic Two”

Question to answer: What can be Done this Sprint?

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.

How = “Topic Three”

Question to answer: How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

Note: Many teams employ a practice called Product Backlog Refinement between Sprint Planning events, for example, around the mid-point of a Sprint. A common reason that teams supplement Sprint Planning with Refinement is to get greater clarity on business or technical questions that may require deeper conversation or checking in with people outside of the team. See also my blog post Backlog Refinement and Sprint Planning: Similarities and Differences.

Note 2: Use the “Why,” “What,” and “How” as prompts for questions to ask and topics to cover during Sprint Planning, rather than as rigid instructions to be followed.

Daily Scrum

The Daily Scrum, sometimes referred to with the synonymous term Daily Standup, is an opportunity for the Developers on a team to identify ways in which they can most effectively collaborate over the next 24-hour period:

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. 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 next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

Note: One of the most common mistakes that teams make is to treat the Daily Scrum as a status report. Another anti-pattern that sometimes emerges is where a person who’s not a member of the team hijacks the meeting. For more thoughts about Daily Scrums, including facilitation tips, see Daily Standup Patterns.

Sprint Review

There is no more important proof of the idea that “feedback is a gift” than the Sprint Review.

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

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 Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

Note: The format and duration for Sprint Reviews can different significantly from organization to organization. For instance, one important variable is whether a single team, or multiple teams, is/are participating. To sum up the purpose of a Sprint Review, it comes down to visibility and transparency, in that it’s a great opportunity to highlight the work that a team is doing, and also shine a light on challenges the team is experiences, which some stakeholders may be able to help the team address.

Sprint Retrospective

I am one of many Agile practitioners who, if asked which aspect of Scrum I consider most important, would choose the Sprint Retrospective, because it’s the engine of continuous improvement:

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. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

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.

Note: There is no better source of guidance and inspiration when it comes to Agile continuous improvement than the the book Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen. For visibility into how vast the universe of facilitation options is for retrospectives, check out this public Trello board I started many years ago.

Scrum Roles (Accountabilities)

The three Scrum roles are:

• Developers
• Product Owner
• Scrum Master

Together, the Developers, the Product Owner, and the Scrum Master constitute a single Scrum Team.

Note: The Scrum Guide used the term “roles” in previous revisions; in the most recent update, the term “accountabilities” is the closest equivalent.

Developers

The Developers include any member of the team who is actively involved with producing business value:

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the 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.

Note: The skills of the Developers on a team are as diverse as the range of products that teams can potentially work on. Arguably the simplest way for us to conceptualize who needs to be a member of a team as a Developer is to remember that for a team to be viable, it must have “everyone and everything it needs” to produce value, without relying heavily on people external to the team.

Product Owner

The Product Owner (PO) is a person who has a high level of mastery about the product, and about current and/or potential customers for that product:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

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.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner

Note: It is assumed that the PO, and/or another person who has a solid understanding of, and connection with, stakeholders, is available to the Scrum Team on a regular basis. In the absence of a person with strong product awareness, the likelihood of committing the cardinal sin of “building the wrong thing” increases.

Scrum Master

It is common for Scrum Masters to wear many hats, and arguably the most important hat for a Scrum Master is that of a coach or facilitator:

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.

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

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.

Another dynamic that tends to stand out on successful Scrum Teams is evidence of an effective partnership between the Product Owner and the Scrum Master:

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;

- Helping establish empirical product planning for a complex environment; and,

- Facilitating stakeholder collaboration as requested or needed.

A third area in which Scrum Masters can be involved, to varying degrees, has to do with things like cross-team coordination and improvement, and in some cases, organizational improvement:

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.

Note: The extent to which an individual Scrum Master serves the organization has a lot to do with factors such as organizational size and how much experience the Scrum Master has.