We can describe Scrum in terms of three roles, five events, and three artifacts. In this book we view each of these, as well as many more fine-grained elements of Scrum, as patterns—solutions to organizational, process, and business problems. At a higher level, an organization views Scrum as a way to structure the workforce, 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 will likely be 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 these twelve patterns. We will of course dive into each of these in more depth, each in its own turn—as well as many smaller patterns that refine them and help tie them together.
We can succinctly define Scrum in terms of its roles, its events, and its artifacts. We start with a list that defines terms for Scrum’s roles. Each term is both an ordinary word phrase describing the role, and also the name of a pattern describing the role. The terms for events and artifacts work the same way. There are three roles in Scrum:
the Product Owner, who owns the vision of the product direction and its rollout;
the Developer, which builds product increments to the Product Owner’s specification; and
the ScrumMaster, who owns the process and leads incremental improvement efforts.
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 in a product team called a Scrum Team. They interact with each other in five main events:
the Sprint, a time-boxed interval that is typically two weeks long and sets development cadence;
Sprint Planning, an event where stakeholders (mainly the Scrum Team members) together plan upcoming development, focusing on the work ahead of them in the current Sprint;
the Daily Scrum, an event at which the Development Team adjusts the Sprint plan, focusing on the next 24 hours;
the Sprint Review, an event where stakeholders overview the product status; and
the Sprint Retrospective, where the Scrum Team members assess how the process is working for them.
Underlying the framework are three artifacts:
the Product Backlog, which the Scrum Team uses to plan upcoming deliveries;
the Sprint Backlog, which the Development Team uses as its work plan for the current Sprint; and
the Product Increment, which the team delivers to end users.
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 or culture. It is both a Collocated Team and a Cross-Functional Team that operates as a small business, 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 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. (By ‟hireˮ we mean to associate a committed group to the effort, whether in the formal sense of employment for wages or through some other form of organizational commitment.) The Development Team is a team within the Scrum Team.
§ 19 ScrumMaster.
The Scrum Team identifies (chooses or hires, as previously described) 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 estimate 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 refine, break down, and 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 workweeks, 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 it will develop the Product Backlog Items to deliver the Product Increment. The Development Team creates 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 its 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.
Product Backlog Items that the Product Owner has decided to incorporate 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.