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 these 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:
Together 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 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 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 two to 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.