The Scrum Core as Patterns

Scrum is based on three roles, five events, and three artifacts. Each one of these contributes to some part of the structure of Scrum: of either its organization and the relationships between people connected to a Scrum product development organization, or of its process, including the dynamic groupings of selected roles that keep the process moving forward at its cadence. We’ll talk later about these two larger ways of looking at Scrum structure. We can think of the roles, events and artifacts as patterns that contribute to one or the other, or both, of these larger structures. So, from a pattern perspective, here is Scrum in a nutshell. 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:

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 process.

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 bring Scrum to 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 primary organization of people: a Collocated, Cross-Functional Team that operates as a small business within the context of the organization, making independent decisions to respond to using stakeholders and the market. The first member of the Scrum Team is usually the...

§ 11  Product Owner  ... who leads the nascent team, to realize his or her vision to achieve value. The Product Owner is the single person who takes accountability for realization of the Vision, the value that emanates from the delivery of that Vision, and for 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  A ScrumMaster is selected (often hired by the Scrum Team) as the team’s “servant leader” to guide them in the use of the Scrum process, and in continuous improvement.

§ 54  Product Backlog  Foresight, experience, and circumstances lend insight on what the best decisions might be at imminent forks in the product roadmap (which may be written or just in the mind of the Product Owner), and a vision of a specific path through the roadmap emerges to add value at every step, based on today’s best guess of business conditions. The Product Backlog makes the current likely trajectory of long-term delivery visible to all stakeholders. The Product Owner builds the initial Product Backlog and leads the updating of 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 in duration, 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 develop the Product Backlog Items that will allow them to deliver the Product Increment. To achieve these ends 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 replan their work and 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 should be incorporated 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 one such improvement during the next Sprint.