The Scrum Core as Patterns

We can describe Scrum in terms of its two large-scale structures: the organization that builds a product, and the Value Stream along which the product flows. Each of these is a Whole, a designed thing in its own right. A pattern language guides as as we build such a Whole a step at a time. This book presents two pattern languages that provide expert and proven guidance as you build your Scrum.

Scrum is a game we play. Poorly played, it is a game that our team or our company tries to win. In the larger scheme of things, Scrum is a game where our firm and our competitors may take turns in the lead as each one innovates new features, paths to market, or other items that add value to society. We try not to overplay the game metaphor but it does recur now and again as a useful touchstone. The very first pattern, The Spirit of the Game, stands at the head of each pattern language. It sets the stage for the remaining patterns and, more fundamentally, for how we hope you view and use this book. A good pattern stands on its own, and we’ll let the pattern explain itself.

The Spirit of the Game

The Core Patterns in Brief

Scrum is based on three roles, five events, and three artifacts. At a higher level, a company looks at Scrum as a way to structure the work force, as well as a way to organize how work flows through that organizational structure. We have structured much of this book around these two ways of looking at Scrum in the large. The roles, events and artifacts are patterns that contribute to one or the other, or both, of these larger structures. In fact, it is a bit artificial to separate Scrum into these two parts: Scrum is a quite simple, integrated worldview. However, to some degree, the organizational concerns belong with each other and reinforce each other, as do the process concerns, so it is easier for you to grasp the whole if the book can help you first grasp these two focused concerns.

But before we dive more deeply into Scrum, here we present it in a nutshell, as a single whole, perhaps in the simplest possible terms. The core of Scrum stands on the following twelve patterns. We will of course dive into each of these in more depth, each in its own turn—and many “smallerˮ patterns that refine them and help tie them together.

There are three roles in Scrum:

Each one of these is both the name of a role, and a pattern that describes that role. We use pattern names the same way in the text ahead for the events and artifacts of Scrum. These roles work together in a product team called a Scrum Team. They interact with each other in five main events:

Underlying the framework are three artifacts:

Each one of these is a pattern: something that the organization builds to add to or refine either the organization or its development process. What we “buildˮ may take the shape of a role or of a temporary gathering of people or of a list of items or the product itself—any fruit of human innovation and design.

As an organization introduces Scrum, it might introduce these elements one at a time, as is the usual practice for patterns. The roadmap for introducing patterns one at a time is called a sequence. Here is a typical or canonical sequence by which these patterns fit together to introduce Scrum in a development effort. This is probably the minimal set of patterns which together could be called Scrum.

§ 7 Scrum Team

The Scrum Team emerges from the broader organization: a Collocated, Cross-Functional Team that operates as a small business within the context of the organization, making independent decisions to respond to stakeholders and the market. The first member of the Scrum Team is usually the...

§ 11 Product Owner

... who leads the newly formed team to realize his or her Vision to create value. The Product Owner is the single person accountable to realize the Vision, to create value through that Vision, and to concretely communicate the vision through the Product Backlog. The Product Owner is the voice of value to the rest of the Scrum Team.

§ 14 Development Team

The Product Owner hires a team to implement the product as a series of Product Increments, to realize the Vision. The Development Team is a team within the Scrum Team.

§ 19 ScrumMaster

The Scrum Team identifies (chooses or hires) a ScrumMaster as the team’s “servant leader” to guide them in the Scrum process, and in continuous improvement.

§ 54 Product Backlog

Foresight, experience, and circumstances guide decisions about what to build and deliver now, next week, and next month. The Product Owner builds an ordered list of Product Increments called the Product Backlog, based on today’s best guess of business conditions. The Product Backlog makes the likely trajectory of long-term delivery visible to all stakeholders. The Product Owner builds the initial Product Backlog and leads the Scrum Team to update its content over subsequent iterations.

§ 46 Sprint

The team starts its first iteration, called a Sprint, to plan and develop a Product Increment. Sprints have a consistent length of typically one, two, or four work weeks, establishing a fixed cadence of work, delivery, review, and process improvement done together.

§ 24 Sprint Planning

The Scrum Team—the Product Owner, Development Team, and the ScrumMaster—assembles to plan the development part of the Sprint, to build a potentially releasable Product Increment.

§ 72 Sprint Backlog

The Development Team plans how it will achieve the Sprint's objective, called the Sprint Goal, and how they will develop the Product Backlog Items to deliver the Product Increment. The Developers create a work plan called a Sprint Backlog.

§ 29 Daily Scrum

Once development starts in the Sprint, the Development Team assembles every day in an event called the Daily Scrum to adjust their work plan to optimize their chances of meeting the Sprint Goal and of delivering the Product Backlog Items they forecast that they would deliver.

§ 35 Sprint Review

At the end of the Sprint, development stops, and the Scrum Team together evaluates progress on the product. The Product Owner decides what changes to incorporate into the imminent release.

§ 85 Regular Product Increment

Approved Product Backlog Items compose into a cohesive Product Increment which the Product Owner may choose to make available for use by stakeholders. The items in the Product Increment must comply to a predefined Definition of Done.

§ 36 Sprint Retrospective

As the last gathering of the Sprint, the Scrum Team assembles to contemplate how best to make incremental process improvements, and commits to make one such improvement during the next Sprint.