The Scrum Guide Explained A Comprehensive Analysis of the Scrum Guide [Kindle Edition] 9783540760962, 9780735619937, 9780140249071, 9780932633446, 9781118206669, 9780141186856, 9781847941107

Citation preview

The Scrum Guide

Explained

A Comprehensive Analysis of the Scrum Guide

Moritz Knueppel

••

a

To those who have shaped my path in Scrum

Dr. Peter Stormer my first boss after college, who encouraged me to pursue the Scrum Master path

Sumeet Madan the PST who taught me about Product Ownership and helped me in my pursuit of PSM- III

Sofia Katsaouni my girlfriend and fellow Scrum Master, who has helped my writing of this books with countless discussions during walks by the lake

Self -published in September 2020 First edition Moritz Knueppel Hermannstal 89 22119 Hamburg, DE scrumquide@moritz-knueppel . eu

Copyright © Moritz Knueppel 2020

Contents Preface

v

1 Purpose of the Scrum Guide

1

2 Definition of Scrum

§

3 Uses of Scrum

18

4 Scrum Theory 4.1 Transparency 4.2 Inspection . 4.3 Adaptation .

24 29

32

26

5 Scrum Values

39

6 The Scrum Team 6.1 The Product Owner . . 6.2 The Development Team 6.3 The Scrum Master . .

53 62

7 Scrum Events 7.1 The Sprint . . . . 7.2 Sprint Planning . . 7.3 Daily Scrum . . . 7.4 Sprint Review . . . 7.5 Sprint Retrospective

Z2 8J

1QZ 112 123

122

m

158

8 Scrum Artifacts 8.1 Product Backlog 8.2 Sprint Backlog 8.3 Increment . . .

165

167

1SZ 125

9 Artifact Transparency 9.1 Definition of "Done”

122

10 Endnotes

207

11 Acknolwedgements

209 209 209

11.1 People 11.2 History

.... ....

202

License of the Scrum Guide

211

Postface

212

Bibliography

213

List of Figures

214

Preface

v

Preface Scrum is simple to understand but difficult to master.

This paraphrased statement from the Scrum Guide holds a special meaning for me. When first I came into contact with Scrum. I read the Scrum Guide a few times and thought I had understood all there was to understand, that I would now know all there was to know. Glossing over the Scrum Guide, I accepted it as "one way to do things”, not questioning any meaning behind it. My modus operandi was hence all too often "this is how it would be done by the books, but it doesn ' t really work for us. so we will do it differently ". As I moved around different companies and got to observe Scrum in practice in many Scrum Teams, from small teams of a handful of people to scaled environments with several dozen developers, deviation from the principles laid out by the Scrum Guide appeared to be the norm rather than the exception to it. Other Scrum Masters I would work with didn' t seem to see this as problematic either. But as I saw more and learned more, I began to question the validity of my existing knowledge, or - as I would come to realize - significant lack thereof . I decided for this to change and set out to understand Scrum more appropriately. This book represents my attempt to explore the Scrum Guide in-depth to understand what this truly means. It is an attempt to inspect the delicate balance between rules, roles, events, values and artifacts the Scrum Guide describes. Most of all. it is my attempt to understand not only WHAT the Scrum Guide says, but WHY it says what it says.

Preface

VI

To explain the Scrum Guide, I am taking apart the entire Scrum Guide. In what grew to be over 200 pages. I am examining the Scrum Guide sentence by sentence, sometimes even word by word. I provide background information about the history of Scrum and about underlying concepts. Most of all, I am trying to explain the interconnectedness of the Scrum Guide, how the sections refer to each other, and everything in Scrum is dependent on each other . Every Scrum Guide section and, for the most part, every Critical sentence can be read individually in this book , dependencies between them, such as an explanation of Scrum related terminology and essential concepts , are marked in footnotes. Therefore, the book can be used as a reference book to look up the meaning of and ideas behind individual aspects of Scrum.

For an in-depth study of the Scrum Guide using this book , I recommend reading the entire Scrum Guide and then working through this book back to back . While this book is not explicitly intended as study material for any Scrum examinations, I believe that it can certainly help you prepare for exams that require not only a superficial but a more thorough understanding of Scrum.

I sincerely hope this book can be of help to anybody who is seeking to understand Scrum more thoroughly. I hope it helps them gain a more in-depth insight into this genuinely ingenious framework. I wish for this book to be a valuable contribution to the ever-growing Scrum Community.

1 Purpose of the Scrum Guide

1

1 Purpose of the Scrum Guide Scrum is a framework for developing, delivering, and sustaining complex products.

The first sentence of the Scrum Guide is only 11 words long; however, it contains an essence of what Scrum is and is not , what it is for. and even what understanding it has of product development. This sentence can be broken down into three key components: 1. The term " framework " outlines that Scrum does not have a handbook for every given situation and does not claim to have the solution to every single challenge arising in product development . Rather, it provides a set of rules within which the people involved are free to operate with

the tools, methods, and techniques they deem appropriate . Scrum provides a frame to work within, hence the term " framework”.

2. The trifold of " developing , delivering , and sustaining" products lays out the understanding of the product development lifecycle: Scrum acknowledges that software is not simply shipped when it is finished and left to the customer to use, but rather there ought to be an ongoing process of development in collaboration with the customer, continually adjusting the product to the needs of the market.

1 Purpose ol the Scrum Guide

2

3. When speaking of " complex products " , the Scrum guide makes two implicit claims:

a) There are situations in which using Scrum is appropriate. When developing a product that is complex , especially in environments that are complex . Scrum is indeed capable of providing a framework with which to address the challenge of complexity. t

Example: The development of an intricate mobile application with a team of six developers over the course of a year may warrant the use of Scrum. b) Conversely, there are situations for which Scrum is not appropriate, namely when the product in development is not complex . While Scrum is a lightweight framework, it nonetheless creates overhead by defining roles, events , roles and what it calls artifacts. This overhead may not be justified if the product development at hand is simple . Example: setting up a simple website with two people in a few days may not warrant the use of Scrum.

This Guide contains the definition of Scrum. This definition consists of Scrum 's roles, events, artifacts, and the rules that bind them together.

Unlike some other project management methodologies or frameworks. Scrum has a clear definition of what it is and what it is not. leaving no room for subjective interpretations or variations while still operating under the title of "Scrum”.

The Scrum Guide is not descriptive in nature, meaning it does not try to describe an already existing real- world practice by abstracting models from it, but rather it is prescriptive, meaning

' see explanation ol complexity in the Cynefin Framework on pages 7H,

1 Purpose of the Scrum Guide

3

that by definition, what is written in the Scrum Guide and it alone serves as the definitive source.

The Guide defines the roles, events, artifacts and rules which constitute Scrum . In practice, there are often deviations on one or more of these - often called "ScrumButs" deriving from the expression "we do Scrum, but . . . " followed by an outline of the deviation. By definition, these approaches are not Scrum, as they violate the prescriptive definitions outlined in the Scrum Guide. Only what adheres to the definitions laid out in the Scrum Guide is truly Scrum.

1 Purpose ol the Scrum Guide

4

Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.

Some approaches to product development gradually emerged as a wide set of practices. Scrum however, was explicitly defined by Ken Schwaber and Jeff Sutherland. Both developed approaches in their respective companies that would lay the foundation for the modern Scrum. In 1995 they joined forces and integrated their ideas into a framework that is known today as Scrum. Since then, it has been further improved multiple times, most recently in the 2017 update to the Scrum Guide. ,

Figure 1.1; Jeff Sutherland ( left ) and Ken Schwaber (right )

In 2002 , Schwaber, together with others, founded the Scrum Alliance" and launched the Certified Scrum accreditations to spread Scrum. ;

hnps /www 5crumaHiar>ceora/

^

1 Purpose of the Scrum Guide

5

In 2009, he left over differences - mainly regarding the standardization of the curriculum - and created Scrum .org3 , which now oversees the Professional Scrum accreditations. Parallel to this, Sutherland set up a company called Scrum Inc. 4 offering consulting and training on Scrum, setting up the Licensed Scrum accreditations.

These two sentences in the Scrum Guide can be seen as a commitment to further cooperation in developing Scrum. It further outlines that no organization owns the definition of what Scrum is. but that instead , that definition is up to the Scrum Guide , which is jointly maintained by Schwaber and Sutherland.

3

httos 7/www.scrumof(V

4

hnps7Awww.scruminc .com/

2 Definition of Scrum

6

2 Definition of Scrum Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

This one sentence definition contains a highly distilled essence of Scrum and can be inspected almost word by word: The use of " Scrum (n)f [ with " (nf indicating that Scrum is a noun] mirrors a dictionary entry. This can be seen as having two purposes:

.

1 It reinforces the idea that the Scrum Guide is the definitive source, in which the one and only true Scrum is defined.

2. It clarifies the correct way of spelling Scrum, which is often written as "SCRUM *, likely because in an early paper on the subject by Ken Schwaber, the document title contained the word Scrum in all capital letters. The term "Scrum" is based on the rugby formation known as "scrummage" or "scrum” for short. As a proper noun, it is capitalized. " A framework within which... * once again indicates that Scrum does not provide a definitive methodology, but a set of definitions and rules, within which other tools, approaches and methods can be used.

The choice of "address complex [. .. ] problems" can be explained by looking at the Cynefin-Framework, which categorizes

7

2 Definition of Scrum

problems into four primary clusters: complex and chaoticMl

Complex Probe Sense

simple, complicated ,

Complicated Sense

Respond

Analyze Respond

Emergent

Good Practice

Chaotic ACt Sense

Respond

Novel

Simple Sense

Categorize

Respond

ijBest Practice

Figure 2.1: A graphic representation of the Cynefin quadrants. 1. Simple problems are ones with "known knowns”. in which the rules are clear and known, and the situation is considered stable. In situations with these problems, a defined ruleset of best practices can be followed. The advice given by the framework is "sense, categorize, respond", meaning that one observes the problem , categorizes it into existing categories and applies the standard solution for that category.

2. Complicated problems are ones where "known unknowns" exist, meaning there is awareness of what is not known. These are situations where experts can be consulted, and conducting deeper research can lead to solving the problems. Good practices may be identified based on the analysis conducted. The frameworks advice is thus similar

2 Definition of Scrum

8

to that for simple problems but replaces "categorize" with a more in-depth look .

"analyze", indicating a need for

3. Complex problems are ones in which the "unknown unknowns' dominate . The nature of cause and effect cannot be known in advance ; thus, categorization or conventional analysis will not be useful. According to the Cynefin-Framework , the proper approach is thus to "probe , sense, respond", meaning that experiments should be undertaken, of which the results can be observed, and actions can then be defined accordingly. It is impossible to plan the actions far in advance as the nature of the metaphoric playing field has yet to be discovered . 4. Chaotic problems are ones where any knowledge-based

response is not possible , and the rules of cause and effect cannot be deducted. The advice given by the framework is "act. sense , respond", which differs from complex problems

insofar that the first step is to take immediate action rather than experiment first . The goal is to take effective action as reasonable as can possibly be estimated with good judgment - and based on observations, determine a way to turn the problem from a chaotic one into a complex one. In the context of product development , those categories imply the following respective approaches; 1. Simple: inspect the problem beforehand, choose the appropriate methods and tools , implement the solution

2. Complicated; analyze the problem beforehand, choose the methods and tools that appear most appropriate, implement the solution 3. Complex: run an experiment, evaluate the result and determine the best course of action based on the insights gained

2 Definition of Scrum

9

4. Chaotic: do anything, evaluate the result, based on that determine the best course of action to turn the problem into

a complex one

The Scrum Guide states that Scrum is appropriate for complex problems, which is consistent with the ideas of the Cynefin framework: Scrum is founded on empiricism . 1 with the three pillars of "transparency" , '’inspection" and "adaptation", which are mirrored in the Cynefin framework's recommended response for complex problems: 1 . "probe " , which aims at generating data, or in other words, creating transparency

2. "sense", which describes the inspection of the generated data 3. ’respond", which means to take appropriate action based on the newly won insights, or in other words to adapt actions to the situation as it is now understood

By " address [. . . ] adaptive problems" the Scrum Guide claims that Scrum is capable of addressing problems that are not static but can change over time . While many conventional approaches to product development assume the general environment of the product during its development to not change in fundamental ways, Scrum acknowledges that the conditions of the problem may change over time.

A problem that is complex but not adaptive may be solved by conducting an experiment (probing) once, evaluating it (sensing) and executing one derived set of actions ( responding). If the problem itself changes though (adaptive problem), the derived set of actions may be outdated This can be avoided by repeating the process of probing, sensing and responding often enough to adapt to the problem, while not too often to hinder actual

see the section on empirical process control on pages 24H

2 Definition ot Scrum

10

progress in developing the solution to the problem. This is the basis lor the iterative nature of Scrum. Example: a company develops a mobile app. At the beginning of the development, it is estimated that building the entire app to fulfill the current expectations will take 24 months. Considering this as a static problem would mean to assume that in 24 months , the conditions around the app will still be the same, and development could be done with an approach like the Waterfall Model. In contrast , considering it an adaptive problem recognizes that the conditions surrounding the app may change significantly within the development period. In this example, hardware specifications could change, such as higher- resolution screens demanding other designs or the newly widespread availability of NFC in phones creating new opportunities for the app that were Alternatively, potential customers' not initially planned expectations for the app may change, as competitors may set standards with their applications. Thus, it should be considered an adaptive problem and is hence a problem for which Scrum may be a valid framework to choose due to its iterative nature. ,

Using the adjective "productively " highlights Scrum's focus on efficiency. Scrum aims to utilize the available ( human) resources efficiently. This focus can. for example, be seen by the use of time-boxes or the concept of the Daily Scrum , which aims to increase productivity by facilitating a high-density exchange aimed at synchronizing the entire team, rather than letting information spread decentralized and risking miscommunication, which would lower productivity.

The adjective ”creatively " outlines the necessary approach to solving the problems , which earlier in the sentence were outlined to be complex and adaptive. Unlike simple or complicated problems, for which best practices may already exist , complex

2 Definition of Scrum

11

problems - and complex adaptive in particular - require trying new approaches often and thus require creativity. 2

Finishing the sentence with " delivering products of the highest value" again underlines the focus on productivity, but also emphasizes that the key metric in product development with Scrum is the value delivered to the stakeholders and especially to the final users. This is a crucial factor in the Scrum mindset , especially for Product Owners: a key measure of whether Scrum is applied properly is whether every iteration aims to deliver the highest possible value product.

To illustrate: A Sprint spent on cleaning up technical debt (often called a "hardening Sprint”) could at first glance be considered a good idea. However , it is not conforming with Scrum as it does not deliver the maximum value possible to the stakeholders. When the Scrum Guide uses the term "product", this includes physical and non-physical products, as well as services of any kind.

Scrum is:

• Lightweight • Simple to understand • Difficult to master Listing these three attributes of Scrum illustrates the sharp contrast between the ease with which Scrum can be grasped due to its light setup, on the one hand, yet difficult to understand in-depth on the other . 1. Characterizing Scrum as "lightweight refers to two aspects:

2 for

a wider definition of creativity in the Scrum context and how Scrum optimizes for creativity, see pages 55fT

2 Definition of Scrum

12

a) The number of prescriptive rules and definitions Scrum forces on those who choose to apply it is relatively low. This can be powerfully illustrated by comparing the Scrum Guide, with its less than 20 pages , to the official guide for the V-Model XT, which contains more than 400 paqes. (21 b) The amount of time the events Scrum demand creates relatively little overhead. It does not demand hour-long status meetings and time-intensive written updates within the team but instead has relatively short, time-boxed, face-to- face meetings. In terms of staffing and role division, Scrum can also be considered lightweight , as it recognizes merely three roles and centers the product creation within the Scrum Team itself, instead of demanding various new levels of hierarchies with titles and complex chains of command. 2. Scrum is "simple to understand" in so far as reading the Scrum Guide a few times will get one to understand the overall concept , especially the more practical aspects , mainly the events and. to a lesser extent , the roles and the artifacts. With only a few hours of studying Scrum, it would be possible to observe a Scrum Team in action and identify many of the patterns described in the Scrum Guide.

3. While Scrum may be easy to understand, it is "difficult to master” particularly because it is lightweight. Scrum is based on a broad set of axioms about how people can work together to deliver value. It addresses these assumptions not only with explicit rules but with a foundation of values. 3 Understanding how to use the ideas of Scrum and apply them in situations not explicitly covered by the Scrum Guide in the "Spirit of Scrum” is what differentiates a novice from a master . ,

3

see chapter on Scrum Values on pages 39«.

2 Definition of Scrum

13

Reaching this stage requires arguably much practical experience , theoretical knowledge and introspection, and thus mastery of Scrum can be considered truly difficult.

Scrum is a process framework that has been used to manage work on complex products since the early 1990s.

With this, Schwaber and Sutherland define the origins of Scrum . Based on the given time, it can be assumed that they understand their initial, separate approaches to be the roots of what we now call Scrum. Rather than defining their first joint paper outlining Scrum in 1995f 3l as the birth of Scrum, they choose to include the early emergences. From this, it can be deduced that Scrum itself is not considered "finished' by the creators, that it was not placed into existence at a specific time to remain static for all times, but instead is itself a continually improved increment through updates to the Scrum Guide.

Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.

Scrum can be thought of as a container , within which those driving the development are relatively free to choose their approaches. In his book "Agile Project Management with Scrum" [ 41, Schwaber outlines in the foreword "Why Scrum Works" that a crucial aspect for the success of product development with Scrum is that it acknowledges that in complex projects decisions should best be made is by the people actually conducting the work. This sentence once again emphasizes that Scrum is not to be considered as anything beyond a framework , within which the people involved are free - and in a sense obligated - to choose other tools and paradigms according to their needs.

2 Definition of Scrum

14

The only requirement for these additions is that they must comply with the rules outlined by Scrum, including the values and ownership regulations. Thus, it is acceptable, for example, to use Test Driven Development, run Product Discoveries or utilize Kanban metrics and WIP-limits as the Scrum Team sees fit. It is on the other hand not acceptable for the management to enforce upon a Development Team the way in which they work on their Sprint Backlog via prescribing Gantt charts, as this would violate the Development Team s ownership of the Sprint Backlog. 4

Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

The introduction of Scrum in projects is often considered painful because it reveals problems in the existing product management and makes issues that are hindering better performance transparent. Scrum, with its basis on empirical control theory 5 , is based on making things transparent in order to inspect them and adapt to the situation of newly gained information. The goal of Scrum, in a way, is perpetual improvement aimed towards ever greater value delivery.

-

This is one reason why Scrum may only be adopted in its entirety, including the roles and terminology. Scrum is meant to break with conventional product and project management paradigms and allow the transparent inspection and consequent questioning of existing methods. With this sentence, the Scrum Guide further stakes the claim, that Scrum is not only aimed at improving the product but also

4

foe more on the Development Team’s ownership of the Sprint Backlog see the section on the Sprint Backlog on paoes 187 ft. 5 see the section on empirical process control on pages 24ff .

2 Definition of Scrum

15

• the team who develops the product, for example by fostering attributes such as trust by emphasizing the Scrum Values6 , and

• in a second step the working environment , later in the Guide referred to as "organization", by scaling the Scrum thinking beyond the Scrum Team into other parts of the organization; typical examples here are the sales department and the HR department

This last section of the sentence was only placed into the Guide with the latest update in 2017.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules, Each serves a within the framework purpose specific component and is essential to Scrum's success and usage.

This is often summarized by a quote from the section Endnotes7 , 'Scrum is .. . immutable", meaning that there is a carefully crafted balance between the components, which will be inspected in this book. Using only parts of Scrum may be useful - e g. , using Sprints or having standup-meetings in the fashion of the Daily Scrum - but is not Scrum. Similarly, leaving out and ignoring components that appear not to fit the business situation reduces the potential positive effects that Scrum may bring. A typical real- world example for this is adopting most ideas from the Scrum Guide but putting one Project Manager in charge of a Development Team, instead of providing it with a PO and Scrum Master. This may be done because higher management does not trust a self-organized , ’unmanaged" team to deliver relevant results, or even merely due to office politics.

‘see chapter on Scrum Values on pages 39ft 7

see chapter Endnotes on page 207

.

2 Definition of Scrum

16

The resulting construct may still be better than the previous arrangement , but it does not allow Scrum to unfold its full

potential and hence is not Scrum. The roles, events, artifacts and rules are not created apart from each other, but as a system , which can only function if all components are in place.

The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document .

With this paragraph , the authors emphasize again

• the interconnectedness of Scrum's parts via its rules, which are laid out in the sections of the Guide

• the

Guide’s claim as the definitive source of Scrum in general and its rules in particular

It also outlines that while Scrum does not regulate every single aspect , it does prescribe the kind of interactions deemed most appropriate . An example for this is that not only are the positions of Product Owner and Development Team described , but also it is

clarified that these two are not in a hierarchical relationship with each other, but both - together with the Scrum Master - make up a Scrum Team , in which all operate on eye-level.

Specific tactics for using the Scrum framework vary and are described elsewhere.

The authors contrast the use of Scrum as a general framework with specific tactics for using it , e g., through the application of other techniques and methods, for example, different manners in which to conduct a Daily Scrum.8 While these tactics may be

explanation of the use of the three questions in the Daily Scrum on pages 'see 143 .

*

2 Definition of Scrum

17

useful depending on the situation, they should be tailored to the needs of the respective Scrum Team and are hence not part of the Scrum Guide. In turn, it clarifies again that the Scrum Guide is not a complete manual for all aspects of product development , but rather a basis on which teams can organize themselves and their processes.

3 Uses of Scrum

18

3 Uses of Scrum Scrum is very heavily associated with software development due to its origins being in this field. Even to this day, the Wikipedia article differentiates the framework "Scrum" from the rugby method by giving the former the title "Scrum ( software development) ".[51 This entire section was added in the latest edition of the Scrum Guide in 2017. It is likely that with this section, Schwaber and Sutherland aim to emphasize that the Scrum is applicable not only in the area of practical software development but also in the surroundings of software development, as well as entirely other fields altogether.

Scrum was Initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to: 1. Research and identify viable markets, technologies, and product capabilities;

2. Develop products and enhancements;

3. Release products and enhancements, as frequently as many times per day; 4. Develop

secure , and sustain Cloud (online, on-demand) and other operational environments for product use; and,

5. Sustain and renew products.

3 Uses of Scrum

19

Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government , marketing, managing the operation of organizations and almost everything we use in our daily lives as individuals and societies. With this list and the subsequent elaboration, the authors clarify that they believe that Scrum has been and continues to be applicable in various fields and use cases, including, but not limited to software development.

.

As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum s utility in dealing with complexity is proven daily.

The first half of the sentence claims that the overall complexity in which product development is conducted has increased. A comparison of today s lives with that of one generation prior reveals that while life back then may not have been easier, it was certainly less complex . Arguably the driver for this increase in complexity is the increase Cheap availability of computational power , in technology. technological advances in fields such as mobility, radio technology and various other fields, and the societal changes this brings about, may make life arguably more comfortable, but certainly also more complex . Examples of this are the emergence of the internet and social media, the spread of smartphones, the affordability of (intercontinental) travel and its effects on the business world and the globalization of supply

chains. According to the Guide, Scrum is capable of dealing with this increase in complexity and is an appropriate tool to use as problems needing to be solved become increasingly complex.

3 Uses of Scrum

20

Scrum proved especially effective in iterative and incremental knowledge transfer.

When initially setting up Scrum in an environment, it causes a disruption Rules, terminology and workflow have to be changed, and those involved need to adapt to the new circumstances. This is why Scrum is often considered a more disruptive framework compared to, e.g. Kanban, which is seen more as an evolutionary method of gradual changes.

.

t

Beyond this initial disruption, however, which is used to clarify the relative efficacy of the existing product management and work techniques, Scrum focuses on incremental change. Within a Scrum environment, products are built in an iterative manner, in which the exchange of knowledge is fostered by: 1. Inspection and adaptation during the four Scrum Events within a Sprint

2. The

requirement

cross- functionality

-

self organization

of

and

^

3. Particularly the Scrum value of openness , in the form of ^

a) The openness to spread existing knowledge b) The openness to gaining new knowledge

1

for an explanation on the terms sett -organization and cross- functionality, see the respective definitions on pages S3 ft. 2 for an explanation of the value of openness see page 49 ,

3 Uses of Scrum

21

Scrum is now widely used for products, services, and the management of the parent organization.

According to this sentence. Scrum can be used not only in product development but also in managing a company inside which products are developed. While arguably most applications of Scrum are in individual teams working on one respective product, frameworks exist that scale Scrum to work with several teams working on the same product, such as LeSS, Nexus and Scrum@ Scale. These are further elaborated on in the next paragraph of the Guide. When thinking of a more conventionally managed, medium to large product development , one potentially encounters several layers of management , hierarchical structures, and reporting structures.

Scrum replaces this with a relatively easy to understand the structure , which even at scale maintains its focus on self-organization of teams and high- value delivery. When looking at an organization, we encounter similar situations: hierarchies , management layers, reporting structures, while the true purpose of the company lies in delivering a specific value as well as it can. Hence Scrum can be scaled beyond the product development into other parts of an organization, including the management itself . While this is still an arguably underutilized use of Scrum, it is one that the authors appear to deem important enough to add it to the Guide with the 2017 revisions.

The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single , several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.

3 Uses ol Scrum

22

Scrum is built around small teams as its core unit. A team must be large enough to deliver value , but small enough to allow for a good communication level within the team. At an absolute maximum of eleven people 3 . Ihe team maintains the possibility of self-organization.4

This is important as it allows in for the people encountering a problem to be the ones to work on solving it and having the necessary skills and empowerment to do so. Opposed to this are more conventional, hierarchical organizational structures, where problems usually would need to be passed up a chain of command. Hence a Scrum Team has the advantage of being, as the Guide puts it. highly flexible and adaptive . An initial thought when considering the development of larger products might be to add a layer of conventional management over individual Scrum Teams, for example, in the form of, e.g., a VP of Engineering, or a VP of Product . However, this would move decision-making out of the teams and. hence, violate the Scrum Team as the core entity for problem- solving and decision- making. The Scrum Guide argues that extrapolating the Scrum Team concept into an environment with several, many or even networks of teams is possible and that throughout the scaling, it is possible to maintain the benefits of flexibility and adaptivity.

While not committing to a specific way to scale Scrum in this Guide, this paragraph claims the general possibility of developing products with Scrum with more than one team. As Scrum is gaining further adoption in product management around the world , it seems to have been important to the authors to emphasize both that:

• Scrum involving potentially

up to thousands of people

is

possible, but also that

3 4

nine developers, one Product Owner one Scrum Master lor an explanation on the terms self-organization, see the definition on pages 53ff ,

3 Uses of Scrum

23

• this can only function if what the Guide calls the "flexibility

and adaptability" - which others may call "agility" - remains intact as the team remains at the core of decision making as much as possible .

When the words "develop" and "development ” are used in the Scrum Guide, they refer to complex work , such as those types identified above.

The terms "develop" and "development" are often associated with software development , where Scrum has its origins. However, as the Scrum Guide points out extensively in this section , they are not exclusively to be understood in the context of software development , but anything in terms of delivering value to people by incrementally solving complex problems. An example cited in another paragraph of the Guide is marketing, where Scrum could be used to develop a new multi-media marketing campaign. Instead of developing top-down , possibly dividing tasks up and passing them to individual people, a small team of "developers" could address the task . The "developers" in this case would be marketing professionals and designers. They would work iteratively to add new features to the campaign often while conducting tests with stakeholders and potential future target audiences throughout the development process .

4 Scrum Theory

24

4 Scrum Theory Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. In epistemology, the theory of empiricism asserts that knowledge can only or primarily be gained through experiences, rather than, for example, solely or primarily through reason, as the theory of rationalism argues. The German philosopher Kant argues that these two theories can be contrasted as such161

• Some knowledge can be derived primarily logically based on a limited number of axioms. A typical example is the field of mathematics, where no experiment is necessary to validate that 2 + 2 = 4 is a valid statement. If the axiom that 1 + 1 = 2 is accepted, applying logic, in this case, deductive reasoning, will yield this result. This knowledge is described as a priori knowledge, as it can be gained prior to (i.e , before) running experiments verifying its correctness.

.

• Some

knowledge can be derived primarily through experience. This is arguably the case in most natural sciences and also everyday life. The question of whether or not the average age of humans has increased in the last 50 years cannot be answered through pure reason, but rather

4 Scrum Theory

25

1. the hypothesis has to be formed, e.g., "the average age of all human beings has increased between 1970 and 2020"

2. the data needs to be gathered and evaluated, i.e., different potential sources are identified and checked for credibility, the data accumulated and checked for consistency

3. the hypothesis is validated or falsified based on the data. e.g. "based on the gathered data, the average age of humans in 1970 was 21.4 years old and the average age of humans in 2020 is 24.2 years old; thus we conclude that the average age of humans has. in fact, increased over time" In cases like these, where knowledge is gained through experiences and is therefore available only after experiments, the term "a posteriori knowledge" is used.

_

The Definition section’ points out that Scrum is useful for complex adaptive problems. Since a priori knowledge for such problems is not possible , an approach of gaining a posteriori knowledge has to be chosen; hence experiments have to be conducted and evaluated and decisions should be made in a data-driven manner rather than through intuition. ,

An important aspect to consider is that insights gained empirically are only approximations. They may be falsified in the future as more data become available or made obsolete as models are developed that address a problem more appropriately. From this, we can derive that:

• inside

Scrum everything should be questioned; for every approach , technique and method , it may turn out that one exists that is more suited to the current situation

see chapter 'Definition of Scrum" on pages §

4 Scrum Theory

26

• Scrum itself is open to change over

time - as it has in a handful of revisions - since newly gained insights may help us find a superior way of conducting Scrum

Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

As knowledge for most problems facing teams in product development is of an a posteriori nature, there is always a chance of failing . When approaching a problem to which an answer can only be known after an experiment, there is an inherent risk of failure. In product development , this may mean that development is going in the wrong direction: for example, that the product being developed is what is assumed to meet the demands of the market , but once released fails miserably, as it does not .

This risk is inherent in trying to solve complex problems. While Scrum cannot remove that risk, its approach can make that risk more controllable and create higher predictability. These two are interdependent, as higher predictability lowers risk, and a controlled risk yields higher predictability in the development process.

The approach Scrum takes to address these issues is its iterative and incremental approach. While these terms are sometimes wrongly used synonymously, they describe two fundamentally different concepts:

• An incremental approach to a problem means that instead of solving the entire problem at once, it is split into smaller units and solved step by step, building on top of the previous one . In Scrum, the product is not developed in one piece with all functionality ready. Instead, a piece of high- value functionality is added each Sprint on top of the existing product , called together the Increment .

4 Scrum Theory

27

• An

iterative approach is one where the same overall process is repeated and only altered in a controlled manner. In Scrum, every Sprint looks roughly the same. While the contents of what is being developed may change, the general layout remains the same: Sprint Plannings takes place in the beginning, Daily Scrums are conducted. Reviews are held, and Retrospectives are done. While small, controlled experiments may be conducted, such as shortening the timebox for the Retrospective by 15 minutes or trying out a new format for the Review, the overall flow and the underlying principles remain constant .

The iterative approach makes things more predictable. On the one hand, doing things the way they have been done before makes it likely that - aside from massive disruptions - things will work at a similar level of efficiency. On the other hand, it allows for variations in the results to be noticed. Every iteration can be seen as conducting the same experiment with roughly the same conditions present, allowing for comparisons, which creates the transparency necessary for inspection and adaptation. In Scrum, every Sprint can be seen as an experiment, testing for the best way to deliver the most value to the stakeholders.

The incremental approach limits risks by only taking one step at a time and inspecting the results before taking the next one . While this creates the overhead of having to inspect regularly, it also limits the risk to one of these steps , which may have been in the wrong direction. In Scrum, a Sprint may fail for any number of reasons, not least common of which is that what was developed was simply not what the stakeholders want . A "wasted” Sprint is nothing anybody would initially be happy about . However, it is still significantly better to have wasted a maximum of one month: developing something wrong than developing a product for potentially multiple years, just to learn in the end that all of it is not to the stakeholders liking.

2

the maximum duration of a Sprint

4 Scrum Theory

28

Furthermore, mistakes in product development quickly lead to more mistakes being made, known as the propagation of errors. In a software product development , an early misunderstanding may lead to a wrong interface design, which may lead to an incorrect structuring of data in the database, which leads to new functions build specifically for that data model being unusable once the structure is altered, etc. Analogously, taking a step in the wrong direction and correcting course may lead to a messy line, but it is better than marching straight in a straight line in the wrong direction. By building software incrementally and inspecting iteratively, Scrum limits the risk of compounding errors, which may otherwise be detrimental to the project as a whole.

4 Scrum Theory

29

4.1 Transparency

Significant aspects of the process must be visible to those responsible for the outcome.

The underlying necessity for empirical process control to function is transparency. The first sentence of the definition outlines how transparency is to be understood in the Scrum context: The phrase "Significant aspects of the process" outlines that the requirement is not absolute transparency, but rather one limited to those aspects that are deemed significant . Two reasons for this can be outlined: 1. Absolute, full transparency is not desirable. A typical example is the confidentiality level of the Retrospective . While it is not outlined in the Scrum Guide, it is common for a Retrospective to be conducted under the so-called " Vegas Rule" in practice. This rule is based on the American idiom "what happens in Vegas, stays in Vegas”, meaning that the things discussed during the Retrospective remain within the circle of its participants , if not defined otherwise. In this case, absolute transparency and the idea of trust in Scrum would collide.

2. Absolute, full transparency is not practical. In the context of Scrum, transparency is to be understood as a rather technical term. It refers to the possibility of others to see and understand what is happening. This requires effort , which may not be justifiable. For example, it may be possible to thoroughly document a newly created piece of code so that a stakeholder with no prior technical knowledge can understand it. However, the effort to create this documentation would likely far exceed the potential benefits of the stakeholder understanding the code.

In this sense, the word "significant" can be understood as

4 Scrum Theory

30

describing that which is relevant and whose transparency can be believed to generate a net gain towards value creation.

When speaking of "those responsible for the outcome”, the Scrum Guide implicitly includes the stakeholders affected as those responsible. Although one may initially think that only the Scrum Team is referred to, the phrase can be understood much more broadly as referring to anyone who has a stake in the outcome, i.e., the stakeholders. Agile product development understands the stakeholders to not merely be in the role of taking the ready product, but instead as responsible for shaping the product by contributing their inputs. Thus, a reasonable level of transparency, i.e., regarding significant aspects of the process, must be brought towards not only the Scrum Team but also the stakeholders. To give an example, the Scrum Guide states in a later section regarding the progress towards goals that "[tjhis information is made transparent to all stakeholders ”

Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen. For example:

•A

common language referring to the process must be shared by all participants; and,

• Those performing

the work and those inspecting the resulting Increment must share a common definition of "Done ".

In this second part of the definition, the requirement for transparency is outlined, namely the common understanding of what is being observed, which requires common definitions. While everybody may sense the same, i.e , take in the same

.

3

see section Monitoring Progress Towards Goals on page 183

4 Scrum Theory

31

stimuli through their senses, the interpretation ot what is being sensed, will vary depending on a wide array of factors. Creating a list of commonly shared definitions for things being commonly observed reduces the possibility of different interpretations. Thus, transparency requires a reasonable degree of standardization. Picking up the second example given by the Scrum Guide, the term "Done” may hold different meanings for different parties involved in the development process. While for a programmer, " Done" might mean that a piece of code is fulfilling the specific requirements outlined in a task , a QA specialist may require that a pace of code is tested with integration tests and comes up without problems. A Product Owner may, in turn, understand "Done" as something that can be delivered to the customer following some further work on migrating existing data. In contrast , the customer may take "Done" to be ready to be activated at the press of a button. In the scenario described above, the same observation , i.e., seeing or hearing the word "Done", raises widely varying expectations. To avoid this. Scrum requires the necessary transparency to be created in the form of a definition of "Done" ( DoD), to which an entire subsection of the Scrum Guide is dedicated. 1 A common standard regarding the meaning of used terminology allows for expectations to be synchronized and communication to be more efficient or - in some cases - even practically functional at all.

Furthermore,

transparency requires clear definitions of measurements prior to insF>ection. When for example, evaluating the efficiency of a newly introduced technique, the measured variab)e( s) of "efficiency”, for example , the number of Story Points finished par week, must be defined and, in turn, commonly shared across those conducting the inspection .

‘see chapter on the Definition of "Done" on pages 202

4 Scrum Theory

32

4.2 Inspection

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.

The term "Scrum users" is ambiguous and could in this context be meant to refer to two things: 1. It refers to the roles in the Scrum Team and is used instead of the term "Scrum Team' since not the entire team necessarily inspects all artifacts.

2. Aside from the Scrum Team , it is meant to include all those participating in the product development under Scrum, including the stakeholders.

The Scrum Guide requires transparency about the progress towards the Sprint Goal towards all stakeholders. It further requires that Reviews are conducted with key stakeholders present and that during the Review, all artifacts are inspected:

• By looking at which Product Backlog items are "Done" and which ones are not "Done", and what went well and what problems occurred, the Sprint Backlog is inspected

• The combination of the previous increment and the "Done" Product Backlog items create the new Increment , which is being inspected during the Review

• As the Product

Owner presents the Product Backlog and the entire group ( Scrum Team plus key stakeholders) collaborates on what to do next , the Product Backlog is inspected during the Review

Thus, it may be assumed that the term "Scrum users" in this case includes (key) stakeholders. Each individual inspects artifacts and the goal according to their respective role in the process. For example, the Product Owner frequently inspects the Product

4 Scrum Theory

33

Backlog and the progress, while the Development Team frequently inspects the Sprint Backlog. In the inspection process , commonly agreed-upon measures, which are defined in the process of creating transparency, are to be used to a) observe possible variances from agreed-upon conventions and b) determine whether these are undesirable and warrant further action in the phase of adaptation.

Their inspection should not be so frequent that inspection gets in the way of the work. The inspection aims at detecting upcoming problems and allows for possible solutions to be devised and implemented quickly. Thus, in theory, there should be a virtually constant inspection of all inspectable things. In practice, however, this would cause a problem, as the ones who are conducting the inspections are (primarily ) those doing the work that is being inspected, meaning no work would be done, as everybody would be busy only inspecting. While with these extremes, it may seem obvious, finding the right balance of inspection and work in practice may be difficult. For this reason, the Scrum Guide explicitly outlines that during the Planning, Daily, Review and Retrospective inspection and possible adaptation must take place, effectively defining a minimum number of opportunities for inspection and adaptation. As the required amount of inspection may vary depending on the circumstances. Scrum does not prescribe anything more concrete beyond that inspection should not get in the way of the work . Herein it can be seen that Scrum is a framework rather than a definitive methodology.

4 Scrum Theory

34

Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

When speaking of inspection, it must be clarified whom the inspectors are ideally supposed to be. In this sentence , the Scrum Guide gives three criteria, which, when fulfilled, lead to the most beneficial inspection . The inspectors should:

• inspect diligently, meaning carefully and with a lot of effort. This includes the courage to inspect according to the metrics agreed upon prior, regardless of what may be uncovered. Diligent inspection lives on the courage to uncover things even if their revelation may be uncomfortable or inconvenient to individuals or groups. A diligent inspection into the reasons for a part of a product causing technical problems may uncover, that errors were made by developers and not discovered in testing. This situation may be initially uncomfortable, especially for the developer who made the mistake and the developer who conducted the testing, but a thorough inspection nonetheless uncovers this, as only that way, adjustments to the process, what the Scrum Guide calls 'adaptations', can be made and the value delivery to the stakeholders can be maximized.

• be skilled. This is a broad term

which is once again due to the wide variety of products that may be developed with What skills exactly are necessary is highly Scrum. contextual, though it should be ensured that those conducting the inspection are skilled , i.e. . have the capabilities to uncover what needs to be uncovered.

• conduct

,

their inspections at the point of work. This is an important notion, as it breaks with the setup of conventional product development as is still practiced in many organizations, namely the separation of the development and the inspection, usually performed by some form of a Quality Assurance (QA ) department.

4 Scrum Theory

35

While an inspection by an inspector external to the Scrum Team has advantages , one of which is the greater degree of objectivity, as those inspecting a product are not the ones who have built it and are therefore less error-blind and less biased. The Scrum Guide , however, argues that inspection at the point of work , which in most cases means by the Scrum Team ( or a respective subset thereof ) , is more beneficial. This is likely because those who develop a product are automatically those most familiar with it , meaning the degree of information is highest at the point of work , which - when done diligently and skillfully - leads to the best insights and thus the most beneficial inspection overall.

4 Scrum Theory

36

4.3 Adaptation

If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation. If a deviation is identified, measures should be taken as soon as possible to correct the underlying problem. It is important to note that this adaptation will in itself just be an experiment, the outcome of which needs to be empirically assessed While there may be educated guesses as to what could constitute a proper adjustment , the outcome of the process with the adjustment made needs to be again inspected, and further adaptation ( attempts ) may be necessary.

.

Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of this document:

• Sprint Planning

• Daily Scrum • Sprint Review • Sprint Retrospective All events within a Sprint are to be used for inspection and adaptation. This emphasizes the importance of empirical process control within Scrum It can even be argued that Scrum itself is primarily a setup for systematized inspection and adaptation among other things since all events in Scrum serve the purpose of empiricism in some form and the only way that

.

-

-

4 Scrum Theory

37

progress can be made and understood is through empirical process control.

4 Scrum Theory

38

This section on empirical process control gives a very technical outline. It is interesting to look beyond that , at the practical implications such an approach has in environments where product development is still dominated by a non-empirical mindset: Working on a complex problem occasionally, yet inevitably, leads to failures, e.g. , a Sprint that delivers little or no value ; conventional thinking may be quick to attribute blame, thinking that the Scrum Team is guilty in some way for failing. This is based on the assumption that the "right" way of working on an issue could have been known beforehand and that it is a shortcoming of the Scrum Team not to have put in the effort to

find it. A key implication of understanding empirical process control, however, is that the "correct" way of working on a problem does not exist . There may, in theory, be a perfect way in which to develop a specific product ; it is not possible to know this way in advance due to the complex nature of the problem . Hence the entire process is a series of controlled experiments and data-driven decisions aiming towards the overarching goal of value delivery as efficiently as possible.

Norm Kerth, author of the book Project Retrospectives: A Handbook for Team Reviews, thus suggests framing retrospectives with what he calls the Prime Directive: " Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at handT71

5 Scrum Values

39

5 Scrum Values Values are the drivers of behavior. They allow individuals and teams to make decisions for which there is no prescribed rule. Scrum as a framework provides relatively few rules, leaving decisions on interactions between individuals, techniques and methods, and specific courses of action up to the Scrum Team. For the decisions on these, the Guide provides a set of values on

which Scrum is based In Scrum, these values are aimed at fostering empirical process control as a means of achieving higher productivity and better value delivery by the Scrum Team.

The Scrum Guides chapter on values is relatively new, having only been added in 2016.

When the values of commitment, courage , focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. In this first sentence of the value section, the Guide claims a causal relationship between embodying and living by the five values on the one hand and the functionality of empirical process control, as well as the emergence of trust.

The Scrum Guide distinguishes between embodying and living of values:

• The

-

Merriam Webster dictionary defines embodying as representing something in human form, to be used as a

5 Scrum Values

40

possible synonym for personifying. In the Scrum context , values can be understood as acting on them, i.e. , aligning one's actions by the values.

’embodying' , the

• "Living"

in this context refers to the internalization of the values into one's regular behavior and thinking and decision-making process.

Doing both , according to the Scrum Guide, leads to the ’ Scrum pillars’ coming to life. This is a poetic formulation for the functionality of empirical process control, which strongly benefits from the presence of realized Scrum values. The relationship between the values and empirical process control will be elaborated in the next sections.

Another result of embodied and lived Scrum values is the emergence of trust . Trust is defined by the Cambridge English Dictionary as the belief "that someone is good and honest and will not harm you. or that something is safe and reliable". It provides the basis for collaboration within a team, particularly a self-organizing one. The relationship between the values and the emergence of trust will also be elaborated in the next sections.

The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

Values cannot be taught academically. It may be possible to understand them and their intent sufficiently to be able to embody them , for example, by giving a proper answer to a case study based on the internal logic of the values. In order for Scrum Teams to be successful, however, they must not only embody the values but live by them. This requires not only an understanding of the values but acceptance of them and integrating them into one’s thought and decision-making process.

The way this can occur is by what the Scrum Guide refers to as learning and exploring the values with Scrum's events, roles and artifacts. In Scrum, all of these rely on the Scrum values'

5 Scrum Values

41

presence in one way or another. The way the Scrum Team becomes proficient , which the subsequent sentence defines as essential for successful use of Scrum , is by applying the values experimentally, observing the results and drawing conclusions. Seeing beneficial outcomes of applying the values reinforces their acceptance and integration.

Example: The value of courage is a crucial one for Sprint Retrospectives. A team has a difficult problem to address: for multiple Sprints, it has been slowed down by an issue that nobody wants to address, fearing negative repercussions . While everybody is aware of the negative influences , nobody has the courage to speak up about it yet . During the next Sprint Retrospective, one member finally addresses the issue, having built up the courage to do so. Initially, this causes some trouble and discomfort within the team; however, the team now works together to find a solution for the problem. Over the next few weeks, the problem is mitigated , and a clear path to resolution is visible to all members of the Scrum Team . The Scrum Team observed an act of courage, i.e., an embodiment of the value of courage, leading to a positive outcome for the individuals on the team and the team as a whole. This positive reinforcement will make acts of courage more likely in the future and work towards the integration of the value of courage.

Successful use of Scrum depends on people becoming more proficient in living these five values.

Scrum is a framework built around empirical process control. use’ can be understood as improvements in the application of empirical process control. Scrum has set up its roles, artifacts and events to foster empirical process control. Each of these depends on one or multiple of the values being lived out by "peoplen i.e. , not only members of the Scrum Team

" Successful

.

5 Scrum Values

42

but also even others in the organization or even external stakeholders. An increase in proficiency in living the Scrum values allows for more effective events , more useful artifacts and roles acted out more productively. All of these factors foster empirical process control and make the product development process more effective, efficient and risk-controlled.

5 Scrum Values

43

People personally commit to achieving the goals of the Scrum Team. People, referring to everyone with an active stake in what the Scrum Team is developing, personally commit to the achievement of the Scrum Team's goals. Having buy-in from those involved ensures their willingness to do what it takes to achieve the goals.

Commitment is listed first and provides the basis for the other values to matter : A team, in which no one is committed to the goal , has no intrinsic reason to act courageously , as doing so would generate discomfort to achieve something those involved do not care about. Such a team would also not focus on goals which it does not care about. It would furthermore have no reason to ensure openness , which potentially leads to problems while not generating results the team cares about. Respect may or may not be present in such a team, though this is dependent on the personal values of those involved, not due to respect 's positive effect on generating outcomes. Commitment fosters empirical process control by ensuring everybody is taking an active stake in the outcome and becoming involved both in the development process, as well as the control of that process by empirical process control. A group that does not care about the outcomes has no reason to improve the process of generating those outcomes. An example of visible results of low commitment is a Sprint Retrospective with low engagement . The Scrum Team members don't care about the goals of the team. Therefore, they have no reason to improve upon this through retrospection. Commitment fosters trust , as everybody can be sure that those involved work actively towards a common goal. This provides a

5 Scrum Values

44

unifying factor and. therefore, a sound basis upon which issues

can be resolved and potential synergies utilized.

5 Scrum Values

45

The Scrum Team members have courage to do the right thing and work on tough problems. The Cambridge Academic Content Dictionary defines courage as "the ability to control fear and to be willing to deal with something

that is dangerous, difficult, or unpleasant". When dealing with complex problems, situations are bound to arise that require actions to be taken or decisions to be made that are:

• unpleasant

- making those involved uncomfortable, i.e. , providing feedback to a colleague or stakeholder about perceived inappropriate behavior

• difficult - having no certainty that the issue can be overcome • dangerous - carrying the risk of severe negative consequences Concerning these, courage refers to the Scrum Team members' willingness to tackle such issues despite them being tough.

Courage also empowers the other values : Commitment requires a belief that the goals set are achievable. When courage is missing , people will be less inclined to commit to goals, especially tough ones. A lack of courage may lead to the Scrum Team losing focus of the Sprint work and the team's goals , as it is much more inclined to work on other things that are easier to accomplish. Being open with each other carries with it the risk of being ( emotionally ) vulnerable by others on the one hand, as well as offending others on the other. The willingness to do either is significantly reduced if there is no courage, i.e., willingness to do such things and carry such risks even though they are tough . One can accept others as capable and independent. However, truly respecting somebody entails a willingness for honesty with them, as one respects them enough to assume they can handle honest statements. Being honest can be easy at times, but at others - usually, those where it truly matters - it can be tough . To be honest , despite this, one needs courage.

5 Scrum Values

46

Courage fosters empirical process control by allowing the team to run difficult experiments . Empirical process control is predicated on running experiments to determine cause and effect relations, which are not knowable beforehand in complex problems, and adjusting accordingly. ' Running experiments carries with it the risk of the hypothesis being tested being falsified , which is often understood as a failure. This notion is especially strong if the effort to conduct the experiment was high , i. e., conducting the experiment was tough. Conducting experiments, i.e., working empirically, despite these challenges, is what the value of courage is about . An example of visible results of low courage is a Sprint Retrospective with unambitious results The Scrum Team members may care about the outcomes of their work but are afraid of potential negative consequences of trying new approaches, most notably the risk of their experimental approach being unsuccessful. ,

Courage fosters trust, as everybody can rely on each other to tackle even difficult problems in pursuit of a common goal. Overcoming difficult challenges together creates a bond of trust between people, as their relationship has been successfully challenged in the face of adversity.

*

see explanation of complexity in the Cynefin Framework on pages 711

5 Scrum Values

47

Everyone focuses on the work of the Sprint and the goals of the Scrum Team.

To be successful, the Scrum Team must be able to focus on the Sprint work. Doing the work necessary to achieve the Sprint Goal is the highest priority for the Scrum Team members throughout a Sprint. The Scrum Guide uses the term "everybody " , implying that the need for focus goes beyond the Scrum Team to include (key ) stakeholders. Supporting stakeholders' understanding of the Scrum Team's goals and why focusing on them is critical to success are among the tasks of the Product Owner and Scrum Master within a Scrum Team. Concerning goals , focus can be understood synonymously to "goal-directedness", in that those involved ensure the highest priority guiding their actions is achieving the commonly defined goals.

Focus relates to the other values: Without focus, commitment is merely an empty promise. Committing to a goal that is then not pursued in a focussed manner is not useful. A consistent focus on common goals drives courage. The ability to tackle difficult problems is necessary to achieve goals. A high focus on a goal also provides motivation to step out of one's comfort zone to tackle tough problems, which is courage. Focussing on a higher common goal provides a shared purpose among those pursuing them, which provides a solid basis for the required mutual openness. Successfully working together to achieve common goals allows respect to grow among those involved.

Focus fosters empirical process control by bringing larger parts of the work under the influence of empirical process control, makes things more predictable and more consistently comparable. A team that spends much of its capacity outside the scope of the Sprint and not directed towards common goals spends much

5 Scrum Values

48

time on activities outside the view of Scrum s empirical process control. Scrum s events are set up to inspect the Sprint s work towards the team s goals. If only a share of the capacity is spent on those, then Scrum will only be able to support the improvement of that share. Furthermore, empirical process control relies on experiments that deliver the most meaningful results when the conditions of the experiment are relatively stable, and only one or a few parameters are changed. Focus on the teams work , mainly manifesting in the vast majority of ( time ) capacity being spent on work in the Sprint, allows conditions between different days and between different Sprints to be more comparable, reducing complexity and improving the possibilities of empirical process control. An example of visible results of low focus is chaotic Daily Scrums with overly frequent changes to the Sprint Backlog and potentially the scope of the Sprint . Forecasts in the Sprint Planning are based on the perceived capacity of the Development Team. If focus is lacking, which may manifest in members of the Development Team working on things outside the Sprint, the forecasts become vaguer. This leads to the need for more frequent adjustments during the Daily Scrum, especially when the amount of work spent on Sprint work strongly fluctuates between days.

Focus fosters trust , as everybody can rely on each other to pursue common goals and work with the highest priority to achieve these. Having common goals and achieving them through dedicated common work allows for trust to grow between individuals.

5 Scrum Values

49

The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Openness, as understood by Scrum, describes the willingness to share key aspects of their work, such as the topic, the goals, the intentions, the methods, the speed and the challenges. This value applies to both the Scrum Team and its stakeholders. Stakeholders must be open about their needs and provide feedback to the Scrum Team. The Scrum Team, in turn, must be open towards the stakeholders and share with them aspects that in more conventionally managed product development may be actively hidden, such as obstacles to work or critical feedback towards the stakeholders. Furthermore, the members of the Scrum Team must be open towards each other.

Openness relates to and fosters the other values: When significant parts of the work are not visible, and it is not possible to see what others are working on , agreeing to work hard towards a goal is difficult. If , on the other hand , everybody is open about the work and the scope and goal of the work becomes clear, it is easier for both Scrum Team members and stakeholders to commit. Being open about work and its problems allows those involved to understand both the challenges ahead and the challenges already overcome in the past. Being aware of the difficulties that have been overcome to get to the current point encourages tackling the next problems courageously . Focus on the work of the Sprint and common goals requires openness towards each other what the goals and the work are and how progress is advancing. When people can see the work that everybody else does, and everybody sees how others overcome difficult tasks, it becomes easier to respect each other. Openness fosters empirical process control by providing the basis for transparency. For inspection and adaptation to take place, transparency must be present . This can only be the case if

5 Scrum Values

50

those involved are open about the situation as it is about the work and its challenges. An example of a failure of openness is repeated frustration in Sprint Reviews. The stakeholders may have a hidden agenda , which leads to needs they are not open about towards the Scrum Team. Subsequently, the Scrum Team cannot develop the product to meet these needs. Also, the Scrum Team may not be open about the problems they face when doing the work, be it out of fear of offending stakeholders or due to a false understanding of pride in their abilities. In either case, empirical process control is undermined. With openness present, all involved could address the issues and collaborate to improve the situation for mutual benefit . Openness fosters trust , as those involved can observe the activities of one another. This allows trust in their abilities to grow, as it is visible to one another that each person actively contributes to common goals. It also allows trust in each other as human beings to grow, as openness allows an understanding of each other's intentions. While one may not agree with another person s intentions, being aware of them allows for predictability, which is a cornerstone of trust .

5 Scrum Values

51

Scrum Team members respect each other to be capable, independent people.

The Merriam- Webster Dictionary defines respect ( as a verb) as The Cambridge English Dictionary defines it as "admiration felt or shown for someone or something that you believe has good ideas or qualities”. In Scrum’s context, members of the Scrum team respect each other, meaning they consider each other worthy of high regard and acting on the assumption that the others have good qualities in them, especially related to their work .

"to consider worthy of high regard”.

Respect relates to the other four values: Having to solve a problem alone or with others, whom one deems incapable, is demotivating. When a Scrum Team member respects their fellow members, however , the problems they have to address together become more approachable. This enables a higher level of commitment . Furthermore, believing one's fellow members to be capable and knowing the feeling to be mutual, provides an environment in which difficult problems can be more easily addressed through acts of courage. When working with a team towards a goal, focussing on that goal becomes easier when working with people held in high regard for their abilities to contribute to achieving that goal . In order to show openness, one needs to regard the others as worthy of openness. People held in low esteem may not be perceived as worthy of openness, while respected fellow team members are. Respect fosters empirical process control in that it is a fundamentally necessary assumption for process improvements. When faced with an improvable situation, one can either blame others, especially particular individuals , which will likely not yield positive results. If respect is present , on the other hand, the approach changes to change the process ( through empirical process control) rather than giving up by blaming people. Furthermore, teams in which respect is strong will be willing to experiment more, as an experiment proposed by an individual member failing will not hold negative personal repercussions in

5 Scrum Values

52

the form of peer pressure. The willingness to conduct more experiments increases the speed and intensity of empirical process control and generally leads to better results. An example of visible results of low respect is unengaged Sprint Plannings. Members are afraid to contribute their ideas. An implicit hierarchy was built due to a lack of respect from more senior members towards the others. Rather than collaboratively finding the best way to create the Sprint Backlog plan , only a few Development Team members work in it. This leads to poorer planning , in turn, lower engagement in adjusting the plan throughout the Sprint and ultimately to worse results being produced.

Respect fosters trust in both directions. It is difficult to trust another person who holds one in low regard and considers one incapable . Conversely, it is difficult to have trust in somebody who is believed not to be capable. Awareness of mutual respect provides the groundwork for trust to grow

6 The Scrum Team

53

6 The Scrum Team The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. A Scrum Team is made up of people, falling into one of three distinct roles:

• One Scrum Master • One Product Owner

• A member of the Development Team There are no further roles within a Scrum Team.

Scrum Teams are self -organizing and cross- functional. Self -organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross- functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

-

The Scrum Guide identifies self organization and cross functionality as key criteria for a Scrum Team. These two are tightly interwoven with each other.

-

-

Self organization can be broken down into two perspectives:

• The external: A team must be empowered to choose the

best way to accomplish their work for themselves. An environment must exist, where no interferences with the

6 The Scrum Team

54

Scrum Team's decision- making exist, e.g., through micro- management from a higher hierarchy layer in the organization.

• The internal: A team must be capable and willing to choose the best way to accomplish their work for themselves. This requires a high sense of ownership of the team towards what they are developing, meaning that the team wants to pursue the development further in the best way possible , which is not necessarily the easiest , most exciting, or most rewarding.

These two sides are mutually dependent, as a team that wants to determine its way, but is not allowed to. would not be self -organizing and neither would a team that is given the freedom to but does not want to or does not know how to. Therefore the requirement of self-organization puts significant challenges on those within the team, as well as on the parent organization. ,

Cross- functionality requires the team’s competencies, i.e., skills, abilities, and expertise required to do the work without dependencies on external third parties. This can be split into two complementary views:

• Internal:

A team must collectively possess the skills required to accomplish the work on its own. While not every individual within the team must be capable of accomplishing every work , across the team, the proper abilities must exist to make a team function in their value delivery, hence the term cross- functional.

• Structural:

Within an organization , the work must be structured in a way that a team can potentially be capable of accomplishing work without depending on external parties.

In Scrum, "accomplishing the work" always refers to activities aiming towards delivering value.

6 The Scrum Team

55

The two concepts of self-organization and cross- functionality are dependent on each other in practice:

• Only a cross- functional team that possesses all the abilities necessary to accomplish the work can choose adequately, what the best way of doing so is. If a skill were needed for the work that the team does not have, it would depend on outside input and thus not self-organizing. self-organizing team is the one quickest to identify the needed skills it is lacking . Thus a self -organizing team is the most reliable basis on which to create a cross-functional

•A

team.

The team model in Scrum is designed to optimize flexibility, creativity, and productivity. The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.

Scrum is designed to address complex problems' . Thus, Scrum's attributes , including the team model, need to be designed to optimize for characteristics that help address complex problems. Flexibility, creativity, and productivity are considered crucial for addressing complex problems.

Complex problems are categorized by the fact that the relationship between cause and effect cannot be known in advance . Therefore, the correct approach is to experiment , observe , gain insights, draw conclusions, and potentially adapt to better solutions. This is the empirical approach as the Scrum Guide understands it, and it is based on the ability to change the parameters of the experiments.

see explanation of complexity in the Cynefm Framework on pages 7ft .

6 The Scrum Team

56

In a product, such an experiment could be to create a new user interface for an existing program and test how the market reacts to it. In a development process, an experiment could be to expand the time developers spend per Sprint on refining the Product Backlog with the Product Owner to test how this affects the speed and quality of the development. In these examples , the interface and the duration of the refinement respectively are the parameters changed to inspect the outcome , draw conclusions and potentially adapt accordingly.

One crucial factor for the effectiveness of empirical process control is the ability to conduct such controlled experiments quickly, which in turn depends on the ability to change parameters frequently and quickly. This is what "flexibility" means in this context. It allows for a quicker empirical process and, therefore, faster, more efficient solutions to the complex problem to be solved.

Another crucial factor is to decide on parameters to adjust , which would be easy if the relationship between cause and effect where approximately foreseeable, which by definition is not the case in a complex problem. Thus a skill and a mindset are needed to come up with new ideas to try. This is what is referred to by "creativity" in the Guide. The goal of work in product development in Scrum is to deliver high- value Increments Increments can be described as high- value if much value has been added within a Sprint . As the key parameters of work during a Sprint - the time, the number of people , the available resources - are relatively static , i.e. , they do not change significantly - the only way to generate more value is to improve the process by which value is generated. The relationship between inputs into a Sprint and the outcomes of a Sprint ( for the stakeholders) are what the Scrum Guide understands by "productivity”. ,

The team model optimizes for these as follows:

Flexibility, which is understood as the ability to make changes quickly, requires those making the changes to be able to do so. If

6 The Scrum Team

57

every minor change would need to go through a multi-step approval process in various levels of hierarchy, or if for every change a third party would need to be consulted for advice due to a lack of knowledge , the process would be dependent on parties outside the team and take longer than necessary.

A self -organizing team possesses the autonomy to make changes on their own without external approval.

A cross- functional team can make changes on its own without external dependencies, hence avoiding potentially long feedback loops with outside parties.

The team model in Swum thus creates an environment of empowered and capable actors and can hence be seen to foster flexibility. Creativity, which in this context is understood as the ability to develop possible creative solutions, requires a significant understanding of the problem. While somebody unfamiliar with the problem may give an input that could be "creative", it is arguably much more likely to be nonsensical. A team that has the permission and the ability to conduct its work the way it chooses to, i.e. , a self-organizing, cross- functional one. is a team that is more knowledgeable of the work than anybody else. This significant insight into the work provides a key pillar for creativity.

Furthermore, as creative solutions are, by definition, not "normal", developers may require a sense of safety to express potentially creative ideas. The team model in Scrum is a manifestation of the Scrum Values, the most important ones for creativity arguably are:

• Openness:

both of sharing new ideas and being open to new ideas, rather than brushing them off

• Courage : both to express new ideas and to try them out

6 The Scrum Team

• Respect:

58

brought towards other team members, in this

case, those voicing new ideas These values, as well as the trust that results from living all Scrum Values2 . provide individuals within the Scrum Team with the environment in which creativity can flourish. Lastly, a self -organizing team is one to decide on their own how to do their work, implying that there is no other party to make those decisions for the team. With regard to creativity, this creates the necessity for the team to be creative itself , which creates a greater incentive both to generate new ideas as well as to take action to further foster creativity. The team model in Scrum thus creates incentives as well as the proper environment for creativity and can hence be seen to foster creativity. Productivity in Scrum can be understood as the relationship between what resources go into the Sprint and what value is generated by the process within a Sprint . The team model in Scrum with its self-organizing and cross- functional teams and clear roles sets up a team with relatively little overhead. While there are two non-developing positions on a team, the team s self -organizing nature removes the necessity for an The team as a administrative layer above the team. cross-functional entity is capable of doing its work without external dependencies, removing the need for outside support . Thus the total resources required for producing an Increment are lowered to an almost absolute minimum. On the other hand, the efficiency of the process is continually upkept and increased through the application of empirical process control3 . which benefits from the self- organization and cross- functionality, as they foster the necessary flexibility and creativity to drive empirical process control. The team model in Scrum thus reduces the resource inputs into the Sprint as well as supporting the continual optimization of the 2 3

see chapter on Scrum Values on pages 39fl. see the section on empirical process £2£lL2! 0 1 P^Sjes 2411

,

6 The Scrum Team

59

development process and can hence be seen to foster productivity.

Scrum Teams deliver products iteratively and Incrementally, maximizing opportunities for feedback.

in Scrum, the iteration within which value is delivered is the Sprint. Therefore, every Sprint , i.e., in a consistent time frame no longer than a calendar month, an Increment is produced.4 The Incremental approach , i.e., adding value one piece at a time rather than building an entire product right away, is chosen, as it allows for feedback to be gathered throughout the development process. This, in turn, allows adjustments to be made relatively early in the process when errors can be conected relatively cheaply.

The first opportunity for a Scrum Team to gather feedback on a new Increment is the Sprint Review5 . in which the new Increment However, incremental is presented to key stakeholders development allows the Increment to be released to the end- users and valuable feedback to be gathered from them. This is different from more conventional approaches, which in the Increment may be considered an "unfinished product”, as it does not yet contain all features desired. It is important to note that the term "deliver” in this sentence does not refer to delivering a product to the end- user, but merely to have an Increment done for inspection at the Sprint Review. While it may be beneficial to release Increments to the end-user often, this does not need to be after every iteration , but according to business decisions among the Product Owner and key stakeholders.6

The iterative delivery of products , as compared to deliveries that are non-iterative like, for example, in some Kanban systems,

‘ see section "The Sprint" on oaoes I 12tt 5

“

see section "Sprint Review" on *2*-l* L*Js 14flff , see the final sentence of the Increment section on page

6 The Scrum Team

60

means that feedback can be given not only on the product delivered but also on aspects of the delivery process. The key iteration in Scrum, the Sprint, is relatively well comparable over time, as it follows the same pattern and is of the same length every time7 . This relative standardization allows for the results of Sprints to be compared with each other, for example, in terms of stakeholder satisfaction with the results, which can provide valuable feedback to the Scrum Team.

Incremental deliveries of "Done" product ensure a potentially useful version of working product is always available.

At the end of a Sprint, the Increment must be "Done”. This does not mean that the product must be finished and the project is over, but rather that an Increment could potentially be handed over to stakeholders or the market and would be usable.

An example of this would be adding a new contact form to an application in which users can type in their message , which, however, does not actually send anything, as the messaging functionality in the backend has not been developed yet . In this case, adding the un- "Done” feature to the delivered Increment , thus creating an un-"Done” product , would lead to a non- useful

version. An Increment does not necessarily have to be released to the stakeholders or the end- users every iteration, but it is advisable to release often to gather feedback Releases are not necessarily restricted to the cadence of the Sprint. However, having a "Done” Increment at the end of a Sprint ensures that there is always a point in time when a product exists that is "Done" and could be released.

Without this requirement, an Increment could potentially always

7

see explanation on why Sprints have consistent lengths on paoe 113

6 The Scrum Team

61

contain at least one feature not Done ", which would mean that

either

• a release would not be possible at all - which would prevent feedback and therefore hinder empirical process control. • priorities would need to be shifted temporarily towards getting an Increment "Done" for release, rather than

towards further feature development; this would lower overall value delivery and violate the value of focus . -

• the un-"Done" features would need to be made inaccessible either by removing them or by adding a way to hide the unfeature • both of them would add unnecessary work and hence hinder value delivery, the latter may even create security risks, further lowering value.

"Done "

To allow for the Product Owner and stakeholders to be able to release a version potentially, every Increment must adhere to the standards defined in the definition of Done" (DoD ) . ’

'’ foe an explanation of the value of focus, see page 47 9

-

see chapter on the Definition of ‘Done on pages 202

6 The Scrum Team

62

6.1 The Product Owner

The Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Scrum Guide s section covering the Sprint Planning 0 divides it into two parts: one concerned with what should be developed in the next Sprint and one with how this development should best This divide is present throughout the entire take place. framework and shapes both the Product Owners and the Development Team's role and the relationship between them. The Product Owner in Scrum is concerned fully with defining the direction the product development, i.e., the work of the Development Team, should take in order to deliver maximum value. This is to be understood as a broad generalization of their responsibility, as well as the general attitude of a Product Owner. The concrete implementation of this depends on a variety of factors and. as the Guide points out, may vary significantly across

• organizations, which provide different environments within which the product development takes place. For example, a Product Owner of a product that is owned by their company and released directly to the final user may spend much time on market and customer research and have only minimal interactions with other stakeholders. On the other hand, the Product Owner of a product that is developed for a B2B customer may be concerned much less with market and customer research than with gathering and balancing the interests of different stakeholders from within the customers company, e.g., different departments. At this

10

see section "Sprint Planning" on pages 123ff

6 The Scrum Team

63

level, it is crucial for a Product Owner to adjust to the organizational maximize their surroundings to understanding ot what is needed for the maximization of value delivery by the Development Team’s work.

• Scrum Teams, which may have different requirements of the Product Backlog . For example, some Development Teams may need highly detailed descriptions of their expectation to fulfill their work properly as the Product Owner would like it. On the other hand, there may be Scrum Teams in which the Product Owner entrusts the Development Team with a much greater creative freedom and only gives a handful of acceptance criteria. Such a dynamic may shift over time. At this level, it is crucial for a Product Owner to adjust to the needs of their Scrum Teams, to ensure they receive what is needed for maximum possible value delivery.

• individuals, which may have widely different processes and methods that work best for them . For example, some Product Owners may find it best to meet with stakeholders, ask them powerful questions to gather data and over a few days distill it into their understanding of the needs and subsequently into updates of the Product Backlog. Others, however, may meet with their stakeholders to conduct a day-long Design Thinking session with multiple options for possible prototypes.

At this level , it is crucial for a Product Owner to use tools with which they as an individual are best able to do what is necessary to allow for value maximization of the Development Team's work.

Scrum as a framework does not prescribe methods, tools or processes, as each situation is different , and each Product Owner is empowered to find out for themselves how best to maximize the value delivered by the work of the Development Team. The only constraint that the Scrum Guide gives for this is that the roles, events, artifacts, and the rules binding them

6 The Scrum Team

64

together may not be violated.

The Product Owner is the sole person responsible for managing the Product Backlog.

The Product Backlog reflects what is known about the product and its future direction. Its ordering reflects current priorities. The responsibility for managing the Product Backlog, aspects of which are outlined in the next sentence of the Guide, lies exclusively with the Product Owner.

Product Backlog management includes:

Product Backlog management aims towards strengthening the purpose of the Product Backlog , which is to serve as an Artifact , making transparent what is currently known about the product and the direction its further development will likely take.

• Clearly expressing Product Backlog items; Product Backlog items must be crafted and refined to be clearly understood. This serves to create a common understanding of the purpose and details of an item and hence creates transparency regarding the expectation.

6 The Scrum Team

65

• Ordering

the items in the Product Backlog to best achieve goals and missions;

The implementation of Product Backlog items aims at delivering value to realize a larger vision or mission and, in the more immediate context, concrete goals. The ordering of the Product Backlog reflects the priorities to do this as they are currently understood.

• Optimizing the value of the work the Development Team performs;

Scrum aims at increasing the effectiveness and efficiency of product development The efficiency of the development is increased through improving the development processes via empirical process control. The effectiveness, i.e. the value of what the work delivers, is optimized by properly managing the Product Backlog.

.

t

The Product Backlog should reflect at any time how the limited resource of the Development Team s work can be utilized to deliver the greatest value.

• Ensuring

that the Product Backlog is visible , transparent and clear to all, and shows what the Scrum Team will work on next ; and,

Four attributes describe the Product Backlog in this sentence:

• visible,

meaning those who have a reasoned interest in inspecting it must be able to do so easily. A Product Backlog that is hidden away in a file on the Product

6 The Scrum Team

66

Owner's computer makes it impossible for others to inspect and provide feedback on the current Product Backlog .

• transparent, in this case going beyond just the aspect of visibility. It must be possible for those inspecting it to have the same understanding of the terminology used.

• clear to all, in this case going beyond the requirement of transparency for a common language, and including Product Backlog items in a way that they can be reasonably understood by those responsible for the outcome of the product development expressing

• showing what the Scrum Team will work on next, meaning the order must reflect the current priorities and , therefore, approximately what the next things will be that the Scrum Team will work on. Ensuring that these criteria are sufficiently fulfilled is one responsibility of Product Backlog management.

• Ensuring the Development Team understands items in the Product Backlog to the level needed.

In order to provide estimates and later implement the Product Backlog items, the Development Team must understand the items in the Product Backlog with which it is dealing. Therefore, Product Backlog management must aim, among other things , to ensure the Development Team 's understanding of the items.

6 The Scrum Team

67

The Product Owner may do the above work , or have the Development Team do it. However, the Product Owner remains accountable.

The accountability for the state of the Product Backlog lies with the Product Owner. This does, however, not mean that the Product Owner must be actively involved in every aspect of Product Backlog management. There may be scenarios in which delegating some or almost all aspects of Product Backlog management to the Development Team makes sense and/or is necessary. Such delegation is especially necessary in cases of scaled Scrum approaches, in which multiple Scrum Teams work on one product. As the Product Owner’s time is limited, two approaches are thinkable, only one of which is Scrum compliant though:

• Adding a separate (Proxy-)Product Owner for each Scrum

Team. This approach, in which the individual Product Owners would likely be subordinate to the (Head/Chief ) Product Owner, violates Scrums idea of having a single Product Owner as the ultimate source of truth regarding the product and the direction in which the development is heading. While this approach is common in practice, it is not in accordance with the Scrum Guide.

• Delegating

some aspects of the Product Backlog management to the Development Teams. This may require adding product management capabilities to the team to ensure it remains cross functional.

-

A common approach is to delegate to the Development Teams to break down large Product Backlog items into smaller ones and refining those without the Product Owner as much as possible

While the immediate responsibility for management may be delegated to the Development Team, the accountability remains with the Product Owner, which includes the requirement to

6 The Scrum Team

68

ensure those doing the management work are capable and inspecting the work they do reasonably frequently.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item's priority must address the Product Owner.

Scrum creates the Product Owner as the single source of truth regarding the Product Backlog. When developers or stakeholders wish to gain information, speaking to different Product Owners may yield them different results, which would lead to miscommunication. One product is owned by one Product Owner, where ownership does not refer to the possession, but to the Scrum understanding of ownership, i.e., to initiative, responsibility, and being in the care of somebody. This rule remains in place even when multiple Scrum Teams work on the same product. In this case, the Development Team may need to play a more active role in Product Backlog refinement to support the Product Owner. The previous sentence explicitly allows for this.

The Product Owner may consider inputs from stakeholders and possibly even an internal advisory committee when sorting the Product Backlog, however, the decision of what constitutes the maximum possible value delivery by the Development Team’s work and therefore the order of the Product Backlog remains one that only the Product Owner is allowed to decide over.

6 The Scrum Team

69

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner ’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

The role of the Product Owner was crafted based on the idea that one person, who knows most about the current state of the product and how to deliver value from it, would make the decisions regarding the direction of further product development. The Scrum Team as a whole and the Development Team within it are described as self organizing. Similarly, the Product Owner is self -organizing, in that they are given autonomy to do their work as they believe best. To ensure this autonomy, the entire organization must respect the decisions of the Product Owner. However, this does not mean others are not free to provide inputs to the Product Owner aiming at changing their decision

-

*

.

The Product Owner's decisions are reflected in the Artifact of the Product Backlog. Its purpose is to

• create transparency regarding what is currently understood about further product development and

• what - according to the Product Owner - will deliver the greatest value for the work of the Development Team.

To allow the Product Owner to maximize the value of the Development Team s work, they must have full control over the source of what the Development Team works on. Others forcing the Development Team to work on other things will undermine the value maximization by the Product Owner and thus impede their success.

11

for an explanation on the terms self -organization, see the definition on pages 53ff

6 The Scrum Team

70

6.2 The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done " product at the end of each Sprint. A "Done” Increment is required at the Sprint Review. In these two sentences, the Scrum Guide characterizes the Development Team in the following ways:

• It is made up of professionals. The term "professional" is not explicitly defined in this context, but likely meant to refer to an individual who is capable of doing the development work , such as preparations, organization and communication.

• Its members' primary job within the Scrum framework is to develop an Increment. The other tasks that may occur, such as assisting the Product Owner in Product Backlog refinement, are secondary to this.

Further, the Scrum Guide characterizes the Increment as having to be "Done", meaning being in accordance with the definition of "Done" 1 " . as well as potentially releasable at the Sprint Review ' 3 . This means that:

• It must be possible to release an Increment at least at the Reaching potentially releasable end of each Sprint. Increments more frequently is acceptable and even potentially beneficial if the Increments provide value and feedback can be gathered . However, the minimum required by the Scrum Guide is a potentially releasable Increment at the Sprint Review. This ensures two things:

12

see chapter on the Definition ot Done' on pages 202 ,3 see section "Sprint Review" on paoes 148tl. "

6 The Scrum Team

71

- There is an Increment to inspect during the Sprint Review to gather feedback on. - A recent, potentially useful version of a working product is always available.

• The

Increment resulting from the Sprint does not automatically have to be released , but instead, the decision to release a product into the market or to stakeholders is a decision of the Product Owner, considering a variety of factors.

Only members of the Development Team create the Increment.

This can be seen as excluding three categories of people, who may otherwise potentially be involved in the process of creating the Increment:

• People

who are on the Scrum Team, but not the Development Team , i.e. , the Product Owner and the Scrum Master

• Developers who are not part of the Scrum Team • Other people who are neither on the Scrum Team ,

,

nor

other developers, e g., parent organization 's management , stakeholders.

The exclusion of other developers can be understood as being for the following reasons:

• It creates a hard metric for cross-functionality

. A team that is not allowed to delegate tasks away will inevitably notice whether or not it is capable of delivering Increments without external help. In this sense, the exclusion creates the necessary transparency for empirical process control aimed towards cross- functionality.

6 The Scrum Team

72

• Delegating

tasks necessary for the Increment to outside developers creates an external dependency, which creates risks outside the Scrum Team s scope.

• The development

process is subject to empirical process control. A developer from outside the Development Team and hence outside the Scrum Team , would introduce new parameters into this process that would be very hard to control for and make empirical process control less The goal is to continually optimize the effective. Development Team s process, which is easiest if general parameters remain as consistent as possible.

The exclusion of the Product Owner, Scrum Master and other nondeveloper entities can be understood as being for the following reasons:

• During the Sprint Planning, the Development Team commits to the Sprint Goal. This commitment requires a high degree of control over the outcome, namely the ability to decide on how to do its work of delivering the Increment. That ability is what the Scrum Guide refers to as self -organization". ' * "

• It creates a hard metric for self-organization. A team that is not able to deliver an Increment without intervention from

non-Development- Team entities is easily identified as not In this sense , the exclusion properly self-organizing . creates the necessary transparency for empirical process control aimed towards self -organization .

• The

Scrum Guide assumes the members of the Development Team to be professionals. In its definition of empiricism, it outlines that decisions should be taken based on what is known. Therefore, the decisions on how to turn a Sprint Backlog into an Increment should be taken

14

foe an explanation on the terms self - organization, see the definition on pages 53 ff

6 The Scrum Team

73

only by the Development Team (collectively), as it is the entity with the best understanding of how to do that.

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team 's overall efficiency and effectiveness.

The first of these sentences outlines the key requirements for cross functionality and self organization. For a team to be cross-functional, it needs to be able to organize, manage and conduct their work without external dependencies. This requires the team to be structured with that particular need in mind. What this means concretely can vary widely from case to case. Under the idea of self -organization, determining what structure would be appropriate is up to the team itself.

-

-

For a team to be self -organizing, it needs to have positive and negative freedoms given to them by their organization. Negative freedoms, i.e., freedom from something, in this case, means being free from intervention from the outside, for example, from micro-management from the organization’s governance or a Product Owner or Scrum Master ordering the Development Team around and telling them how to do their work. Positive freedom, i.e., being given the ability to do something, in this case, means having a structure in place that fosters self -organization. Examples of this could be the availability of a sufficient budget to freely decide on development tools or the workspaces easy organization providing allow that communication between the team members

.

The Scrum Guide claims in the second sentence that with these conditions fulfilled, teams can work together highly effectively, generate synergy and thereby lead to an optimization of how well time and resources are used (what is called "efficiency") and of the value it ultimately delivers ( what is called "effectiveness").

6 The Scrum Team

74

Development Teams have the following characteristics:

• They are self-organizing.

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality ;

-

Just as the Scrum Team is a self organizing unit, the Development Team within a Scrum Team is self organizing with regard to how they conduct their development work. As the introduction of a Scrum Master, in the role of a servant leader ^ . is arguably one of the more drastic changes when comparing Scrum with more conventional approaches of product To clarify the hierarchical development and management. relationship, or rather lack thereof, between the Development Team and their Scrum Master, the Guide emphasizes explicitly, that the principle of self -organization protects them from orders from anybody, explicitly including the Scrum Master.

-

-

• Development

Teams are cross- functional, with all the skills as a team necessary to create a product Increment ;

-

Just as the Scrum Team as a whole has to be cross functional the Development Team within it has to be as well.

15

16

6

.

see the definition of a servant leader on pages 84f for an explanation on the terms cross- functionaiitv. see the definition on pages 53ff

6 The Scrum Team

75

• Scrum

recognizes no titles for Development Team members, regardless of the work being performed by the person

• Scrum

recognizes no sub- teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,

• Individual

Development Team members may have but specialized skills and areas of focus, accountability belongs to the Development Team as a whole.

These three points together outline key assumptions of the Scrum Guide on how the work within a Development Team is best organized . The last point outlines the understanding of accountability within a Development Team, which the team shares as a whole, not held by any individual. Not every member has to be equally capable of everything that is required for a particular piece of work, as that is neither realistically possible nor desirable.

Nonetheless, the accountability for all of the tasks of the Development Team belongs to all of the members collectively, not to any individual or group within the Scrum Team Neither the specialization of a Development Team member’s skills nor even their focus area leads to accountability to rest only in that person. Scrum understands the process of development to be owned collectively by the Development Team , which is therefore collectively accountable for the process and the results. .

A result of this collective accountability is that members of the Development Team are obligated to create transparency on their current work towards each other. Furthermore, they need to

6 The Scrum Team

76

assist each other in their tasks as necessary. The Scrum Guide underlines this need for transparency with the event of the Daily Scrum and the need for mutual assistance with the following sentence: "Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint."' 7 If members of the Development Team were to hold different titles , that would work against the idea of collective accountability. If a Development Team has a member with the title "tester", problems related to insufficient testing would be understood as a failure of that person. Instead. Scrum suggests this to be seen as a process issue that needs to be inspected and for which solutions need to be developed. This same concept applies not only to individual titles but also to sub-teams. A failure of testing might otherwise be attributed to shortcomings of the testing- team , instead of a need for a process improvement .

,rsee the corresponding quote on oaoe 139

6 The Scrum Team

77

6.2.1 Development Team Size

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.

The ultimate goal of a Scrum Team and, therefore, of a Development Team is delivering value. Thus the lower limit of the team size is determined by how many developers are needed to deliver value that is significant. The definition of "significant" is subjective; however, the evaluation of it must take into consideration the overhead that the Scrum framework. The specialization into the roles of Product Owner and Scrum Master as well as the time cost associated with the Scrum events, need to be justified by the value delivered. As a framework, Scrum does not prescribe a definitive answer but instead gives a lower and an upper limit, combined with arguments that serve both as justifications for the limits. These arguments further serve as criteria for a Scrum Team to evaluate its own ideal size.

Fewer than three Development Team members decrease interaction and results in smaller productivity gains.

Scrums benefit lies in maximizing value by fostering, among other things, communication and synchronization. When only two developers work in the development, this factor loses its potency, and the lack of productivity gain does not justify the overhead of Scrum.

6 The Scrum Team

78

Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment.

-

A Development Team is defined as being cross functional 13 and delivering an Increment. ' If a Development Team is small, the necessary skills may be absent all together or not available sufficiently to deliver an Increment. Example: A three person Development Team works on a piece of software, which requires expertise in frontend development, backend development and databases. Each developer is an expert in one of these categories, making the team To deliver an Increment, however, more cross functional. capacity in the frontend development is required. This may be solved by adding another developer who is savvy in frontend development, bringing the total number of developers to four.

-

-

-

This sentence is not intended to argue that smaller teams will inevitably encounter this issue; instead, it outlines that:

• when evaluating the proper team size, the possibility of the team being too small relative to the required skills should be considered, and on the other hand that

• when a

team runs into problems with not being able to deliver Increments due to skill constraints, the reason may lie, among other things, in the team size being too small.

18

foe an explanation on the terms cross - functionality see the definition on pages 53ff. 19 see definition of a Development Team on page 70 ,

6 The Scrum Team

79

Having more than nine members requires too much coordination.

A number of nine developers is given as the absolute upper limit. This limit is not determined by any calculations, but rather has established itself from practical experience using empirical process control.

Large Development Teams generate too much complexity for an empirical process to be useful.

The method that Scrum uses for continuous improvement is empirical process control - transparency, inspection and adaptation20 . In practice, the empirical approach is to alter individual parameters of a process and inspect the results. This is especially useful when the other parameters that are not altered and remain relatively constant , allowing for comparison and. therefore, inspection. Larger Development Teams consist of many people and conduct many activities. With this, a large number of factors are introduced into the system of the team. Applying empirical process control would mean either to change only a small set of the many parameters or to change a larger number of the many parameters. Changing only a small set of parameters at the same time and keeping most other parameters constant allows for the generated results to be more meaningful. This approach however, comes at the cost of relatively few changes every iteration and, therefore, only relatively slow improvements. The benefit that Scrum is supposed to bring is quick adaptability and rapid self-organizing improvements. Changing only a small set of parameters is, therefore, in its result contrary to the idea of a Scrum Team . Therefore, the consequence would be a loss of flexibility, for which Scrum aims to maximize.

“see the section on empirical process control on pages 24H

6 The Scrum Team

80

Changing a larger set of parameters at the same time makes it challenging to infer which change may have been beneficial and which may even be counter-productive. The results of such a process are much less meaningful and undermine the effectiveness of empirical process control.

This sentence is not intended to argue that these problems can only occur when a team has more than nine developers, nor that any team of nine developers will inevitably face these problems. Instead, it gives a guideline to consider:

• when evaluating the proper team size, the possibility of the team being too large relative to the complexity of the development process should be considered, and on the other hand that

• when

the process of developing a product becomes too complex for empiricism to be practical, the reason may lie , among other things, in the team size being too large.

The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog. The Development Team does not include the Product Owner or the Scrum Master unless they are working on the Sprint Backlog . This sentence indirectly clarifies that the Scrum Guide allows for two combinations of a Scrum Team member fulfilling two roles: Product Owner and Development Team member on the one hand , and Scrum Master and Development Team member on the other. The Scrum Guide does not give explicit guidance of whether either of these combinations is useful and leaves that determination up to the individual teams using Scrum.

6 The Scrum Team

81

6.3 The Scrum Master

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. All of the responsibilities of the Scrum Master within an organization fall under one of two categories described in this sentence, which need to be continually done in parallel to each

other:

• They are

supposed to promote Scrum. This means they are responsible for strengthening the understanding of the ideas behind the framework , as well as spreading the ideas of Scrum beyond the scope of their own Scrum Team. This summarizes work such as educating and coaching team members, the organization and stakeholders and working with management to spread Scrum.

• They are supposed to support Scrum. This means they are responsible for maintaining Scrum within their teams and organizations by fulfilling such tasks as facilitating events and removing impediments.

Scrum in this context is again to be understood as what is defined in the Scrum Guide. The responsibility of the Scrum Master is, therefore, to conduct their activities in accordance with the Scrum Guide as well as promote and support the ideas in the Scrum Guide as the "true Scrum". In this sentence, the Scrum Guide does not explicitly limit the scope of these responsibilities to the organization. This can be understood as an obligation of Scrum Masters to spread the ideas of Scrum even beyond the scope of their respective organizations. A practical example of this could be helping people new to Scrum gain greater insight by attending and actively participating in local Scrum working groups.

6 The Scrum Team

82

Furthermore, this lack of limitation and the insistence on understanding Scrum as what is defined in the Scrum Guide can be understood as implying another meaning behind this sentence. The strict and repeated insistence of the Scrum Guide to be the definittve source of Scrum is partly due to these two reasons:

•A

large set of sometimes contradicting practices is informally referred to as being a part of Scrum. For example , the use of the user story format for Product Backlog items is common practice in many Scrum Teams and is a valid approach within the Scrum framework but is, strictly speaking not part of Scrum. ,

• In practice.

Scrum adoption often ends at a certain point . Some organizations may choose to adopt the events, but not the terminology. Others may choose to work iteratively and Incrementally, but still have a team managed by a project manager.

In light of these, the sentence in the Scrum Guide can be interpreted as placing on Scrum Masters the responsibility to hold each other accountable to understanding Scrum only as it is defined in the Scrum Guide. The intent may be to create a social pressure within the Scrum Master community, to inspect each other and support each other in understanding Scrum as what is defined by the Guide.

Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The creators of Scrum believe that the Scrum Guide outlines a logical, consistent response to the issue of addressing complex problems in product development . Therefore , a Scrum Master does not need to be equipped with hierarchical authority to force Scrum onto teams and organizations. Instead, spreading and supporting Scrum can be done by helping others understand:

6 The Scrum Team

83

• Scrum

theory, namely the empirical process control of transparency, inspection and adaptation

• Practices, such as the events and artifacts of Scrum • Rules, which bind the framework together and define the relationship between events , artifacts and roles

• Values,

which together with empiricism set the foundation for Scrum, by providing guiding principles for those things , tor which the Scrum framework does not prescribe specific methods or tools

The implicit idea behind this sentence is that once somebody understands the ideas of Scrum, they will be willing to try it at least . Therefore , no hierarchical authority is required. The use of the word "everyone" does explicitly not limit the scope of whom Scrum Masters are supposed to help understand Scrum. This can be understood as meaning, that a Scrum Master is not only responsible for helping those within their teams or organizations, but everyone who is willing to listen. The creators of Scrum , Jeff Sutherland and Ken Schwaber. describe Scrum as a better approach to product development . They state that this is not only because Scrum helps deliver value more efficiently, but also because it creates better conditions for those working within the Scrum framework. [81

Therefore, this sentence can be seen as a call to spread Scrum also outside of one's own immediate surroundings, to create a better working culture not only in one s own organization but also on a larger, societal scale.

6 The Scrum Team

84

The Scrum Master is a servant-leader for the Scrum Team.

The idea ot a servant-leader goes back to Robert K. Greenleaf , a long-term manager at the American telecommunications company AT& T, who outlined the idea in a 1970 essay titled 'The Servant as Leader”, followed by a book on the matter, describing it as follows: servant-leader is servant first. It begins with the natural feeling that one wants to serve. Then conscious choice brings one to aspire to lead . The best test is: do those served grow as persons : do they, while being served , become healthier , wiser, freer, more autonomous , more likely themselves to become servants ? And. what is the effect on the least privileged in society: will they benefit , or, at least , not be further deprived ?' \ 91 "The

The Scrum Guide defines that a Scrum Master must act as a servant-leader for their team. They are not the master of their team , i.e„ they do not hold any hierarchical authority over them, but rather of the ideas and values of Scrum and of transmitting those.

As a servant-leader the Scrum Master takes care of the needs of others in order to allow them to grow. They are someone who defines their own success through the success of others they helped enable The Scrum Master drives the team towards better processes and interactions and, consequentially, a higher value delivery, making them a leader on the team . ,

The manner in which this is done, however , is not through hierarchical authority, but by assisting the team from a servant position. This is manifested by the kind of tasks in the Scrum Master’s responsibilities, such as impediment removal for the team, facilitating the meetings of the team and educating the team as well as its surroundings to allow the team to improve their own interactions and processes.

6 The Scrum Team

85

The approach of a Scrum Master under the servant-leadership paradigm is one that aims to strengthen the self -organization of the team, guiding it towards the ability to solve as many problems of their own as possible. In this spirit , the position of the Scrum Master was created without any formal authority over anything, as opposed to the Product Owner, who owns the Product Backlog and the Development Team who own their Sprint Backlog. The Scrum Master leads by enabling others through their services.

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren't. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. A Scrum Team usually exists within the scope of a larger organization, leading to interactions between the Scrum Team and other parties. Scrum outlines general guidelines for the interactions of Scrum Teams and other parties, such as a need to respect the self -organization of a Development Team or the decisions of a Product Owner. Interactions going against these outlines would impede value delivery in the long term and thus would not be helpful.

On the other hand , Scrum relies heavily on feedback from stakeholders, which they may be hesitant to give as they may be uncomfortable, especially if they are not familiar with Scrum or other agile approaches to product development These , , . interactions however would be very helpful ,

It is the Scrum Master 's obligation to maximize the efficiency of the work of the team by improving helpful interactions and preventing unhelpful ones as much as possible. The approach they are supposed to take here is in line with the idea of a servant-leader2 1 , as the Scrum Master does not force these 21

see the definition of a servant -leader on pages 841.

6 The Scrum Team

86

changes, which in the case of preventing behavior might be possible through sufficient hierarchical authority.

Instead, they support the outside parties' understanding of the impacts of their interactions:

• of the negative consequences of unhelpful behaviors, which sometimes only occur in the long run and thus need to be placed in a context by the Scrum Master , as well as

• of

the positive possitxlities of helpful interactions on the long- term value delivery

6 The Scrum Team

87

6.3.1 Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways , including:

-

The Scrum Master is the servant leader for their Scrum Team and. as such, provides support for those on the team, namely the Product Owner and the (members of the) Development Team. In the following, the Scrum Guide provides a non exhaustive list of how the Scrum Master can be of service to the Product Owner.

-

For all items on this list, the Guide does not specify concrete implementation methods, but as a framework merely defines the basic requirements.

• Ensuring

that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;

-

Scrum is predicated on the idea of a self organizing team.1" In order for the Scrum Team to make the best possible decisions, all members need to understand the ideas behind what is being buitt, including the goals, scope and general product domain.

This is primarily a service to the Product Owner, as it improves their work of maximizing the value of the Development Team s work . A team with a proper understanding of the product and its development is better able to contribute to the decision making. Example: a Development Team that understands the (business) goal of the upcoming Sprint will be able to offer more suiting

22 foe

an explanation on the terms self -organization, see the definition on pages 53 ff .

6 The Scrum Team

88

solution proposals and more accurate estimates, allowing the Product Owner to maximize the value of the Development Team s available capacity.

• Finding

techniques for effective Product Backlog

management;

A core responsibility of the Product Owner role is the management of the Product Backlog.23 The Scrum Guide does not prescribe specific methods or techniques to be used for Product Backlog management. There are, however, qualitative differences between different approaches, measured by their effectiveness at creating transparency about the current plan for the future of the product.

The Scrum Master is tasked with supporting the Product Owner in their role by finding techniques for effective Product Backlog management and explaining the benefits of them. This allows the Product Owner to manage their Product Backlog better and, therefore, more effectively maximize the value of the work of the Development Team. Example: Maintaining a list of Product Backlog items in a shared text document may suffice to give the stakeholders and Development Team a rough idea of the current priorities. While in the early phases of product development , this may be enough . As the product matures and the Product Backlog becomes larger, the text document may not be able to create enough transparency, e g. , about the relationship between individual items. It is the Scrum Master's responsibility to explain this emerging need to the Product Owner and work with them to introduce a new technique for Product Backlog management , e .g,, a system in which items are categorized by how far they

23

see the section on Product Backlog management on page M

6 The Scrum Team

89

have been broken down in refinement, in which dependencies between items are easily visible and in which a proper search and filter functionality exists.

• Helping the Scrum Team understand the need for clear and concise Product Backlog items;

The quality of Product Backlog items has effects on the Development Team's ability to provide estimates and implement the items as part of their Sprint Backlog. Items that are clearly expressed allow the Development Team team to understand the requirements they represent and make development decisions accordingly. Product Backlog items should be understandable by the Development Team as much as possible, ideally to the degree where the Development Team can implement them without frequently consulting the Product Owner. On the other hand, Product Backlog items should be concise, i.e., limited to transmitting the requirements they represent, without giving a prescription on how the item is to be implemented. A balance must be found between too little detail and too much.

Scenarios exist in which either the Product Owner, the Development Team or both want for Product Backlog items to be much more or much less detailed than is most beneficial. The Scrum Master 's responsibility in all of them is to teach both parties about the purpose of Product Backlog items and the subsequent need for a proper balance. This allows the Product Owner to provide the Development Team with enough detail to allow them to develop the product properly while limiting the time the Product Owner needs to spend on writing Product Backlog items. Example; A Development Team expects a high degree of detail in the Product Backlog items. The Product Owner complies and is

6 The Scrum Team

90

not only writing requirements but goes as far as to include pseudo-code, which the Development Team takes and turns into proper syntax . This creates a heavy workload on the Product Owner, while at the same time limiting the self-organization of the Development Team. The job of a Scrum Master in such a scenario would be to make both the Development Team and the Product Owner understand what the purpose of a Product Backlog item is and. subsequently, why it should be concise. The Scrum Team would then transition to more concise items , freeing the Product Owner to spend their time working with stakeholders to understand their needs better .

• Understanding

product planning in an empirical

environment;

The supposed benefit of conventional product planning is predictability. A plan is crafted with a clear timeline when things will be ready. Stakeholders still used to this way of thinking will expect clear timelines from the Product Owner, who themselves may be inclined to desire a high degree of predictability.

The responsibility of the Scrum Master in this regard is to support the Product Owner 's understanding of how product planning works within Scrum. The basis for Scrum is empirical process control, which applies to individual components within the product development as well as the overall product development itself. As new things are learned about the product and its development , plans may need to change . Therefore, extensive predictions about steps far in the future cannot be made with any certainty. Instead , the development is oriented towards maximizing value based on what is currently understood. The Scrum Master supports this understanding in the Product Owner and, if necessary, in the (key ) stakeholders. When both the Product Owner and the (key) stakeholders understand the

6 The Scrum Team

91

approach to planning in empirical environments, transparency is created, since both parties have the same understanding

.

Example: The Product Owner of a product has a high understanding of how planning in empirical environments works. However, the key stakeholders of the product do not. When the Product Owner forecasts future releases during a Sprint Review, the Product Owner understands this as a forecast, which may change as things evolve. The stakeholders, however, understand this as a certainty. When things eventually do change, and the Product Owner subsequently changes the release plans, the stakeholders are upset about this. Here the Scrum Master needs to work with the stakeholders, help them understand why exact plans are not possible and/or not beneficial and that forecasts contain no certainty. The Product Owner and the stakeholders now have the same understanding of what a "plan" is. This transparency of the terminology allows for improving the working relationship and therefore improves the capabilities of the Product Owner to maximize the value of the work of the Development Team.

• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;

The goal of a Product Owner is to maximize the value of the product. For this, they need an understanding of what constitutes value and how that value is best achieved. The responsibility of the Scrum Master is to ensure that the Product Owner has a definition of value and an understanding of how to use the Product Backlog to reflect the next steps in order to realize that value. Example: A product has two different types of users, one group uses the product very rarely and does not generate a lot of income, while the other group uses the product extensively and hence generate a lot of income and profit per customer. The

6 The Scrum Team

92

Product Owner of this product uses the metric of profit to determine value. The Scrum Master needs to ensure that the Product Owner knows how to arrange the Product Backlog to maximize this value. This knowledge would likely manifest in a high priority given to items that serve the high-use group over those serving the low-use group. Furthermore, an indicator could be that the Product Owner uses different tags for items that serve the two groups, allowing them to more easily visualize the items generating high value.

• Understanding and practicing agility; and, Sutherland and Schwaber, the co-creators of Scrum, are original signatories to the Agile Manifesto (source footnote ). The ideas laid out in its values and principles are reflected in various aspects of Scrum. For example , the fourth comparison in the Agile Manifesto reads ~[ Responding to change over following a plan", which manifests itself in Scrum's use of a Product Backlog as a living artifact and in the continuous adjustment of the Sprint Backlog during the Daily Scrums. An understanding of agility is beneficial for the Development Team and the organization to have. However, the Guide outlines it as a service by the Scrum Master only for the Product Owner. This is due to the fact that most aspects of agility - as it is understood in the Agile Manifesto - deal with the interaction between the (key ) stakeholders on one side and those responsible for the product development , represented mainly by the Product Owner, on the other.

The Scrum Master 's responsibility is to support the Product Owner's understanding of agility, referring especially to the mindset and subsequent practices regarding collaboration with stakeholders, flexibility towards requirement changes and frequent releases to gather feedback .

6 The Scrum Team

93

Example: A Product Owner , who previously held the title of project manager and remained in the mindset of conventional product management , gathers inputs for the next release of their product . Once all the requirements appear to be gathered, the Product Owner sets up a plan for the next 6 Sprints of what the Development Team will work on. After two Sprints, a key stakeholder provides an urgent input , that would lead to a change in the Product Backlog and subsequently in the Product Owner's planned timeline. The Product Owner plans to reject the input and inform the stakeholder that the changes would be included in the next release, as was agreed in the original contract . The Scrum Master must work to help the Product Owner understand agility and support their practice of it. In this case, that means explaining to the Product Owner that changes late in the production process should be welcomed (principle 2), that they should work with the customer to integrate the new requirements rather than insist on what the contract says ( value 3) and perhaps even encouraging the Product Owner to increase release frequency from every six Sprint to a faster pace (principle

D-

• Facilitating Scrum events as requested or needed. This is a service the Scrum Master may provide for both the Product Owner and the Development Team. The Product Owner is actively involved in three of the four Scrum Events within a Sprint:

• During

the Sprint Planning, the Product Owner presents their (business ) objective for the upcoming Sprint , collaborates to craft a Sprint Goal and provides inputs for the Development Team to make decisions when creating an initial plan for the Sprint Backlog.

6 The Scrum Team

94

• During the Sprint Review, the Product Owner presents an overview of what was achieved throughout the Sprint , presents the planned next steps for the product development and collaborates with the Development Team and present stakeholders on what the likely next steps will

be.

• During

the Sprint Retrospective, the Product Owner participates as a member of the Scrum Team, aiming to improve the overall process.

The Scrum Master may support these events through facilitation if they are requested to do so by a member of the Scrum Team . Furthermore, the use of "or needed " implies that the Scrum Master may choose to proactively take the facilitator role if they deem it necessary.

The facilitation is a service to the Product Owner because it allows the Product Owner to more effectively live out their role if the Scrum events function more properly due to the Scrum Master 's facilitation than without it. Example: The Product Owner usually facilitates the Sprint Review. Recently, the Scrum Master started noticing personal conflicts between the Product Owner and a key stakeholder. This conflict eventually leads to the Product Owner actively ignoring the stakeholder during the Sprint Reviews, undercutting their possibility to contribute their feedback . Upon providing the Product Owner with feedback on that observation , the Product Owner may request that the Scrum Master facilitates the Sprint Review for the next few times, while the Product Owner works out their differences with the stakeholder. The neutral facilitation by the Scrum Master allows the previously stifled stakeholder to provide their inputs , allowing the Product Owner to take them into consideration, let the Product Backlog more accurately reflect the current priorities and subsequently deliver a higher- value product.

6 The Scrum Team

95

6.3.2 Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including: The Scrum Master is the servant-leader for their Scrum Team and. as such, provides support for those on the team , namely the Product Owner and the ( members of the) Development Team. In the following , the Scrum Guide provides a non-exhaustive list of how the Scrum Master can be of service to the Development Team . For all items on this list, the Guide does not specify concrete implementation methods, but as a framework merely defines the basic requirements.

• Coaching

the Development Team in self-organization and cross- functionality;

Scrum Teams as a whole need to be self-organizing and cross- functional.^' On the level of the Scrum Team, this means that the team must have a Product Owner capable of product management , a Scrum Master capable of fulfilling their obligations to the team and organization and a Development Team that is capable of doing the work of developing the product. In order to do this efficiently, the Development Team needs to be self -organizing and cross- functional.

The Scrum Master's responsibility is to coach the Development Team in these aspects The concrete methods are not prescribed; however the use of the term "coaching" indicates that ,

,

24

see section 6 on page §2

6 The Scrum Team

96

the Scrum Master is supposed to take a guiding approach and provide feedback . The idea is to enable the team and help them help themselves. Example: A Development Team working on a product repeatedly fails to reach their Sprint Goal due to external dependencies. Upon inspection, it is realized that the external dependency is not unavoidable, but due to a lack of a particular skill within the team. The Scrum Master now needs to work with the Development Team to help them understand the need for cross-functionality to reliably deliver high- value product Increments. The Scrum Master must then support the team in finding an appropriate solution, which could be that the team decides on one of its members to spend one day per week acquiring the skill that the team is lacking. This allows the team to gradually transition (back ) into a state of cross- functionality.

• Helping

the Development Team to create high- value products;

The Development Team is responsible for delivering Increments of the product. The value of the Increment is determined by which additional features and capabilities it possesses, as well as the quality of these. The choice of features is determined by the Product Owner, while the quality is largely up to the Development Team .

The Scrum Master 's responsibility towards the Development Team is to support them in delivering high- value products, which may be done in a variety of ways among others: ,

• Ensuring

the Development Team understands the items selected for a Sprint , including the motivation for choosing Understanding of the business side of the them. requirements guides the Development Team in their decisions during implementation.

6 The Scrum Team

97

• Ensuring the Development Team understands the concept of a Definition of "Done" and the need to tighten it over time. This increases the quality of the product delivered and. therefore, its value.

• Supporting the Development Team in automating redundant tasks to free more time for product development. Example: A Development Team has repeatedly been delivering Increments that initially satisfy the stakeholders: however, after a while, each time technical errors are revealed. The stakeholders become dissatisfied with the overall state of the product . In their eyes, the value of the product has dropped due to quality concerns. The Scrum Master is then responsible for working with the Development Team to help them understand quality as a key metric for value and work with them to tighten their definition of "Done". One key aspect of this is testing , which has been conducted insufficiently, as no member of the Development Team has been willing to do repeated manual testing. The Scrum Master works with the team to develop a concept for automated testing, which increases the quality of the delivered Increment while limiting the amount of time spent on testing by the Development Team , allowing them to deliver more features and capabilities instead and therefore more valuable Increments.

• Removing

impediments to the Development Team ’s

progress:

Impediments are anything that stands in the way of the Development Team delivering value. This includes , but is not limited to:

• improper

working conditions, such as a non- working airconditioning system

6 The Scrum Team

98

• external requests, potentially taking away capacity from the Development Team

• technical problems, such as broken hardware • communication

problems between members of Development Team or with the Product Owner

the

The Scrum Master s service to the Development Team is working towards the removal of these impediments. This does , however, not require the Scrum Master to remove all impediments themselves. A valid approach, in line with bullet one of the list of services to the Development Team, is to support the Development Team by helping them remove their own impediments wherever possible. Should impediments arise that are beyond the reach of the Development Team, however, the Scrum Master is responsible for taking action. Example: During the Daily Scrum , an impediment is identified: for proper software testing, the members of the Development Team require one more monitor each. The Scrum Master will help the Development Team determine how to solve this impediment. One member is determined to request additional hardware from the tech support. The tech support replies that the request is not possible to be fulfilled due to budgetary constraints. In this case, the Scrum Master takes ownership of the issue and reaches out to the person in charge of the budget , explains the Development Team s needs and works towards finding a solution on behalf of the team .

• Facilitating Scrum events as requested or needed; and, This is a service the Scrum Master may provide for both the Product Owner and the Development Team. The Development Team is actively involved in all of the four Scrum Events within a Sprint:

6 The Scrum Team

99

During the Sprint Planning, the Development Team provides its forecast , collaborates to craft a Sprint Goal and defines an initial plan to reach the Sprint Goal. During the Daily Scrum , the Development Team inspects the progress towards the Sprint Goal and makes adjustments if necessary. During the Sprint Review, the Development Team presents what they worked on, demonstrates the new Increment , collaborates with the Product Owner and stakeholders on what the likely next steps will be.

During the Sprint Retrospective, the members of the Development Team participate as a member of the Scrum Team , aiming to improve the overall process.

The Scrum Master may support these events through facilitation if they are requested to do so by a member of the Scrum Team. Furthermore, the use of "of needed" implies that the Scrum Master may choose to proactively take the facilitator role if they deem it necessary. The facilitation is a service to the Development Team , because it allows the Development Team to more effectively live out their role if the Scrum events function more properly due to the Scrum Master 's facilitation than without it . Example: The Development Team provides a forecast during Sprint Planning. They feel pressured by the Product Owner to increase that forecast in order for the Scrum Team to meet predefined deadlines. This pressure persists: throughout the meeting, the Product Owner pressures the Development Team to take on more work than they feel achievable. In this case, the Scrum Master should intervene and facilitate the meeting. In a second step, the Scrum Master should work with the Product Owner on their understanding of the roles and their respective responsibilities. The intervention of the Scrum Master, taking over the facilitation

6 The Scrum Team

100

of the event, allows the event to progress and ensures that the Development Team is allowed to choose as many items as they believe are achievable.

• Coaching

the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Environments with low understanding and adoption maturity of Scrum place a significant burden on the way the Development Team works. Scrum defines the Development Team as self -organizing, meaning they have the skills to organize their own work on one side, but on the other side also have the organizational empowerment to make those decisions for themselves. In environments that lack understanding of the intrinsic logic of Scrum, it is likely that outside influences will attempt to influence the decision making

.

The responsibility of the Scrum Master is to help the Development Team understand the need for and benefits of a self organizing team but beyond that also help them address the specific challenges that the organizational environment places on the Development Team.

-

^

Example: A Development Team in an organization that has very recently introduced Scrum is struggling with a manager repeatedly trying to intervene in their work or trying to force some of them to do work outside the Sprint. Some members of the Development Team are complying with the requests, wanting to avoid troubles. The Scrum Master now needs to work with the Development Team to help them understand the reasons for avoiding such behavior. Furthermore, they need to work with the team to find a

25

see bullet one

6 The Scrum Team

101

solution to the problem, e.g., by preparing the Development Team and planning and facilitating a meeting between the manager and the Development Team on this topic, aimed at gaining a commitment from the manager to stop their behavior.

6 The Scrum Team

102

6.3.3 Scrum Master Service to the Organization

• Leading

and coaching the organization in its Scrum

adoption;

In this sentence , the Scrum Guide argues that the Scrum Master should work towards an improvement of the organization s adoption of Scrum. It uses the verbs "leading" and "coaching" to describe the activities related to this. By using leading", the Scrum Guide ascribes to the Scrum Master the responsibility to actively push forth the adoption of Scrum . This is particularly relevant in the early stages when Scrum is being introduced or is still very newly adopted. By using "coaching", the Guide refers to the long-term service to the organization, helping it consistently improve in its adoption of the Scrum framework in its context.

The expression "Scrum adoption” has to be differentiated from "Scrum implementation", as mentioned in the following bullet. By "Scrum adoption”, it refers to the broader organizational attitude towards Scrum and its use within the organization. The methodology to be chosen is left up to the Scrum Master. It does, however, usually involve working with existing management structures as well as potentially with (key ) stakeholders from internal and external stakeholders.

Example: A company has decided to introduce Scrum. The Scrum Master must lead the adoption of Scrum by proactively working with the management to help them understand the ideas behind the Scrum framework and the subsequent necessities for changes on the organizational level. Once the first Scrum implementations have been conducted and Scrum Teams take up their work , the Scrum Master remains in regular contact with key players relevant to the adoption of Scrum and helps them better understand Scrum, its theory, its uses and its requirements.

6 The Scrum Team

• Planning

Scrum organization;

103

implementations

within

the

The Scrum Master supports the organization by taking on the responsibility of planning Scrum implementations. By "Scrum implementations", the Guide refers to the use of Scrum for the development of a specific product and the subsequent creation of one or more Scrum Teams for that purpose. Scrum Teams are self-organizing once they have been established and use empirical process control to improve their process as well as potentially their own composition. The Scrum Master , however, takes the lead in planning this initial set-up. As the Guide does not specify further what is involved in this planning, this could be understood as anything between

• defining

the staffing , initial Sprint length and other key

parameters of the Scrum Team( s)

• merely initiating the process and creating the surroundings, such as a time, a location and the proper atmosphere, for people to self-organize into Scrum Teams. Ken Schwaber , one of the co-creators of Scrum, makes a point in support of the latter understanding in one of his blog posts. In it , he poses the question of how best to divide 100 developers into Scrum Teams. His answer is to create proper conditions, such as ensuring a common understanding of the product and its technical requirements, and then allow them to self -organize into teams.1101

6 The Scrum Team

104

• Helping employees and

stakeholders understand and enact Scrum and empirical product development;

In the second sentence of the Scrum Master section, the Guide defines a Scrum Master as someone responsible for "helping everyone understand Scrum theory, practices , rules, and values ." 6 In the services to the organization, this manifests in the Scrum Masters responsibility to increase the understanding of employees and stakeholders about Scrum and the subsequent implications of using an empirical approach to product development.

The Scrum Master is further responsible for helping these parties enact Scrum, which mirrors a prior description of the Scrum Master as helping "those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren't".27 This is highly contextual and depends on the relation between the individual in question and the Scrum adoption or implementation. Example: A Scrum Master enters an environment where Scrum has only recently been introduced. The product development is working well; however, the stakeholders are hesitant to provide feedback and engage in the Sprint Reviews. The Scrum Masters responsibility is to help the stakeholders understand Scrum and their role in it and work with them to find a way how they can better serve their function. The stakeholders and Scrum Master collaborate to come up with a working agreement regarding their feedback on product releases and together develop a proposal on how to change the format of the Sprint Review to allow for more feedback from the stakeholders.

26 2

see page fi2 see pace 85

6 The Scrum Team

105

• Causing change that increases the productivity of the Scrum Team; and,

This sentence describes the responsibility of the Scrum Master to initiate changes aimed at increasing the Scrum Team's productivity. Placing this sentence in the list of services to the organization reflects the understanding of the Scrum Team's place in the organization: the creation of some value in the organization takes place within the Scrum Team(s). The goal of the organization is to deliver a value, which in cases of a for-profit organization is delivering something that will generate profit . At least part of this value is created by the Scrum Teams, which means that increasing the productivity of the Scrum Teams directly serves the organization in achieving its Making changes towards increasing productivity is, goals. therefore, a service to the Scrum Team, as well as to the organization. The change mentioned may be of any kind, including changes to internal policy, hiring guidelines, working agreements and even the company structure. Example: A company is developing one product with a total of 7 Scrum Teams. There are also a sales department , an HR department , a marketing department and a management layer. The Scrum Master determines that the different departments do not collaborate well with each other and with the teams. The marketing department and the sales department do not work well with the Product Owner, the HR department hires new developers without consultation of the Scrum Teams , and the management insists on having to sign off on many non-crucial decisions. The responsibility of the Scrum Master is now to find and implement a way to better integrate the marketing and sales department into product development. Furthermore, they need to work with HR to ensure that the

6 The Scrum Team

106

Scrum Teams, and especially the Development Teams, are involved in the recruitment process by making their needs transparent , defining their requirements and collaborating with the HR department on candidate selection. Lastly, the Scrum Master needs to work with the management to gradually transition more decision-making ability into the Scrum Teams, allowing them more self-organization.

• Working

with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

The work of Scrum Masters can be broadly categorized into two spheres: the work within their Scrum Teams and the work outside their Scrum Teams. Many topics are exclusively located within a Scrum Team, such as the quality of the Daily Scrum or the effectiveness of Sprint Retrospectives Beyond that , however, there are topics affecting multiple teams. To address these issues , the Guide requires the Scrum Masters to work together to increase the effectiveness of Scrum's application. This serves to increase the value created by the Scrum Teams and therefore serves the goals of the organization . Example: An organization has two Scrum Teams working on its product , supported by one Scrum Master. Due to the success and growing demands from the market , it has to scale its production and, subsequently, its number of developers. Within a short time, the organization has five Scrum Teams working on its product, supported by a total of three Scrum Masters. These new conditions pose new challenges to the application of Scrum within the organization. Whereas before, coordinating the work of two Scrum Teams was done easily, coordinating five teams creates problems. The Scrum Masters need to work together to devise a concept for addressing these problems, such as the implementation of a scaled Scrum framework.

7 Scrum Events

107

7 Scrum Events Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. Scrum is an iterative framework. The iteration is the Scrum event called "Sprint , which acts as a container for the other four events. Every iteration has the same order of events, which creates a regularity.

-

The term "prescribed events" indicates that these meetings are not optional, but mandatory

.

Every Sprint begins with a Planning, usually contains multiple Daily Scrums . always contains a Review and always ends with a Retrospective. This regularity is intended to reduce complexity and support the creation of flow. Scrum s goal of value delivery is best achieved when teams get into a flow of work, without being interrupted regularly by other meetings. The events are created to cover all the basic needs a Scrum Team may have regarding meetings. Depending on the context, other meetings may still be useful and take place. However, the need for other meetings is strongly reduced, and hence the number of overall meetings and the time spent on meetings is reduced.

Theoretically, a Spnnt could be two days long and thus only have one Daily Scrum, or even just one day long and therefore have no Daily Scrum. The Scrum Guide prescribes though that a Sprint must be long enough to deliver significant value, which in practice is not the case with Sprints that short.

7 Scrum Events

108

All events are time-boxed events, such that every event has a maximum duration.

All five events defined by the Scrum Guide contain time-boxes, meaning a maximum duration defined in the Scrum Guide. The meetings may not exceed this duration. The time- box can be seen in three different (not mutually excluding) ways :

• Knowing

the maximum duration of a meeting creates predictability and allows for planning appointments without leaving buffer time in between them.

• The time-box serves is an instrument for transparency.

If a meeting exceeds the defined time, an intuitive response may be to extend the meeting if possible or to set up a follow- up meeting. While this may solve the immediate problem addressed by the meeting, it does not work towards addressing the underlying issues that lead to the meeting taking longer than planned. An enforced time-box may lead to meetings being unfinished when the time-box expires, which indicates that the meeting's efficiency is not at an appropriate level . It thus provides transparency about the need to improve the meetings, i.e.. for inspection and adaptation.

• In

1955 British historian Cyril Northcote Parkinson published an article in The Economist , coining what is today known as "Parkinson's Law", arguing that "work expands so as to fill the time available for its completion ".[ 111 In a subsequent book , he elaborates with examples his observations that work tends to grow in (often unnecessary ) complexity until it fills the time available, even though the original problem could have been addressed with much less complexity and thus much less time.f 121 Placing a time-box on the Scrum Events can thus be seen as forcing a limit on the growth of ( unnecessary ) complexity, therefore establishing a focus on the crucial aspects and, in turn, saving time.

7 Scrum Events

109

Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

The iterative nature of Scrum allows for Sprints to be compared with each other, which provides the basis for empirical process control. Having similar conditions, among other things, a consistent length of Sprints, allows Sprints to be compared and hence allows for possibilities to inspect and adapt. The duration of Sprints can be adjusted before the beginning of a Sprint, though this should not be done frequently.

The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

Unlike the Sprint itself , the other four events may end before the defined time-box has expired. Thus, there are two reasons for an event to end: the time-box has expired , or the goal of the event was achieved. The Scrum Guide gives maximum durations to limit the time spent on things that do not work towards concrete value delivery. Thus, an upper limit exists to ensure empirical process control regarding the efficiency of the events. If , however, an event ends prior to its time-box expiration, more time can and should be spent on work towards value delivery.

Other than the Sprint itself , which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection.

The Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective all provide opportunities to inspect and adapt parts of the product development process. They are set up

7 Scrum Events

110

to cover, collectively, all necessary inspection. Using the term opportunity” emphasizes that the events should not be understood as something where inspection and adaptation could "formal

theoretically take place , but that instead they are. as the second sentence outlines, specifically designed in order to serve as

opportunities for empirical process control.

Scrum is addressing complex problems: , therefore very little is certain in the development process, and constant adjustments need to be made to improve the process towards value delivery.

The areas inspected by each event are addressed in the respective sections of the Guide and their explanations.

Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt .

The Scrum Guide repeatedly emphasizes the idea that "Scrum is ... immutable meaning that adopting only parts of the practices and ideas outlined by the Scrum Guide is not Scrum and will not lead to the same results as adopting Scrum properly would. With regard to the events, this holds true, as the events are crafted to complement each other and to collectively cover all necessary inspections to maintain the development process.

^

In practice, the most commonly adopted practice described in the Scrum Guide is the Daily Scrum, sometimes under the title of "Daily" or " Stand- Up”, the most commonly left out is a Retrospective at the end of each Sprint. Not including a Retrospective in each Sprint may save time in the short run, though it means that the process of the team might not be inspected, and consequently, no adaptations may be made. This

2 3

see explanation of complexity In the Cynefm Framework on pages 7ft. see chapter Endnotes on page 207

7 Scrum Events

111

is what the Guide describes when speaking of a lost opportunity to inspect and adapt .

7 Scrum Events

112

7.1 The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created.

Scrum is an iterative framework, with the iteration being called a " Sprint " . It acts as a container for all Scrum events as well as the development work.

The title "Sprint” can be interpreted by understanding the characteristics of a sprint in racing, for where the term is borrowed . Unlike, for example a marathon, a sprint is relatively short in duration. A project managed in a waterfall approach will potentially run for years before delivering value to the customer , whereas a Sprint delivers a piece of value - an Increment - in a relatively short amount of time. ,

Jeff Sutherland describes the origin of the term as follows: "And so my team embarked on what we called "sprints”. We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and stop to see where we were." Q 3J

The Sprint is limited to one month or less. The exact timeframe chosen must be long enough to allow the Scrum Team to create an Increment that is "Done” according to the definition of "Done” and which could be released into the market. This evaluation is made by the Scrum Team. On the other side, a Sprint should ideally be short , as this allows for faster feedback and therefore a development closer to the stakeholders' needs, as well as limiting the risk of waste, in case the result of a Sprint is not according to the needs of the stakeholders at all.

7 Scrum Events

113

Sprints have consistent durations throughout a development effort.

The duration of Sprints should be consistent over time, as this both provides practical benefits in everyday work , as well as support empirical process control. Alterations to the duration can be made but should be done rarely and carefully. Having a consistent length of Sprints creates a habit within the team and allows for better progress evaluation within the Development Team. A consistent duration also allows for Sprints to be compared to each other, as the potentially crucial parameter of duration remains consistent. This ability to compare provides a necessary basis of transparency to inspect and adapt upon. For example , a Retrospective at the end of a one-month Sprint may yields ideas on how to improve the performance of the upcoming Sprint , which is also one month in duration. The ideas are implemented, and at the end of the next Sprint , the results of both Sprints are compared. While other parameters, e.g., factors in the organization , may also have changed, the two Sprints share a their duration crucial characteristic which makes the comparison and the subsequent learnings more valid . In a counterexample, the ideas may be implemented and also the duration of the next Sprint is shortened from a month to two weeks. The results determined in the next Retrospective cannot easily be compared to those of the previous Sprint , an increase in performance may be due to the implemented ideas, but also due to the consequences of a shorter time-box . To even compare the performances, for example, in Story Points delivered, the result of the second Sprint must be extrapolated; whether this is appropriate or not cannot be definitively said.

When attempting improvements, which in an environment of complex problems means experiments that need to be evaluated, the goal must be to limit the number of altered parameters as much as possible. This includes the duration of the Sprint , which should thus remain constant if possible.

7 Scrum Events

114

A new Sprint starts immediately after the conclusion of the previous Sprint.

The Scrum Guide does not recognize a time between Sprints. The entire development process is set up as a (potentially endless) series of iterations with nothing else in-between. This forces the Scrum Team to organize their entire work into iterations and thereby under empirical process control, In practice, some teams may use a Time in-between Sprints" for clean-up work, code-refactoring, additional testing, etc., while all this work should instead be part of the Sprint so that it can be properly inspected and improved.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

In this sentence, the Guide emphasizes the role of the Sprint as a container for the other four events and the development work again. Unlike the four other events, which are meetings at a specific time, a Sprint describes a timeframe in which other things take place.

During the Sprint:

• No changes are made that

would endanger the Sprint

Goal ;

The goal of a Sprint is to deliver an Increment , meaning to deliver a product that has a higher value than it had prior to the Sprint. The direction for this added value is given by the Sprint Goal, which is crafted during the Sprint Planning. This can be thought of as the justification for the Sprint; once it becomes irrelevant or impossible 1 to reach, the Sprint becomes obsolete . Therefore, any changes

4

see section on canceling a Sprint on page ijj)

7 Scrum Events

115

that are made during a Sprint are not allowed to endanger the Sprint Goal.

• Quality goals do not decrease; and. The quality goals, most prominently outlined in the definition of "Done", may be adjusted e.g., as a result of a Retrospective but may not be lowered during a Sprint . As more is learned throughout the Sprint , they may increase, however, if necessary.

For example, when working in areas relevant to IT security, additional quality requirements may emerge without which an Increment would fulfill the definition of "Done”, but not be potentially shippable. Quality goals may not be lowered during a Sprint for two reasons:

• Based

upon an agreed-upon Definition of "Done", the stakeholders may have expectations that would not be fulfilled with an Increment with lower quality goals.

• Quality goals are critical parameters in empirical process control. In order to compare the functionality of the product development process, parameters should remain constant , and if they are changed, the changes should be made in a controlled manner, allowing for the inspection and possible adaptation of the changes.

• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

This rule explicitly permits changes to the scope of a Sprint When dealing with complex problems, during the Sprint. estimations on Product Backlog items can be off , sometimes by

7 Scrum Events

116

significant amounts, in both directions Even when having conducted proper Sprint Backlog refinements, it is possible that the full scope of work units is only understood during the Sprint , while work is being done. Alternatively, conditions may also change in non-preventable ways, for example, through the sickness of members of the Development Team. ,

Scrum is sometimes - wrongly - understood as having a static Sprint Backlog , i.e. , that Product Backlog items agreed upon in the Sprint Planning cannot be changed. Rather , the Sprint Goal is static and. as the first rule outlines, may not be endangered. How the Sprint Goal is achieved, however, can be changed through an agreement between the Product Owner and the Development Team . For example: During a Sprint Planning, a Swum Team , working on a mobile app, crafts a Sprint Goal that says: 'At the end of this Sprint , the user can visit their profile section". Under that goal, the Sprint Backlog contains items including:

• The user can see their own profile picture • The user can change their own profile picture • The user can see their personal data

• The user can edit their personal data The Development Team believes they can get all these items " Done" , but throughout the Sprint, one of the four developers becomes sick and cannot work, and the remaining developers realize that the technical process underlying the change of profile pictures is more complex than initially thought . The rule now permits that the Development Team and the Product Owner discuss and come to the agreement . The scope must be adjusted : while the user still received the added value of being able to see their profile section, this section does not ( yet ) include the possibility to change their profile picture. This feature may be added in another Sprint.

7 Scrum Events

117

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

The iterative , incremental approach of Scrum breaks down product development , which in conventional project management approaches would be one large project , into a series of smaller projects. Each of these projects is worked on during a Sprint and has

• a goal, which is determined during the Sprint Planning. The Product Owner and the Development Team collaborate to craft a Sprint Goal from the ( business) objectives and the forecast of what can be accomplished . This Sprint Goal can be seen as the goal of the project that is worked on during Sprint .

• a design providing guidance on how to achieve the Sprint Goal in the form of the Sprint Backlog, which consists of the selected Product Backlog items as well as a plan on how to deliver them in an Increment. This is a flexible plan, as it is not static, but is revisited at least during every Daily Scrum and can be changed as long as the Sprint Goal . The goal of the project remains intact.

• work

done towards the goal of the project , which is the development work of the Development Team.

• a resultant product in the form of

the increment , which in Scrum is not a final product relative to the iterative, incremental process , but final relative to the project worked on during the Sprint.

The duraton of each of these projects is limited to a month; the reasons for this are explained in the following sentences of the Guide.

7 Scrum Events

118

Sprints are limited to one calendar month. When a Sprint ’s horizon is too long, the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost .

With this paragraph, the Guide provides two guidelines: On the one hand, it establishes a fixed upper limit for the duration of the Sprint, which is defined as one calendar month. On the other hand, it provides Scrum Teams with a guideline on how to choose the appropriate length for their Sprints.

One of the goals of Scrum Events is to create regularity and thereby reduce complexity. For Sprints, this is usually achieved by aligning their length to existing regularities, namely the calendar week or the calendar month Having 10 day Sprints is theoretically possible, the resulting shift of the Scrum events relative to the days of the week would create (potentially ) unnecessary complexity.

.

-

Therefore, most Sprint durations in practice are defined in multiples of weeks, namely one week, two weeks, three weeks or four weeks. Sprints can, however, also be aligned to calendar months. It is important to note that in prior sentences, the Guide stated the time box for the Sprint to be a month, here it especially refers to a "calendar month", specifying the duration as beginning at the start of a specific month and ending on the last day of the same month

-

.

The calendar month limit is not determined by any calculations, but rather has established itself from practical experience using empirical process control, like the maximum number of members of the Development Team. -

5 see

the explanation on the maximum number of members of the Development Team on page 79

7 Scrum Events

119

7.1.1 Cancelling a Sprint

A Sprint can be cancelled before the Sprint time- box is over. Only the Product Owner has the authority to cancel the Sprint , although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint in Scrum is of a fixed and consistent length. There may be circumstances, however, which lead to the assessment that the value generated by continuing the Sprint does not justify the cost of doing so anymore.

The evaluation of whether this is the case is taken by the Product Owner, as they are tasked by the Scrum Guide to maximize the value delivered by the work of the Development Team. Others involved with product development , such as stakeholders and other members of the Scrum Team , may provide their opinions on the matter ; however, the final decision must be made by the Product Owner and be respected .

A Sprint would be cancelled if the Sprint Goal becomes This might occur if the company changes obsolete. direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But , due to the short duration of Sprints, cancellation rarely makes sense.

The Sprint Goal may become obsolete due to a variety of factors, including the mentioned direction changes of the parent organization or changing conditions surrounding the product. As the Sprint Goal provides the purpose for the Sprint, an obsolete Sprint Goal renders the Sprint obsolete, what the Guide expresses as "it no longer makes sense".

7 Scrum Events

120

In the final sentence, the Scrum Guide points out that Sprint cancellations a rare occurrence. Sprints are kept as short as possible6 , in order to minimize the risk of developing in a wrong direction. Therefore obsolescence being realized within a Sprint is rare.

When a Sprint is cancelled, any completed and "Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

The Scrum Guide defines a clear process for Sprints succeeding each other. In this sentence, however, it outlines what happens with this direct succession is interrupted due to a Sprint cancellation.

The ’ Done” Product Backlog items are reviewed While not explicitly state, it can be assumed that this review takes place without the formal setting of a Sprint Review, but rather within the small circle of the Scrum Team. In order to not waste the work that was already done, the Product Owner may choose to accept them ,

.

The Guide uses a descriptive terminology rather than a prescriptive by saying the Product Owner "typically accepts it". This indicated that this is not a rule the Product Owner must follow, but that it can be considered good practice to do so. The incomplete Product Backlog items are moved from the Sprint Backlog back into the Product Backlog. As there may be work done on them aJready or as new insights throughout the canceled Sprint may have arisen, the items are re-estimated. In this

fcsee sentence on the duration of a Spnnt on page 1JJ3

7 Scrum Events

121

sentence, the Guide uses prescriptive terminology, indicating that moving the items back into the Product Backlog and re-estimating them is mandatory, as the Product Backlog as an Artifact must reflect what is currently known about the product and its future direction.

If work was done on the items moving back into the Sprint Backlog, this work might become unuseful quickly. As the Sprint Goal became obsolete, it is unlikely that the next regular Sprint will contain all Product Backlog items for which (unfinished) work exists. Therefore, the product itself will change along with the general surroundings of the product. The usability of the unfinished work will, therefore, depreciate over time, which must be reflected in the estimations.

Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

Canceling a Sprint is described as having two negative repercussions.

• On the one hand

, the immediate need for another Sprint Planning consumes time that would otherwise be usable for further work on the product.

• On the other hand, Sprint cancellations are described as often traumatic *. Scrum aims to reduce complexity by "

’

working with predictable cadences, i.e., regularly reoccurring events, for example conducting a Daily Scrum every day and having Sprint of consistent length. A Sprint cancellation breaks with this order and creates a Furthermore, a Sprint short term chaotic situation. cancellation implies that the work done throughout the Sprint until its cancellations was not the best use of the work of the Development Team and may, in the worst case, even have produced waste.

-

7 Scrum Events

122

The Scrum Guide finishes this section by pointing out that cancellations of Sprint are very uncommon, which gives another indicator to the Product Owner to only make the decision to cancel a Sprint very cautiously.

7 Scrum Events

123

7.2 Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. During the Sprint Planning, the Scrum Team plans the work that should be performed in the Sprint. The term "planned" herein covers the process of selecting the Product Backlog items to be worked on, the creation of an overarching Sprint Goal, as well as deciding a flexible plan of how to work towards the Sprint Goal by delivering the Product Backlog items.

This plan is created by the collaborative work of the entire Scrum Team.

.

The planning involves all roles on the Scrum Team The Product Owner presents a business objective and an ordered Product Backlog, from which the Sprint Backlog will be created. The Development Team forecasts the amount of functionality they can deliver and plans on how to do so. Both sides engage in a dialogue on what can be delivered in the Sprint. This dialogue is supervised and, if necessary or requested, facilitated by the Scrum Master.

Sprint Planning is time- boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

-

The Scrum Guide defines an absolute time box for the Sprint Planning as being eight hours for a Sprint lasting one month. The subsequent sentence outlines that the event is usually shorter for Sprints lasting longer than one month

.

The second sentence is often wrongly seen as advocating scaling the time box linearly with the duration of the Sprint :

-

7 Scrum Events

124

approximating one month as being four weeks and claiming the time box to be 2 hours for every week in the Sprint. The time box , however, remains eight hours for a Sprint of any ( permissible) length, though this time box is usually not fully used in Sprints shorter than one month.

-

-

-

The Scrum Master ensures that the event takes place and that attendants understand Its purpose. The Scrum Master teaches the Scrum Team to keep it within the time- box.

The Scrum Master, as defined by the Scrum Guide, is sometimes described as the "manager of the process". This is not to say that they have any hierarchical authority over either the Product Owner or the Development Team members, but that they are tasked with ensuring the process defined by the Scrum Guide takes place. With regard to the Sprint Planning, this can be seen, as the Scrum Master is given the responsibility for the event to take place. Another role of the Scrum Master, which is explicitly outlined in the definition of the Scrum Master role, is to help those on the Scrum Team understand the Scrum theory and practices. With regard to the planning, this means:

• ensuring that those attending understand the purpose of the Sprint Planning within Scrum, and

• teaching

the Scrum Team to keep the event within the time-box to ensure focus and to allow for empirical process control

The use of the term "attendants", rather than "Scrum Team" or "Product Owner and Development Team members" emphasizes that other individuals who are not part of the Scrum Team may attend the event. In a later section, this is defined as being upon invitation of the Development Team.7

see the explanation on the Development Team inviting others to the Sprint Planning on page 134

7 Scrum Events

125

Sprint Planning answers the following:

• What can be delivered in the increment resulting from the upcoming Sprint?

• How will the work needed to deliver the increment be achieved ? The purpose of the Sprint Planning is to plan the work for the upcoming Sprint. In order to serve this purpose, the Scrum Team needs to first define the scope and aim of what can be delivered. This is done by crafting a Sprint Goal and determining what Product Backlog items will be worked on. In a second step, the Scrum Team collaborates to determine a plan on how to work towards delivering the increment fulfilling the Sprint Goal. While these two questions may be understood as outlining two phases of the Sprint Planning, determinations made while working towards answering the second question may affect the assessment of the scope, and may lead to renegotiations on what can be delivered. Both questions should, therefore, be answered in a Sprint Review where the entire Scrum Team is present throughout.

7 Scrum Events

126

7.2.1 Topic One: What can be done this Sprint ?

The Development Team works to forecast the functionality that will be developed during the Sprint. As those doing the work of delivering Product Backlog items, the Development Team provides a forecast of how much functionality they can deliver in the upcoming Sprint. The term "functionality" in this sentence does not refer to specific features in the Product Backlog, but to an abstract measure of how much general functionality can be developed . It can be argued that the Scrum Guide uses the term rather than speaking of "capacity" because the forecast method chosen must refer to the capacity to deliver features, rather than merely the time availability. Scrum does not explicitly prescribe any metric or factors to be considered and leaves those determinations up to the individual Scrum Teams. However, it can be assumed that simply stating time availabilities and later comparing these to time-based estimated of Product Backlog Items is not approved by the Scrum Guide. "functionality "

A common approach instead is the use of a Velocity based on Story Points , calculated e.g. on the performance of the most recent Sprints and the availability of the Development Team members.

The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.

The Product Owner is responsible for maximizing the value delivered by the work and thus determines what is the best use of the capacity of the Development Team. They discuss the

7 Scrum Events

127

objective of the Sprint , i.e. what the Sprint should achieve if successful, and the Product Backlog items that would need to be delivered in order to achieve the objective.

The Scrum Guide uses the term "discuss", instead of e g . "present", purposefully, since the scope of what features can be delivered can vary with the combination of Product Backlog items. The Product Owner and the Development Team may engage in a discussion on how different combinations of Product Backlog items may best serve the objective defined by the Product Owner, considering the finite capacity of the Development Team. Throughout this process, both parties, as well as the Scrum Master, collaborate to define, re-define and refine a Sprint Goal, which gives guidance on what Product Backlog items should initially be selected to be placed in the Sprint Backlog.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.

In order to determine what will be worked on in the upcoming Sprint , the following things must be known or determined and are thus inputs for the Sprint Planning:

• The latest Increment is, by definition, the product existing at the time of the Sprint Planning. As product development in Scrum works incrementally by adding on top of the existing product version ("Increment"), the work of the upcoming Sprint will integrate with the increment to create a new Increment . All work in the upcoming Sprint must take the overall situation of the increment , with its features and technical debt , into consideration . Therefore, the increment at the time of the Sprint Planning provides the definition of a starting point.

7 Scrum Events

128

• The projected capacity and the past performance give an indication of the scope of what can be delivered in the upcoming Sprint. They are crucial to understanding how far the development can go forward from the starting point.

• The Product Backlog, as a list of

deliverables sorted by value, provides the items which will be drawn into the Sprint Backlog and worked on by the Development Team throughout the Sprint. Therefore, the Product Backlog provides a sense of the direction into which the work of the Development Team will go.

The awareness of all of these facts allows the Scrum Team as a whole to craft an appropriate Sprint goal and the Development Team to decide on how many items it believes it can work on during the Sprint.

The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint .

-

The Development Team is self organizing with regard to their work, which includes the right to decide the scope of what they believe they can accomplish. The Product Owner may try to motivate them to add more items, though the final decision is up to the Development Team. This again is a manifestation of the principle that decisions should be reached as close to the point of work as possible. ®

" see explanation on wtiy Scrum is not a process on paoe 13

7 Scrum Events

129

During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the increment.

The Sprint Planning produces two immediate outcomes:

•A

first version of the Sprint Backlog, which contains the Product Backlog items the Development Team has assessed it will be able to deliver within the Sprint, as well as a initial plan of how to achieve this

• The Sprint Goal The Sprint Goal defines the purpose of the Sprint , it outlines what objective will be met through the work of the Development Team. The Scrum Guide refers to this work as the Implementation of the Product Backlog’ rather than the "implementation of the Sprint Backlog" since the Sprint Goal supersedes the Sprint Backlog and may lead to it being changed. The Sprint Backlog is a list of Product Backlog items and a plan on how to deliver them to realize the Sprint Goal through the delivery of an Increment . This plan falls under empirical process control, is inspected at least during each Daily Scrum and may be adjusted. Furthermore, if it is determined through inspection that the list of Product Backlog items is not the best available way to deliver an Increment which realizes the Sprint Goal, this list may be changed. The Sprint Goal provides guidance to the Development Team by outlining the purpose of their development work. Thus, it provides the necessary transparency for frequent inspection of the validity of the current Sprint Backlog and subsequently for the possibility to ,

• adapt

plan of how to turn the selected Product Backlog items on their own. and

• change

the selected Product Backlog items through negotiations with the Product Owner

7 Scrum Events

130

7.2.2 Topic Two: how will the chosen work get done?

Having set the Sprint Goal and selected the Product Backlog items for the Sprint , the Development Team decides how it will build this functionality into a Done" product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

Following the definition of a Sprint Goal and the subsequent decision on which Product Backlog items the team will work to deliver during the Sprint, an (initial) plan needs to be devised how As this defines an outline for the work of the to do this Development Team, the self -organizing Development Team is responsible for creating this plan, albeit with the possible support of the

.

• Product Owner, who may assist

through clarifications of items, making their own priorities which by definition are the priorities of the product development transparent and possibly renegotiating the selected items with the Development Team

• Scrum Master

,

-

-

who may facilitate the event

The sum of this plan and the items selected together form the Sprint Backlog. The Development Team chose the scope of how many items would be selected and created the plan of how their work will be conducted to implement them. Therefore, the Sprint Backlog is owned by the Development Team.

7 Scrum Events

131

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint.

By using "usually", the Guide gives a common practice rather than a prescriptive rule. This common practice is for the Development Team to "design the system", by which the Guide means drafting a pathway to the desired solution of producing an Increment. This design needs to be broad enough to not over plan, yet specific enough to derive from it the work necessary for implementation.

-

At this point, there is no requirement as to how small the units of work need to be. The only requirement the Guide gives in these sentences is that the work should be planned thoroughly enough for the Development Team to provide an estimation of what it believes to be able to implement in the upcoming Sprint.

Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.

The Sprint Planning must result in a plan that allows the Development Team to start working towards the Sprint Goal. The Scrum Guide uses the term "decompose" to describe the systematic breaking down of work from abstract concepts and ideas into chunks of work that are implementable. The Guide gives the convention of "units of one day or less". This is not a mandatory prescription, but instead a guideline, as the size of units of work is dependent on the context of the product development. A balance must be found between

• making units of work too large

which leads to a longer time until it is done; this is undesirable, as the Development Team inspects the Sprint Backlog regularly to possibly ,

7 Scrum Events

132

make adaptations; this process would be slowed down by large , long-lasting units of work

• making units of work too small, which creates unnecessary planning and coordination overhead that is not justified by the value the unit of work delivers

With regard to the upper limit , the Scrum Guide recommends a day or less, as this allows a unit of work to be done between two Daily Scrums and therefore allows the regular inspection and adaptation mechanism of the Daily Scrum to work optimally.

The Scrum Guide mandates that the ftrst days' worth of work is decomposed in this manner . In practice the entire work for the Sprint is often decomposed during the Planning This is permitted by the Guide: however , it is not mandatory, and may not be necessary. ,

,

The Sprint Backlog contains an initial plan of how the work will be conducted; this plan is, however, subject to inspection and possible adaptations during the Daily Scrum . Therefore , on any day. the work for the upcoming day may change as more is learned. Thus it may make sense to only decompose work for a few days in advance but do so repeatedly throughout the Sprint.

The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

The Sprint Backlog is owned by the Development Team, which is a self-organizing unit with the Scrum Team. As such, it is responsible and empowered to make the decisions for how to conduct the development work on their own. This is true during the Sprint Planning, where is refers mainly to the decomposition of the work into small units, as well as throughout the Sprint , where it includes the further decomposition and adjustments to the plan on how to deliver the Product Backlog items.

7 Scrum Events

133

The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. Throughout the process of planning how the selected work will get done , the Product Owner may be consulted to clarify the Product Backlog items, should questions come up which were not previously discussed , for example, ones that emerged during decomposition. Regarding the trade-offs, the sentence can be understood in two way. both of which can be considered valid:

Product Owner can ... make trade-offs: In this reading, the Product Owner may make trade-offs on the Product Backlog items, for example, with regard to the scope of items, which may occur when planning and decomposition reveal more about the time and resources the implementation of an item will likely take. A result could be to lower the scope of expectations of the item.

• The

• The Product Owner can help to • •• make trade-offs: In this reading, the Product Owner may assist the Development Team to decide between different implementation options. The Product Owner is responsible for the maximization of the value delivered by the work of the Development Team . As such, they may give inputs when, for example, two paths for implementation are possible, one of which would cost more time but lead to greater functionality, while the other solution delivery lower functionality but at a lower ( time ) cost.

If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner.

The Planning is not strictly divided into two phases, as it was in the Scrum Guide prior to 2013. Instead , the two questions that need to be answered by the end of the planning may require some back-and- forth between them. As more is learned throughout the process of the Development Team planning and decomposing the

7 Scrum Events

134

work, the initial forecast of what can be delivered may change. Should this be the case, the team revisits the first question of the Planning and renegotiations what items should be worked on in the Sprint with the Product Owner.

This renegotiation may keep the Sprint Goal intact, especially when a few more items of work are added to the Sprint. The new assessment of what can be delivered may, however, also lead to the Sprint Goal becoming obsolete, in which case a new Sprint Goal needs to be crafted by the Scrum Team. While this may lead to a longer time spent in the Sprint Planning, it would likely avoid having more complex renegotiation at a later point during the Sprint.

The Development Team may also invite other people to attend to provide technical or domain advice. Unlike, for example, the Daily Scrum, which is an internal meeting for the Development Team, the Sprint Planning may benefit from external input. The Product Owner is the only source of the priorities of the Product Backlog and therefore, of what the Development Team will work on. The second question how the chosen work will get done may. however, benefit from inputs from others on technical and domain issues.

.

-

-

The Development Team owns the process of planning the selected work, and as such, is both responsible for and empowered to invite the people they deem appropriate to help them. It is important to understand that these other people take part to advise, the Development Team is still responsible for crafting the plan on how they will get their work done.

7 Scrum Events

135

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated increment.

One outcome of the Sprint Planning is the Sprint Backlog , which is the list o( selected Product Backlog items and an initial plan on how to turn them into an Increment . The Guide uses the expression 'should be able" to indicate that the Development Team is not obligated to explain it to either the Product Owner or Scrum Master, nor to anybody else The ability to explain the plan is, however, a useful benchmark of whether the plan is thoroughly thought through, The Guide emphasizes the self-organization of the Development Team again, emphasizing that the plan crafted must be owned and, if necessary, adapted by the Development Team autonomously. The last part of the sentence emphasizes again the importance of

• the Sprint

Goal as a guiding principle for the work of the Sprint, and

• the increment as the ultimate outcome of the Sprint.

7 Scrum Events

136

7.2.3 Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. In order to answer the first question of the Sprint Planning, "what can be done this Sprint’, the Scrum Team crafts the Sprint Goal during the Sprint Planning. The Scrum Guide understands the Sprint Goal as an overarching objective that guides the Development Team towards creating an Increment through the implementation of Product Backlog items.

The Sprint Goal defines the purpose of the Sprint , which acts as a motivator, as it allows the Scrum Team to commit to something concrete. It further allows for decisions within the Sprint to be made. These include specific implementational issues, as well as inspecting the validity ol the composition of the Sprint Backlog aiming at achieving the Sprint Goal . The purpose of a Sprint is not , as is often seen in practice, the realization of the Sprint Backlog items. These merely serve as an artifact to inspect and adapt the plans and progress towards the realization of the Sprint Goal, which is the, in fact , the purpose of a Sprint.

7 Scrum Events

137

The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives. When crafting the Sprint Goal, the Product Owner discusses the (business) objective they would like to see realized. If this objective and its correspondingly selected Product Backlog items for a coherent function, this function may be chosen as the Sprint Backlog. An example of such a Sprint Goal could be Implementing the functionality to allow the user to register and log in\ If such a Sprint Goal cannot be directly derived, or if it is determined to not be useful for the Scrum Team, it may choose to craft a Sprint Goal on its own. The Scrum Guide requires only that pursuing the Sprint Goal leads to the Development Team to work together. This fosters collaboration and hence knowledge exchange, as well as motivation and the level of commitment and collective ownership. The Sprint Goal, in this sense, acts as a unifying vision for the Sprint.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint . The Sprint Goal is present throughout the Sprint and is, among other things, consulted every day during the Daily Scrum. The work of the Development Team, which includes the implementation of functionality and technology, aims towards realizing the Sprint Goal. The Development Team s work is the means to achieve the end of delivering an Increment realizing the Sprint Goal.

7 Scrum Events

138

Having the Sprint Goal as a focal point allows for evaluation of the Sprint Backlog and the determination of whether or not the current plan is still suited to achieve this goal. If new work emerges or the work previously agreed upon is determined to not best serve the realization of the Sprint Goal, the Development Team collaborates with the Product Owner to change the Sprint Backlog. This change is done in a way that allows the Scrum Team to deliver an Increment realizing the Sprint Goal, albeit perhaps in a smaller or different way than initially planned.

q

7 Scrum Events

139

7.3 Daily Scrum Choosing "Daily Scrum’ as a title for this event may have been influenced by two factors:

• Schwaber and Sutherland borrowed the term "Scrum" from rugby's term "scrummage", which is often abbreviated to A scrum describes a position in which the players pack closely together to gain possession of the ball. This can be seen as the basis for choosing the term "Daily Scrum”, as it is an event where the Developers metaphorically "stick their heads together". "scrum”.

• The idea of "Scrum" as described by the Scrum Guide is a framework based on the empirical process control of transparency, inspection and adaptation, manifesting in iterative, incremental work. The Daily Scrum provides an opportunity for inspection and adaptation . It happens daily, leading to the time between two Daily Scrums being constant and. therefore, the work between them to be Furthermore, during the Daily Scrum, the iterative. participants analyze the work done until the Daily Scrum and how additional work can be done on top it to reach the goal, which describes an iterative approach . Therefore , every development day can be thought of as a micro- Sprint of one day, with the Daily serving as a micro-Review and micro- Retro for the past day and micro-Planning for the upcoming one.

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint.

The Scrum Guide prescribes a time- box of 15 minutes for the Daily Scrum. This maximum duration is independent of the number of members of the Development Team; the time-box is 15

7 Scrum Events

140

minutes regardless of whether the Development Team consists of 3 members or 9. 15 minutes was chosen as it is long enough to allow an efficient synchronization between the Development Team members but short enough to not impede the development work unnecessarily long. Such a limited time-box also enforces a strict focus and limitation technical details to a reasonable level. As implied in the title "Daily Scrum", this event is supposed to take place every day of the Sprint. This is done in order to:

• have

at least one daily opportunity for inspection and adaptation

• limit the planning of work to a timeframe of only the next 24

hours, which limits risk while not being too frequent to get in the way of work

• create regularity in order to reduce complexity The event is defined as being for the Development Team, which, as a self -organized entity, conducts its own meetings for its own work. Later sentences in this section of the Guide specify the extent to which the Scrum Master, Product Owner and other individuals may be involved.

At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work.

During a Sprint Planning, the work of previous Sprints is considered, and a forecast of what can be delivered is made. Analogously, during the Daily Scrum, the team inspects the work that has been done since the last Daily Scrum and takes this into consideration when forecasting what work can be done until the next Daily Scrum. Based on this forecast, the Development Team plans its work. The Scrum Guide does not prescribe any methods for how this is done and leaves this detail to the Development Team.

7 Scrum Events

141

The Daily Scrum is held at the same time and place each day to reduce complexity.

The Daily Scrum is consistent in time and place each day. This rule has both theoretical as well as very practical reasons:

• Holding the event at the same time every day allows for the individual workdays to be likely of the same length. This makes it easier to compare workdays with each other and therefore creates a higher degree of transparency on the basis of which inspection and potential adaptation may be conducted.

• Consistency of time and place makes remembering these parameters easier for the Development Team members.

Changing rooms frequently may lead to some members going to the wrong room. Changing times may lead to members confusing the time and showing up in the room at a time when no Daily Scrum takes place, or not show up for a Daily Scrum as they forgot about it. Both changes increase the likelihood of problems, which are more substantial for the Daily Scrum, considering the short time box of only 15 minutes

.

-

It also establishes a clear time when the Developers are unavailable, making planning other appointments easier, especially for people who are not part of the Development

.

Team

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. Every event in Scrum is set up to create an opportunity for inspection and adaptation. The Daily Scrum is to be used by the Development Team to inspect the progress. The result is then used to extrapolate the scope of what can be achieved with

7 Scrum Events

142

regard to the Sprint Goal. This provides the basis on which potential alterations to the Sprint Backlog might be made , such as

• adding items to the Sprint Backlog • re-negotiating

the scope of the Sprint while keeping the Sprint Goal intact

• informing the Product Owner that the Sprint Goal cannot be met

The Daily Scrum optimizes the probability that Development Team will meet the Sprint Goal.

the

The Daily Scrum contributes to the increased probability of meeting the Sprint Goal in two ways :

On the one hand, it provides a forum for the entire Development Team to synchronize, make impediments transparent , and plan how to work for the upcoming 24 hours. This coordination and the subsequent collaboration increase the efficiency of the work of the Development Team and therefore makes the delivery of the selected Product Backlog items more likely. On the other hand, the Development Team reassesses their path towards the Sprint Goal every day and is, therefore, able to react quickly once it becomes apparent that not all the selected Product Backlog items will be deliverable. It may then choose to work with the Product Owner to re-negotiation the selected items while still keeping the Sprint Goal intact , increasing the chance to still meet the Sprint Goal, albeit with a smaller number of selected items.

7 Scrum Events

143

Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated increment by the end of the Sprint.

-

In Scrum, the Development Team is a self organizing entity. The Daily Scrum provides a powerful benchmarking mechanism for whether it is ( already) capable of self organizing. If every Daily Scrum ends with the team understanding how it will work towards the Sprint Goal, that is a strong indicator for a self organizing team Troubles reaching this understanding, conversely, can be an indicator that the team needs more support in becoming self organizing, especially from their Scrum Master.

-

-

.

-

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, and some will be more discussion-based. Here is an example of what might be used:

• What did I do yesterday that helped the Development Team meet the Sprint Goal?

• What will I do today to help the Development Team meet the Sprint Goal?

• Do

I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

This section was one of the more profound changes in the 2017 update to the Scrum Guide. Previously, the Guide introduced the three questions with "During the meeting, the Development Team members explain:", thereby mandating these three questions. With the 2017 update, the Guide grants the Development Team the freedom to determine the structure of the Daily Scrum for themselves. The three questions remained part of the Scrum Guide, but are now introduced as an example. The three

7 Scrum Events

144

questions can be seen as dealing with the same issues as the

other events within a Sprint: did I do yesterday. . ." - Answering this question looks back at work conducted since the previous Daily Scrum like a Review looks back at work conducted ( and the value generated ) in the last Sprint .

•' What

will I do t o d a y. - Answering this question looks ahead at work to be conducted until the next Daily Scrum like a Planning looks ahead at work to be conducted in the upcoming Sprint.

•‘ What

• "Do / see any impediments.

- Answering this question

looks at what has been or will be problematic lor the success of the Development Team like the Retrospective looks at the problems that impeded the process and tries to generate ideas for solutions. The Development Team may choose to adopt another way of conducting their meetings, as the Guide outlines it may answer questions or engage in discussions. If the Scrum Team integrates a methodology into the Scrum framework, the Development Team may choose to replace the three questions with structures more suited to their methodology. If the Scrum Team, for example, chooses to integrate Kanban, the three questions may be replaced with a discussion based on the current status of the Kanban board.

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint 's work. Meetings after the Daily Scrum are not mandatory. This sentence describes a common occurrence and implicitly gives advice on how to keep the Daily Scrum within its time-box. During the Daily Scrum, questions may arise, e.g. , of a technical nature, or larger issues may be identified.

7 Scrum Events

145

Instead of discussing them within the short time-box of the Daily Scrum, these topics should be moved into a separate meeting. This allows for focus in the Daily Scrum and potentially saves members of the Development Team time, as some discussions may not be relevant for every member ; therefore, the Guide specifies that the meetings may be of the entire Development Team or only of a relevant subset.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

The Scrum Master is tasked with ensuring the Scrum process and therefore has to ensure that the Daily Scrum takes place. The Development Team is a self organizing entity within the Scrum Team and, therefore, responsible for their own meetings. The Scrum Master may facilitate the Daily Scrum if requested or needed. However, the ability to conduct their own meetings properly is a critical benchmark for self -organization and provides both the team and the Scrum Master with valuable input regarding the achieved quality of self organization. These inputs may provide a basis for further improvement driven by the Development Team , as well as further actions to be taken by the Scrum Master.

-

-

The involvement of the Scrum Master in the Daily Scrum is limited; the Guide refrains from ascribing to them the function of enforcing the time-box. Instead, the Scrum Master is given the responsibility to teach the Development Team to follow the time box. This explicit non use of terminology such as "enforce” may be interpreted as a guideline to the Scrum Master to not point out expired time-boxes on the spot, but instead to provide feedback outside the Daily Scrum about this fact.

-

-

7 Scrum Events

146

The Daily Scrum is an internal meeting for the Development Team. If others are present , the Scrum Master ensures that they do not disrupt the meeting. Aside from ensuring the Daily Scrum takes place and teaching the Development Team to keep it within the time-box, the responsibility of the Scrum Master is to ensure that others do not disrupt the meeting. Outsiders may not actively partake in the Daily Scrum. The Scrum Guide uses the expression "internal meeting to describe the Daily Scrum, outlining that even if others attend, the decision on how to conduct the meeting remains with the Development Team and should be made in a way that the meeting best serves the needs of the Development Team, not the others present.

-

An anti pattern for this would be for a manager to attend the Daily Scrum, leading the Development Team to conduct the Daily Scrum as a status update meeting instead of as a proper Daily Scrum, which would weaken the possibility of transparency, inspection and adaptation.

The Product Owner might be present during the Daily Scrum to answer urgent questions that may arise, such as clarifying priorities, but they too do not engage in the internal discussions of the Development Team, nor should they have any influence on how the meeting is conducted.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team s level of knowledge. This is a key inspect and adapt meeting.

Daily Scrums follow the 6th principle of the Agile Manifestof 141. to which both co creators of Scrum were original signees: The most efficient and effective method of conveying information to and within a development team is face to- face conversation.". Therefore, Daily Scrums serve to improve communications and

-

-

7 Scrum Events

147

promote quick decision-making. This, in turn, may make other potential meetings obsolete .

As the Development Team synchronizes every day, it actively engages in sharing their knowledge on the business matter as well as potentially on the technical matter. The inspection ot achieved progress and planning of upcoming work will create transparency regarding issues that will impede the development , which are then collected as impediments to be removed by the Development Team or potentially by the Scrum Master.

The Daily Scrum is described by the Scrum Guide as a key inspect and adapt meeting, because

• its

regularity allows the timeframe in-between , i.e., workdays, to be of the same length, which fosters necessary transparency for further inspection and possible adaptations

• using the Daily Scrum to break down the Sprint into microiterations allows constant adjustment of plans via inspection and adaptation

• having all

Development Team members attend the same meeting creates maximum transparency regarding the work done by the entire Development Team and therefore provides a basis for inspection

• the

meeting inspects the current progress towards the Sprint Goal and makes immediate adjustments to the existing plans, which combined with the high frequency allows for fast adjustments as new things are learned

7 Scrum Events

148

7.4 Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the increment and adapt the Product Backlog if needed.

The Sprint Review is, like all Scrum events, aimed at fostering empirical process control. It does so by providing a dedicated platform for the inspection of the increment , i.e .. the sum of all previous increments plus the "Done" work of the current Sprint . The Scrum Team actively participates in the Review based on the values of openness and courage . The key stakeholders actively participate, based on an understanding of Scrum, ensured by the Scrum Master , and the principle of customer collaboration. These together provide the transparency for the subsequent insp>ection outlines in the previous paragraphs. Based on these inspections, adaptations are made, most notably an alteration to the Product Backlog.

This inspection allows for potential adaptations to be made to the Product Backlog, as the functionality of the Increment, as well as external data, becomes available. Furthermore, feedback and insights gathered during the Sprint Review may be used as inputs for the subsequent Sprint Retrospective.

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint

With this sentence , the Scrum Guide defines the foundation of the Sprint Review : It is intended as a meeting attended by the Scrum Team as well as stakeholders. The presence of both is necessary to allow for maximum transparency, which subsequently allows inspection and may lead to adaptation.

7 Scrum Events

149

The parties are meant to collaborate. The Cambridge English Dictionary defines "collaborate" as "to work with someone else for a special purpose:" The parties involved in the meeting are not merely supposed to inform each other, but to work with each other throughout the meeting on inspecting what was done in the Sprint.

.

The use of done instead of "Done" in this sentence indicates that the inspection during the Sprint Review deals not only with what Product Backlog items were ’Done", but with all the work of the Sprint, whether it resulted in something "Done" or not.

Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.

This inspection, combined with the inspection of other changes made to the Product Backlog since the last Review, in which the Sprint Backlog was inspected together, provides the basis for adaptation. The subject of adaptation is not specified and thus leaves room to address any area where adaptations may lead to improved value delivery. Typical areas include:

• the work of the next Sprint,

• decisions on possible releases of the increment

,

• the

collaboration stakeholders

between

the

Scrum

Team

and

This is an informal meeting, not a status meeting, and the presentation of the increment is intended to elicit feedback and foster collaboration.

With this sentence, the Scrum Guide seeks to distance the Sprint Review from a conventional project status meeting. Status meetings, often held weekly or bi-weekly, are meant to update stakeholders on the status of the project. Oftentimes, this

7 Scrum Events

150

meeting is a very formal event and only involves the stakeholders and the project manager.

The Sprint Review covers aspects of a status meeting, in that it updates the stakeholders about the status of the project . It does, however, define aspects that are untypical for mere status meetings: The Scrum Guide uses the term "informal meeting" to describe the Sprint Review, defining the expectation of a meeting where the titles and status of those involved are secondary to the collaboration towards the common goal.

The Scrum Master, who is responsible for educating stakeholders about Scrum, is tasked to motivate the stakeholders to embrace this format , which, especially for stakeholders from environments with more conventional management methods and formal status meetings, may be a significant change Furthermore, the Increment is presented ( as opposed to just described) and serves as the centerpiece for eliciting feedback from the stakeholders.

.

A common method to foster this feedback is to let key stakeholders use the Increment with its added functionality and gather their immediate thoughts on the user experience.

This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time-box.

These sentences are analogous to the ones describing the timebox and Scrum Master s involvement in the Sprint Planning /

9

see oaoe 123

7 Scrum Events

151

The Sprint Review includes the following elements:

-

Here, the Scrum Guide provides a non exhaustive list of characteristics a Sprint Review must follow.

• Attendees

include the Scrum Team and stakeholders invited by the Product Owner ;

key

The Scrum Team attends the Sprint Review:

• the Development Team members as the ones who have

built the Increment which will be inspected during the Sprint Review

• the Product Owner as the one responsible for maximizing

the value of the Development Team s work, the person most knowledgeable about the business side of the product and as the main contact person for the stakeholders

• the Scrum Master as member of the Scrum Team, observer and possible facilitator if needed or requested

The Product Owner is required to invite key stakeholders, who are supposed to attend the Review. The identification of who constitutes a key stakeholder is subjective and may be determined by the Product Owner

.

The Scrum Guide uses the term Include” to indicate that individuals who are neither members of the Scrum Team, nor key stakeholders, may attend the Sprint Review. This typically includes other members of the parent organization.

7 Scrum Events

152

• The

Product Owner explains what Product Backlog items have been "Done" and what has not been ’’Done”;

The Product Owner explains what Product Backlog items have been added to the Sprint Backlog , which of those have been delivered in accordance with the definition of "Done" and which ones have not been delivered in a "Done" status. This process creates greater transparency for the stakeholders regarding the current status of the overall development of the product .

• The

Development Team discusses what went well during the Sprint , what problems it ran into, and how those problems were solved;

During the Review, the Development Team creates transparency towards the Product Owner, the Scrum Master and the present key stakeholders , how the process of development went throughout the Sprint.

The Scrum Guide uses the term "discuss”, instead of "describe”, to highlight that it is not intended as a one-sided update, but a conversation, in which the stakeholders are supposed to gain a greater insight into the processes of the Development Team. Furthermore, the Development Team has the chance to gain an insight into the expectations and thought processes of the stakeholders and thus become better at delivering according to their needs. In contexts where the Scrum Team develops a product for an external customer, the key stakeholders may include representatives from the customer. Under such conditions, this aspect of the Review creates transparency to help the customer understand why the service they are paying for takes as long and costs as much as it does.

7 Scrum Events

153

• The Development Team demonstrates the work has "Done ” and Increment ;

that it the

answers questions about

As the purpose of the Review is to gather feedback about the newly created increment, a key component of the Review is the demonstration of all the work that is "Done ", i.e., the increment that could potentially be released by the Product Owner. The Scrum Guide explicitly uses the term "demonstrate" rather than "present”, highlighting that the Development Team is not supposed to talk about what they did, but either show the attendees the newly added features in action or even let key stakeholders try the new functionality themselves.

• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);

Once again, the Scrum Guide uses the term "discuss" to emphasize the need for active participation of the Scrum Team and the key stakeholders. If it is deemed necessary, the Product Owner uses the discussed status of the Product Backlog as well as the progress to project potentially crucial dates regarding the product . The "progress" in this case refers to both the overall progress manifesting in the current increment , as well as the speed with which the Development Team has delivered the functionality in the past. The Scrum Guide describes that these dates as assumptions by using the term likely". This is a manifestation of the principle of empiricism, under which knowledge ( such as a target date) cannot be known beforehand with absolute certainty.

7 Scrum Events

154

• The entire group collaborates on what

to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;

The Scrum Team and the key stakeholders work together on what the next steps should be. As the Scrum Guide does not limit what to do next", e.g., by specifying it to ’what the Scrum Team should do next", it can be assumed that these collaborations may yield tasks for the stakeholders as well. These results may become influences for the next Sprint Planning, either "

• directly, e.g., through a revised Product Backlog

,

or

• indirectly, e g., by providing inputs into the Retrospective from which a changed Definition of Done may be crafted

The overall goal of the Review is to synchronize the key players of the product development, in order to determine a commonly agreed upon the further course of action for the next Sprint .

• Review of how the marketplace or potential use of

the product might have changed what is the most valuable thing to do next ; and,

The Review provides an opportunity to inspect the conditions in which the product will be used to determine the direction of further development. The Scrum Guide gives two aspects to consider. On the one hand, changes to the marketplace, which may include factors affecting the product, such as general technological trends and competing products. On the other hand, the potential use of the product may change, for example, when the key stakeholders consider expanding the user base to groups not previously using the product.

7 Scrum Events

155

Both aspects may lead to a reconsideration ot priorities and subsequently to a different determination of the most valuable thing to do next. This determination is ultimately taken by the Product Owner upon the inputs of the attendees of the Sprint Review.

• Review of

the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The Review, as a meeting point of the entire Scrum Team and the key stakeholders , provides a forum to review the plans for the next releases of Increments In this sentence, the Scrum Guide describes four aspects to consider and distinguishes between two potentially different reasons for a release. The Review inspects:

• the

timeline, meaning a planned schedule of upcoming releases

• the budget ,

meaning the monetary considerations around the development of the product

• potential capabilities, referring to what the product could be able to do in the future

• the marketplace, referring to the overall conditions in which the product needs to exist and potentially compete

The Scrum Guide distinguishes between "functionality" and "capability" as reasons for releases. The Cambridge English Dictionary defines functionality as "any or all of the operations performed by a piece of equipment or a software program" and capability as "the ability to do something". The difference between these may be understood by using an example: A Scrum Team builds an online shop. At the point of the Review, the system allows the customer to look at items, add them to a shopping cart and pay for the selected items. The next release is

7 Scrum Events

156

supposed to include the possibility for the user to maintain a list of items they are interested in, but don’t want to add to their shopping cart . This addition is an operation performed by a computer program and, therefore, a functionality. In the following Review, the new piece of functionality delivered by the increment is inspected, found to be acceptable , and the In the meantime, the increment is subsequently released. , popularity of the online shop has soared and the system begins It is to show weaknesses handling massive user traffic. determined that in the upcoming release, these weaknesses need to be fixed. The fix for these may include the use of more efficient algorithms, migration to better hardware or the outsourcing of images to an external hoster. None of these aspects add a new operation that can be performed by the user and is subsequently no functionality. The fix does however , affect the ability of the system to serve its intended purpose and is thus a capability.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities. The Sprint Review inspects:

• the sum of

already delivered Product Backlog items in the form of the increment and

• the plans for what will be delivered next in the form of the Sprint Backlog

Based on these inspections, which include the feedback from stakeholders and information about the conditions surrounding the product , the Product Owner defines what will likely be built next . The Scrum Guide uses the term ' probable', to outline that these items may change, as alterations to the Product Backlog

7 Scrum Events

157

may be made at any time by the Product Owner, including throughout the subsequent Sprint Planning ,

The Product Backlog may also be adjusted beyond the scope of what will likely constitute the upcoming Sprint. The Scrum Guide provides "new opportunities" as the reason for this, which may come in the form of new ideas from key stakeholders, ideas presented and discussed by the Product Owner or reactions to newly attained information about the marketplace.

7 Scrum Events

158

7.5 Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective provides a forum for inspection of the Scrum Team by the Scrum Team. In this sentence, the Scrum Guide does not specify the categories of what is to be inspected, and in further sentences, it narrows the scope down only slightly, to four very broad areas. Therefore, it is left up to the Scrum Team to determine where inspection might yield the greatest insights.

The inspection conducted during the Sprint Retrospective is done in order to create possible improvements. A plan for how to improve in the next Sprint is crafted during the Sprint Retrospective. The dedicated timeslot for this meeting, the settings ensured by the Scrum Master and the participation based on the value of openness provide the necessary transparency for empirical process control. On this basis, the Scrum Team conducts an inspection and develops subsequent (possible) adaptations.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one- month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.

These sentences are analogous to the ones describing the timebox and Scrum Masters involvement in the Sprint Planning 1

.

10

see paoe 123

7 Scrum Events

159

The Scrum Master ensures that the meeting is positive and productive. An inspection of the team by the team, which includes inspection of people and relationships, has the potential to become destructive. On the other hand, the limited time-box and the wide scope of what can be inspected bear the risk of losing focus and running out of time without concrete results. The Scrum Guide defines the Scrum Master as responsible for the quality of the meeting. However it does not provide details on how this is to be achieved beyond the broad requirements of positivity and productivity. This leaves the Scrum Master with a large number of possible approaches , only limited by the Scrum Values. The Guide does not even, like at other times, determine that the role of the Scrum Master in the Sprint Retrospective is that of a Choosing appropriate approaches for the Sprint facilitator. Retrospective is highly contextual, as it depends on the product , environment and the team involved. Therefore, Scrum as a framework only defines the broad requirements, leaving the manner in which these are to be achieved up to the Scrum ,

Master.

The Scrum Master teaches all to keep it within the time-box .

This sentence is analogous to the one describing the Scrum Master 's role in the Sprint Planning.1

" see page 124

7 Scrum Events

160

The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process. The Sprint Retrospective differs from the other events within a Sprint in that the Scrum Master actively participates as what the Scrum Guide calls "a peer team member", instead merely facilitating or ( occasionally) observing to provide feedback . All events within a Sprint aim at inspecting at least one thing:

• The Planning inspects the Product Backlog and business objective, for which the Product Owner is accountable, and the Development Team capacity, for which the Development Team is accountable.

• The Daily Scrum inspects the Sprint Backlog

,

for which the

Development Team is accountable

• The Sprint Review inspects the increment

, the delivery of which is in the Development Team s accountability and the Product Backlog, which is the accountability of the Product Owner

The Retrospective inspects, among other things, the functionality As the Scrum of the Scrum process for the Scrum Team process, its implementation and understanding are the accountability of the Scrum Master, they need to participate in a role, where they receive feedback and inspect along with their

.

,

peer team members.

The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;

• Identify and order

the major items that went well and potential improvements; and,

• Create

a plan for implementing improvements to the way the Scrum Team does its work.

7 Scrum Events

161

The points draft a layout for the Sprint Retrospective. The team inspects how the last Sprint went along the metrics of:

• people,

which may be members of the Scrum Team, stakeholders or others in contact with the team , such as members of the parent organization

• relationships, especially the ones within the team and those between the team and the stakeholders

• process

referring to the overall product development process within the Scrum framework, as well as the implementation of Scrum ,

• tools, which

, for example, may refer to the tools used in the development work. Product Backlog management or testing

This inspection provides the basis for identifying major items. Two categories are defined by the Scrum Guide: those items that represent what went well, and those that represent potential improvements. Differentiating between things that went well and potential improvements, rather than between things that went well and those that did not, outlines that the Sprint Retrospective should aim for a solution-oriented approach, rather than a problem-oriented one.

Items of both categories are ordered. How the items are to be ordered is left to the Scrum Team, similar to how the ordering of the Product Backlog is left up to the Product Owner.

Finally, the team creates a plan for implementing improvements, taking what went well and the potential improvements from before, as well as the outlook of the next Sprint into consideration. The Scrum Guide emphasizes that these improvements are not limited to the work of the Development Team but aim at the way the entire Scrum Team works.

7 Scrum Events

162

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.

This sentence contains the following crucial components:

• "The

Scrum Master encourages the Scrum Team to improve" - A Scrum Team that does not wish to improve, will not improve. Empirical process control in Scrum has the potential to serve to perpetually adapt to the situations discovered throughout product development This does , however, require a desire for improvement by those applying empirical process control. Therefore, the Scrum Master has to, in necessary, encourage the Scrum Team to improve and thus lay the foundation on which improvement may take place .

• "within the Scrum process framework" - The improvements made have to be compliant with the Scrum framework, i.e., they may not violate the values or break the rules of Scrum. Should a Scrum Team decide, for example, that the Product Owner assigns tasks to individual developers, this would violate the self-organization of the Development Team. The Scrum Master 's task in this scenario would be to explain why this would not be a valid improvement proposal.

• "its

development process and practices' The improvements are focused on the development process and practices. The word process refers to the way the Scrum Team organizes itself and the work on a larger scale within the Scrum framework. The process, for example, includes events and agreements regarding Product Backlog refinement , the definition of "Done" or the duration of a Sprint.

The practices refer to individual aspects within the process , such as the use of Story Points for estimations, specific

7 Scrum Events

163

automated testing suites or the way the increment is demonstrated during the Sprint Review.

-

• to

make it more effective and enjoyable" With this section, the Scrum Guide provides the reasons for improvement, which are an increase in both effectiveness and enjoyability. These two aspects are not portrayed as contradicting each other or having to be weighed against each other but are instead listed as equal parameters. This idea reflects the fifth principle of the Agile Manifesto, which starts with "Build projects around motivated individuals*. This idea breaks with traditional process improvements, which usually are focused exclusively on efficiency improvements, often disregarding eniovment.M 4l "

• "for

-

This is used to highlight that the next Sprint " improvements should aim to improve the situation of the next Sprint. Large ideas that may be developed, whose implementation takes a longer period of time, should be broken down into an iterative process, and steps should be taken immediately. The section also outlines that the improvements are not permanent fixtures, but experiments conducted for the duration of one Sprint, after which the efficacy of the improvement is revisited, and further adjustments may be made.

During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of "Done '*, if appropriate and not in conflict with product or organizational standards.

One goal of the Sprint Retrospective is to determine way to improve the quantity of what can be delivered. Another goal, which is described in this sentence, is the improvement of the quality of the product that is being delivered by the Scrum Team. The Scrum Guide, therefore, requires the Scrum Team to inspect

7 Scrum Events

164

its development process and the current definition of 'Done' and make adaptations if deemed appropriate. These adaptations may not create conflicts with other established standards.

By the end of the Sprint Retrospective , the Scrum Team should have identified improvements that it will implement in the next Sprint . Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

The Sprint Retrospective serves as an opportunity for inspection of standards and processes. A standard like the Definition of "Done" may be changed during the Retrospective, which would be an adaptation following an inspection . Other improvements are, at the end of the Sprint Retrospective, plans that will be implemented in the next Sprint . For these improvements, the Sprint Retrospective provides transparency and an opportunity for inspection and the upcoming Sprint is the opportunity for the adaptation. ,

In the last sentence , the Scrum Guide emphasizes two aspects:

• The Sprint Retrospective provides a formal opportunity to inspect and adapt , meaning a time specifically designated for these activities. It, therefore, fosters empirical process control within the Scrum framework.

• Identifying and implementing improvements is not restricted to the Retrospective, but may be done at any time, including but not limited to the Daily Scrum.

8 Scrum Artifacts

165

8 Scrum Artifacts Scrums artifacts represent work or value to provide transparency and opportunities for inspection and adaptation.

The Oxford English Dictionary defines the term artifact as "something observed in a scientific investigation or experiment that is not naturally present but occurs as a result of the preparative or investigative procedure **. This terminology relates to empirical process control on which Scrum is based.

The Scrum Guide understands the artifacts as a representation of work or value. The Product Backlog represents potential product value that may be realized through the Development Team s work in the future. The Sprint Backlog represents a plan of the Development Team s work in the Sprint. The Increment is a representation of the combined value delivered since the first Sprint. The purpose of artifacts is defined as supporting empirical process control by providing transparency and opportunities for inspection and adaptation. This can be compared to the sentence [ the] events are specifically designed to enable critical transparency and inspection" J Scrum and its aspects are set up to enable and foster empirical process control.

see corresponding quote on page 109

8 Scrum Artifacts

166

Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

This sentence is a reference to the Scrum Guide's section on transparency.- In this, it states that "significant aspects of the process must be visible to those responsible for the outcome", which mirrors in the present sentence as "transparency of key information”. Both sections restrict the need for transparency to information crucial to the success of product development. The transparency section further states that transparency "requires those aspects [to] be defined by a common standard so observers share a common understanding” , which the Guide claims the artifacts have been "specifically designed" for. The Scrum Guide claims that the setup has been so that transparency is maximized. How this is achieved is outlined in the respective sections below.

2

see the section on transparency on pages 29»

8 Scrum Artifacts

167

8.1 Product Backlog

The Product Backlog is an ordered list of everything that is known to be needed in the product . Two characteristics in this sentence define the Product Backlog:

• It

contains "everything that is known to be needed in the

product”. This statement makes two implicit requests:

- The Product Backlog is the artifact in which all available information on what is needed for the product is gathered Once information becomes ,

available that relates to the product , it must be worked into the Product Backlog. This ensures that there is a single source of truth, allowing for transparency and a simple inspection of the current status of plans for the product .

- The Product Backlog collects only information that is needed for the product . This focus makes it easier for those inspecting the Product Backlog to understand the current state of plans for the product and thereby fosters transparency.

• It is maintained in the form of an ordered list.

An ordered list ensures that there are items that , by some measurement defined by the Product Owner , more important and some that are less important. This hierarchy of importance is represented in the ordering of the list . An ordered list, usually implemented in the form of important items at the top. provides an intuitive, easy-to-understand visualization mechanism for all those inspecting the Product Backlog. This setup increases the understanding of the Product Backlog and, therefore , its transparency.

8 Scrum Artifacts

168

It is the single source of requirements for any changes to be made to the product.

This sentence underlines the argument implicitly made in the prior sentence. The Product Backlog serves as a single source of truth regarding change requirements. Requirements for changes to the product that are not contained in the Product Backlog are not valid according to the Scrum Guide. This artificial restriction forces the Scrum Team, especially the Product Owner, to ensure that all requirements are placed in the Product Backlog, where they are transparent.

The Product Owner is responsible for the Product Backlog , including its content , availability, and ordering.

The section defining the role of the Product Owner outlines that the management of the Product Backlog is the responsibility of the Product Owner. In this sentence, the Scrum Guide underlines this idea by assigning to the Product Owner the responsibility for its content and its ordering. Furthermore, it assigns the responsibility of ensuring the availability, meaning the existence and the transparency towards others, to the Product Owner.

A Product Backlog is never complete.

In more conventional product development approaches, plans for the product are developed and written down in some form of a project plan. The closest equivalent to this in Scrum is the Product Backlog, which lists requirements that may be turned into features and capabilities. With this sentence , however , the Scrum Guide distances the Product Backlog from project plans, which are finished at some point and then handed over to be developed. The Product Backlog, however, is at no time "complete". It reflects the best understanding of what could deliver value at any given time, and as requirements and market potential are always changing , so does the Product Backlog.

8 Scrum Artifacts

169

The earliest development of it lays out the initially known and best-understood requirements.

The Product Backlog underlies the principles of inspection and adaptation to evolve For the earliest development , meaning the first few Sprints of the Scrum Team, it reflects those requirements that are known at that point and that are best-understood. The latter serves to limit the risk of developing features that may have a higher value delivery, but are not understood well yet , due to the early stages of the product development.

The Product Backlog evolves as the product and the environment in which it will be used evolves.

The Product Backlog reflects what is currently known about the product requirements and how the Product Owner ranks these . The evolution of the product , referring to the ongoing development and addition of features and capabilities to the Increments, has effects on the requirements. So does the environment in which the product will be used, which may include, among others, the customer, users, marketplace and general technological trends. The Product Backlog evolves to reflect these changes and therefore

• the composition, i.e., what items are in it, as well as

• the ordering, i.e., how it reflects maximizing value evolve along.

The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate , competitive , and useful.

The Product Backlog is described as dynamic, by which the Scrum Guide differentiates it from conventional project plans, which are relatively static once the phase of project planning has been finalized.

8 Scrum Artifacts

170

Being dynamic is defined as constantly changing , lay which the Guide expresses that the Product Backlog changes throughout all stages of the product development. The purpose of these changes is given as ensuring that it is identified what the product needs to be:

• appropriate, i.e..

something that can be handed over to a

user

• competitive , i.e.

something that can compete with similar products, potentially in an open marketplace ,

• useful, i.e. , something that adds value for

those using the

products

If a product exists, its Product Backlog also exists.

The Product Backlog is an instrument to make the current status of what is known and the direction the product development is planned to go transparent . This transparency drives empirical process control in Scrum and is obligatory as long as the product exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

Items in the Product Backlog reflect what should be changed about the product in the future. Change in this circumstance includes both additions and alterations of existing parts of the product. Using "ail” in this sentence further underlines the idea that everything known about the (potential ) direction of the product must be reflected in the Product Backlog to create transparency. The categories given in this sentence are:

• features: pieces of functionality that serve a purpose for the user, e.g., being able to store one's score in a mobile game in the cloud

8 Scrum Artifacts

171

• functions:

in this context refers to the product's ability to do something , usually within the context of a feature , e g. , a login mechanism to connect to the cloud, allowing score synchronization

• requirements: a need or want, in this case by a stakeholder, e g. , a user might want to use social media for their login, while a key stakeholder may want only certain social media methods to be possible

• enhancements: improvements to the existing features and functions, e g. , adding a new social media sign- on method beyond the three already offered

• fixes: repairs to existing features or functions, e.g. . updating the sign-on methods after an API change lead to an existing one not working anymore

Product Backlog items have the attributes of a description, order, estimate, and value.

Scrum makes few prescriptions regarding the Product Backlog and its items. One of the few mandates the Guide gives though is reflected in this sentence, listing the (minimum) attributes each Product Backlog item must have:

• Description:

The item is formulated so that it can be understood by the Development Team. This mandate is in place to ensure that the Development Team is capable of turning the item into a piece of an Increment without the need for extensive clarification to save potential time waste. The form and scope of the description are left to the Product Owner and should be agreed with the Development Team.

• Order : The Product Backlog is an ordered list, outlining the current assessment of the Product Owner on what items hold the highest priority. This order is not necessarily the same as value, as a high-value item that takes a long time

8 Scrum Artifacts

172

to implement may add less immediate value than a lower The exact value item that is quickly implemented ,

mechanism of ordering is not prescribed and is left up to the Product Owner.

• Estimate:

Each item is estimated by the Development Team , in order to estimate during the Sprint Planning how many and which items can likely be implemented during a Sprint. The method chosen for estimating is left to the Scrum Team; typical examples are Story Points and t-shirt sizes, estimating either effort , complexity or a combination thereof. The decision on this is up to the Scrum Team.

• Value:

Items in the Product Backlog must hold some measurement of value. This, together with the estimated provided by the Development Team, allows the Product Owner to determine what they believe to be the maximum possible value to be delivered by the work of the Development Team. Value ultimately reflects the Product Owner's belief of what constitutes value, as they are the one taking the - often highly subjective - decision on what value an item in the Product Backlog is believed to hold.

Product Backlog items often include test descriptions that wilt prove its completeness when "Done”.

In addition to the four attributes required , the Scrum Guide states that test descriptions are often included . They are not mandatory but good practice.

The goal of test descriptions is to give pre-defined criteria to validate the completeness of item beyond the criteria in the Definition of "Done". Such test descriptions may be highly technical, for example, defining minimum standards for penetration test results on a security-critical feature. They may also be much simpler, for example, describing that a user on their phone must be able to fill and submit a form without an error occurring.

8 Scrum Artifacts

173

As a product is used and gains value, and the marketplace provides feedback , the Product Backlog becomes a larger and more exhaustive list.

Once the product is released to the users, it gains value. The potential value the Product Owner aimed at maximizing the work of the Development Team for is realized . The marketplace , in this case being used symbolically for the sum of users, customers and other outside stakeholders, provides feedback on the product, which can be used to determine the future course of the product. Feedback from the marketplace allows the Product Owner to explore more possibilities for future development, which are reflected in the Product Backlog. Thus, it becomes larger and more exhaustive, meaning that the list that constitutes the Product Backlog contains more items and that those items describe a larger number of different paths to explore.

This sentence also refers back to an earlier one. in which it was indicated that the initial Product Backlog needs only to consist of a few requirements that are best understood. The Product Backlog grows with the knowledge about the product ; hence as more is learned, the Product Backlog will become more exhaustive.

Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

These sentences outline a fundamental understanding of product development in Scrum. Where in the past product development projects may have been over at the point when the product was "finished".

Scrum instead understands the product as a solution to a complex , adaptive problem consisting of changing requirements. As requirements change and are understood by the Product Owner, the Product Backlog changes accordingly, which is why it

8 Scrum Artifacts

174

is referred to as a living artifact ”, as compared to a static requirement list as in waterfall projects.

The Scrum Guide gives the following possible causes for requirement changes and subsequently for changes to the Product Backlog:

• Business requirements, which refers to the requirements of the users. As the situation for which the product was developed changes, so do the requirements for the product.

For example, a system for managing a logistics center has to be extended as a new workflow process in the center has been implemented, which needs to be reflected in the software.

• Market conditions,

which refer to the products standing in the wider market , covering aspects such as direct competition, general market trends and the overall economic situation. As the market changes, so must the product to remain competitive.

For example, the general trend in the logistics industry may be moving from custom-built software to more generic software- as- a-service solutions, forcing the product to be altered towards more flexible use at different locations and under different conditions.

• Technology,

which refers to the technological possibilities available and useful. As technology progresses, more and different features may become possible and even expected if the product should remain competitive.

For example the wide and availability of NFC readers in mobile phones and, therefore their relatively inexpensive availability may make identifying items in the logistics center via RFID a new feature that might help the users. ,

,

8 Scrum Artifacts

175

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

Scrum Teams are limited in size to nine Development Team members. Larger products may justify the need to have more developers than can fit in one Scrum Team. In those cases , the Scrum Guide prescribes that multiple Scrum Teams should be formed, which work on the same product, delivering one integrated Increment . To ensure transparency, one Product Backlog is maintained for one product to act as a single source of truth. Therefore, even with multiple Scrum Teams, a product will only have one Product Backlog and subsequently, only one Product Owner responsible for it. The Product Backlog describes the upcoming work on the product , regardless of whether one or multiple teams pull work from it. In the final sentence, the word "may" is not intended to convey permission, implying that a grouping attribute is not permitted if only one Scrum Team works on the product . Rather, the Guide gives an optional practice of grouping items. Whether such an attribute is used and by what criteria these groupings are done remains up to the Product Owner.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

Product Backlog items are defined as having the attributes of description , order, estimate, value. All of these, except for the value, are addressed in the Product Backlog refinement:

• Detail is added during the refinement process, referring to the quality and quantity of the description, as well as other factors such as testing requirements. A sufficient level of detail , as determined by the Development Team and the

8 Scrum Artifacts

176

Product Owner, allows for the item to be understood and subsequently estimated.

• Estimates

are given by the Development Team for each item. These generally refer to either the complexity of the item, the effort needed to deliver it , or some combination of both.

• With

the value having been determined by the Product Owner and the estimate having been provided by the Development Team, the Product Owner can re-order the Product Backlog according to their criteria of value maximization. These may include the ratio of eflort and value, which becomes apparent throughout the refinement , as well as dependencies and synergies between items revealed throughout the process of adding detail.

The goals of Product Backlog refinement are to:

• foster the understanding of what are possible next steps in the product development,

• raise transparency towards the Product Owner of the work required for implementing items and

• raise

transparency towards the Development Team about the content of individual Product Backlog items, ensuring they are understood and can be implemented in a future Sprint

This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. As the Product Backlog is a living artifact , Product Backlog refinement is necessary as long as the product is being developed. The process of adding details involves the Product Owner and Development Team collaborating, as both have an active interest in a sufficient level of detail of each item.

8 Scrum Artifacts

177

The Product Owner needs to ensure that the Development Team has enough detail to provide a qualified estimate on an item . The Development Team needs to ensure the level of detail is high enough to deliver the item into an Increment with as little dependency on the Product Owner as possible.

Some teams may choose to define the criteria of what constitutes a sufficient level and refer to it, analogously to the Definition of "Done”, as the Definition of "Ready”.

During Product Backlog refinement, items are reviewed and revised.

With this sentence, the Scrum Guide defines Product Backlog Items are "reviewed". refinement as an iterative process, meaning they are inspected potentially multiple times, and adaptations are made as necessary, which the Guide expresses as items being "revised”. As the conditions around the product change , items in the backlog may change not only regarding value but also in terms of necessary details, estimation and order. For example, an item has been estimated to have eight story points: however , due to improved technological capabilities , the item is re-estimated as only three story points. This makes the Product Owner re-assess the return on investment of the item and give it a higher priority in the Product Backlog.

The Scrum Team decides how and when refinement is done.

Product Backlog refinement is not a prescribed Scrum Event , noticeable among other things by the lack of capitalization of the word "refinement" throughout the guide. Unlike the events, which have defined cadences and sets of requirements, the details of the refinement are left up to the Scrum Team . Some teams may choose to integrate regular refinement meetings into their

8 Scrum Artifacts

178

Sprints: others may spontaneously conduct ad-hoc refinements when they become necessary.

The format of refinements may vary widely. In some teams, a refinement may involve all of the Development Team for all occasion; others may choose to separate into smaller groups and work on items in those.

Refinement usually consumes no more than 10% of the capacity of the Development Team.

Here, the Scrum Guide gives a guideline rather than an explicit rule. Refinement should ideally take up no more than 10% of the Development Team's capacity. This may, at times, be easy to achieve, however, especially in early Sprints or in times of rapid Regularly changes, this percentage may be exceeded exceeding 10% can be used as an indicator for the Scrum Team, that the refinement process needs to be inspected and that improvements may be necessary. ,

However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner ’s discretion.

The suggested limit of 10% in the previous sentence refers explicitly only to the Development Team. The Product Backlog should reflect what is currently known about the potential next steps for the product. Therefore, the Product Owner, as the person responsible for the Product Backlog , may at any time make changes or request others to make changes on their behalf .

8 Scrum Artifacts

179

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail.

With these sentences , the Scrum Guides gives a recommendation rather than a prescriptive rule. "Higher

ordered’ refers to those items that are deemed more important according to the metrics of the Product Owner.

Refining only higher-ordered items thoroughly ensures that the details are being added when the item will likely be implemented soon. Thus , adding details and ensuring clarity relatively late minimizes the risk of waste. Furthermore, the details added reflect the knowledge that is still recent and, therefore, less likely to have been affected by changes, for example, in the technological environment of the product.

The second sentence can be read in two ways: On the one hand, it might express that the quality of estimates is higher when they are based on greater clarity. In this sense, the Guide would give a cause and effect relationship, pointing out that a higher degree of clarity and detail leads to better, "more precise", estimated. On the other hand, it can be read as recommending an iterative approach to estimations , i.e. , suggesting that rough estimates are made for less clear and detailed items and revised, more precise, estimations are made, when the degree of clarity and detail increases.

Both readings are valid and mutually complementary. The second interpretation is supported by a prior sentence, which describes that items are "reviewed and revised” , as well as the idea that the Product Backlog should maximize transparency. Items that are higher ordered are often broken down into smaller units to allow for more detailed estimates.

8 Scrum Artifacts

180

PBI PBI

Higher priority Hems, broken down and more property refined

PBI

PBI

PBI

Lower priority items, less broken down and less refined

Figure 8.1: An illustration of a Product Backlog

Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be ’’Done” within the Sprint time-box . Product Backlog items that can be Done ” by the Development Team within one Sprint are deemed Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above-described refining activities.

While the Scrum Guide leaves the overall state of clarity and level of details of the Product Backlog items up to the Scrum Team, it makes a clear requirement for those items that will be pulled into the next Sprint Backlog. These items must be refined so that they can be ’’Done" within the next Sprint .

8 Scrum Artifacts

181

The expression "items that will occupy . .. the upcoming Sprint” implies at least one of two things to be necessary:

• The

team must be aware of what items will ( very likely ) constitute the upcoming Sprint , so that it can ensure those items to be sufficiently refined.

• Refinement

may need to take place during the Sprint Planning, if the scope of the Development Team's forecast exceeds the capacity of "Ready" items in the Product Backlog.

A Product Backlog item should be 'Ready'' before it can be selected during the Sprint Planning. The exact definition of what constitutes "Ready" is left to the Scrum Team, especially to the Development Team, but must , according to the Scrum Guide, contain the possibility of that item being "Done" within one Sprint .

While refinements within a Sprint Planning are not explicitly forbidden and may, at times, be necessary to ensure that a high- value item can be placed in the Sprint Backlog, the Scrum Guide clarifies in the third sentence , that this is not the norm. Rather, the refinement activities described in the earlier sentences should usually suffice to generate the required levels of clarity and details, which the Scrum Guide here refers to as the "degree of transparency".

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate. The Development Team is self-organizing and, therefore, must be able to estimate the work they will do. The decisions on the estimates are made only by the Development Team, as they will later be used along with the capacity forecast for a Sprint to

8 Scrum Artifacts

182

create a Sprint Backlog, which describes the work of the

self-organizing Development Team.

The Product Owner is involved in the estimation process by providing a greater degree of transparency of the business needs. Often multiple different scopes of realizing an item are possible ; in such cases, the Product Owner may work with the team to ensure they understand their Product Owner 's priorities and make trade-offs accordingly.

8 Scrum Artifacts

183

8.1.1 Monitoring Progress Toward Goals

At any point in time, the total work remaining to reach a goal can be summed.

The Product Backlog is used to create transparency about the work on the product and reflects, among other things, the work that may be done in the future. Goals are expressed in the form of achieving Product Backlog items. Based on the estimates provided by the Development Team during Product Backlog refinements, the total ( estimated) work remaining to reach any goal can be calculated.

The Product Owner tracks this total work remaining at least every Sprint Review.

With the Sprint Review, the development work of the Sprint ends. It is, therefore, possible to assess the progress made by the Development Team in realizing the Sprint Goal through the implementation of Product Backlog items. Differentiating between the items that have been finished and those that have not ( yet) been finished, allows the Product Owner to determine the total remaining work left to achieve a specific goal.

The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.

The Product Owner compares the remaining work at past Sprint Reviews with each other. Understanding the progress made towards a goal throughout the previous Sprints allows for forecasts to be made how much work the Development Team can likely achieve in the upcoming Sprints. This measure is then

8 Scrum Artifacts

184

compared to the remainder of work towards the goal at the current (or most recent ) Sprint Review.

This process allows the Product Owner to make projections about when the goal will likely be achieved. This projection is iteratively adjusted, after every Sprint a new projection is made, and with more data about previous performance available and less remaining work each Sprint, the accuracy of the projections increases over time. The information is made transparent to all stakeholders, to allow for potential adjustments to the goal, further feedback, or for the stakeholders to use it for their own respective planning processes.

Various projective practices upon trending have been used to forecast progress, like bum-downs, burn-ups, or cumulative flows. These have proven useful.

The process conducted by the Product Owner described above can be aided by tools. The Scrum Guide gives the examples of

• burn-downs, which track and visualize the remaining work over time towards a goal: they are usually assuming a finite and known amount of total work; they often contain a trend line expressing when the entire work should be finished

• burn-ups, which track and visualize the total work done over time and the total known work necessary for achieving a goal; with burn-ups, the work necessary can be increased over time as more is learned; they often contain a trend line predicting when the total work done will be equal to the total work necessary to achieve the goal

• cumulative

flows, which are commonly used in Kanban, track and visualize the cumulated number of items in each development stage (e.g., To-Do, In- Progress, Testing, Done)

8 Scrum Artifacts

185

The Scrum Guide does not prescribe either of these tools, does, however, achkowledges that using them has proven useful in applying Scrum.

•6m

•1

u u i) M n H t r i i

» x a

Figure 8.2: An example of a burn-down chart

Figure 8.3: An example of a burn-up chart

8 Scrum Artifacts

186

«

-

Figure 8.4: An example of a cumulative flow diagram (CFD)

However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.

The use of burn-downs, burn-ups and cumulative flows can assist the Product Owner. These tools do not replace empirical process control, though. The trend line of a burn-up chart, for example, is only a projection based on what is currently known and assumes conditions to remain as they have been on average in the past. Such an assumption cannot be reasonably made in complex environments, as what will happen in the future cannot be known by definition.1 Therefore, employing such tools is only useful when combined with frequent inspection and subsequent adaptation of the key parameters and if always bearing in mind that the projections made are only forecasts, which may change, possibly even significantly, as more is learned.

3

see explanation of complexity in the Cynefm Framework on pages 7«.

8 Scrum Artifacts

187

8.2 Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

The Sprint Planning is created to determine for the Sprint:

upcoming

• What can be delivered? • How can it be delivered? The Product Owner and Development Team collaborate on what items are selected for the upcoming Sprint, determining what will be delivered. The Development Team also creates a plan for turning the selected items into an Increment that will fulfill the Sprint Goal. These two parameters, the selected items on the one hand, and the plan on how to turn them into an Increment to realize the Sprint Goal, are together referred to as the Sprint Backlog.

The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a ’ Done ” Increment.

.

In this sentence, the crucial word is "forecast" As the creation of a new Increment constitutes a complex problem, there can be no certainty about what functionality can be added and how the necessary work should best be done. Therefore, the Sprint Backlog is not a static artifact but instead serves as a reflection of the current assumption of the Development Team on what it can deliver by the end of the Sprint and how this is best done.

8 Scrum Artifacts

188

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal.

The purpose of the Development Team s work in the Sprint is to achieve the Sprint Goal through an Increment, The work necessary and the scope of what will be done in the Sprint may change as more is learned. These changes are made through empirical process control, for which transparency is required. This transparency is provided by having the work visible, for which Scrum defines the artifact of the Sprint Backlog. There is no prescribed format for a Sprint Backlog, and the Guide only demands that it creates visibility and thus transparency, often realized in the form of a physical board, sometimes referred to as a "Scrum Board".

To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting. The goal of incremental empirical process control is the improvement of the process over time. To improve the process of product development, improvements must not only be determined ( transparency and inspection) but also implemented (adaptation). To ensure this implementation takes place, the Scrum Guide mandates that at least one process improvement from the last Retrospective should be included in the Sprint Backlog.

The included improvement is described as having to be "high priority ", a determination that is left up to the Scrum Team.

8 Scrum Artifacts

189

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum.

The Sprint Backlog, as an artifact, was created to create transparency. In order to maximize transparency about the progress of the work of the Development Team, it must contain a sufficient amount of details. This allows the Development Team to inspect their rate of progress and potentially make adaptations to the Sprint Backlog or their process. The exact level of detail is not specified, however, it

• must be high enough

to allow for inspections during two consecutive Daily Scrums to generate insights about the progress , and

• should be low enough to leave the Development Team with enough flexibility

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

The Scrum Guide describes the Product Backlog as a living artifact , as it always changes in response to changing conditions around the product and is never 'finalized" or "finished" . An initial Product Backlog may be created when the product development begins; however, the Product Owner constantly changes it. Similarly, the plan within the Sprint Backlog is initially created by the Development Team but is not static after that point. Changes are made by the Development Team "throughout the Sprint’, meaning they only end once the Increment is presented during the Sprint Review. The Sprint Backlog is described as emerging , which the Cambridge Dictionary defines as "growing and developing".

8 Scrum Artifacts

190

This "developing" is done by the Development Team to ensure that the Sprint Backlog continually reflects what is known about the work needed and make the plan to conduct that work transparent within the team.

As new work is required, the Development Team adds it to the Sprint Backlog.

The Development Team may add new work to the Sprint Backlog as it deems necessary to achieve the Sprint Goal, The right to add work to the Sprint Backlog is reserved exclusively for the Development Team, as it is self -organizing. This "work", however, does not refer to the Product Backlog items contained in the Sprint Backlog, but only to the work planned for delivering them. Changes to Product Backlog items in the Sprint are negotiated with the Product Owner.

As work is performed or completed, the estimated remaining work is updated.

The Sprint Backlog is a plan for achieving a Sprint Goal. To be able to understand the progress towards that goal and to make changes if necessary, the Sprint Backlog must create transparency on how much work is left in the Sprint. Therefore, the Scrum Guide prescribes that upon finished work, the remaining work in the Sprint Backlog must be re estimated

.

-

-

In practice, this is often done in the form of a burn down chart , which displays the amount of work done and the amount of work still left over a time axis.4

* for an example of a burn-down chart, see page 185

8 Scrum Artifacts

191

When elements of the plan are deemed unnecessary, they are removed.

-

The Development Team is self organizing and aims for efficiency. Therefore, it is free to remove work from its Sprint Backlog. The term elements of the plan" does not refer to Product Backlog items, as their removal must be coordinated with the Product Owner, but to parts of the plan on implementing the Product Backlog items to realize the Sprint Goal.

Only the Development Team can change its Sprint Backlog during a Sprint.

-

The Development Team is self organizing, meaning it organizes how it does its own work. As the Sprint Backlog is an artifact that represents the best knowledge and plans of the Development Team regarding their work, changes to the Sprint Backlog may only be made by the Development Team.

There may, however, be a need for the Development Team to coordinate with the Product Owner on addition or removal of Product Backlog items to or from the Sprint Backlog.

The Sprint Backlog is a highly visible , real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team. The Sprint Backlog as an artifact is created to maximize transparency about the planned work of the Development Team. Therefore, the Scrum Guide defines two characteristics it must fulfill:

The Sprint Backlog must be highly visible, as this allows for transparency. While not required by the Scrum Guide many teams choose to maintain their Sprint Backlog as a physical ,

8 Scrum Artifacts

192

board, modeled after Kanban boards and sometimes referred to

as "Scrum Boards*.

Furthermore, the Sprint Backlog must reflect changes in real- time, as this ensures that decisions based on the Sprint Backlog always reflect the most current knowledge on the work in the Sprint. The final part of the sentences outlines that the Sprint Backlog solely to the Development Team", which emphasizes the autonomy the Development Team has regarding all again changes to it but also ascribes the responsibility for maintaining it to the Development Team. "belongs

Finally, the section may be understood as giving the Development Team the right to choose how and to which degree they wish to make their Sprint Backlog transparency to persons who are not part of the Development Team.

Example of a Scrum Task Board Product

Sprint Backlog

In Progress

Peer

Review

In Test

Done

Blocked

Figure 8.5: An example of a Scrum Board, with the big cards representing Product Backlog items (e.g. in the format of stories ) and the smaller representing decomposed, smaller units of work (e.g. in the format of tasks)

8 Scrum Artifacts

193

8.2.1 Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed.

The Sprint Backlog is used to create transparency about the work in the Sprint and reflects, among other things, the remaining work. This count is updated as work is performed or completed.5 Therefore, it is possible to add up the estimates of how long the remaining work will take.

The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.

The Development Team is supposed to use this sum and compare it to the available capacity. This inspection should be done frequently, at least during every Daily Scrum. Comparing the projection of how much more work is necessary with the available capacity of the Development Team until the end of the Sprint allows the Development Team to make a statement on the likelihood of the Sprint Goal being achieved if key parameters remain as they are. If the projection of remaining work is significantly smaller than the available capacity, the Sprint Goal will likely be achieved. If the two are of a similar size, the Development Team should inspect the two regularly and carefully to ensure that the Sprint Goal can be met . If the available capacity is significantly lower than the projections , the Development Team has to adapt by making adjustments to their plans, their process or - if deemed necessary - to the items in the Sprint Backlog in coordination with the Product Owner .

5

for more detail see page 190

8 Scrum Artifacts

194

By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Continually tracking the remaining work, especially as compared to projections about work being done, creates transparency about the results generated by the Development Team. This transparency can be used to inspect the development process and, if necessary, make adaptations. This is what the Guide refers to when speaking of managing progress.

8 Scrum Artifacts

195

8.3 Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. In this sentence, the Scrum Guide differentiates two spelling of the term, one using a leading capital letter , implying a proper noun, while the other is written with a leading lowercase letter, implying

a common noun. An "increment ”, written in lowercase, describes the sum of Product Backlog items "Done” during a Sprint and the value of previous increments. It is therefore, the total sum of all the work of all the Sprints. This spelling indicates the descriptive term, i.e.. the result of an incremental process.

.

The "Increment ”, written with a capital T, refers to the artifact and exclusively to the increment of the current Sprint. Thus, every Increment is an increment, but not every increment is the Increment. The Increment is not only the result of the work of the current Sprint, but also explicitly includes the results of previous Sprints. Thus, an inspection of the Increment always refers to the inspection of the sum of all work of the entire product as it is right now. This creates transparency about the entire product including how the most recent work functions together with previous work.

.

8 Scrum Artifacts

196

At the end of a Sprint, the new Increment must be Done,*' which means it must be in useable condition and meet the Scrum Team s definition of ’ Done '.

The purpose of a Sprint is to deliver an lncrement . 6 This Increment is inspected during the Sprint Review and must be potentially releasable if the Product Owner decides to release it. Therefore, it must adhere to the quality standards defined in the definition of *Done".

An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. An increment (note the lowercase Y) is understood by the Scrum Guide as work in the direction of a vision or goal. This implies the need for the product being developed to have a vision or goal that provides the direction for product development. The work that is done must be inspectable at the end of the Sprint, thus allowing for empirical process control to be usable. The specific requirements of what inspectable means is contextual.

The increment must be in useable condition regardless of whether the Product Owner decides to release it.

The goal of the Scrum Team is to produce an increment at least by the end of every iteration that could be potentially shippable. Usable in this sentence refers to the ability of the increment to be used by the end-users, which is one criterion for reusability. Ensuring the increment is always in usable condition allows there to always be a potentially shippable increment that the Product Owner could release when they deem it necessary.

6

see section The Sprint on page 112

9 Artifact Transparency

197

9 Artifact Transparency Scrum relies on transparency.

The foundation of Scrum is empirical process control.1_The Scrum Events and the roles within a Scrum Team rely on transparency to execute an inspection and possible subsequent adaptation to adjust to new challenges in complex environments and improve the product development over time.

Decisions to optimize value and control risk are made based on the perceived state of the artifacts.

The purpose of Scrum is to allow delivery of value while managing risk . This can most notably be seen in the role of the Product Owner as a maximizer of the value of the Development Team's work and Scrum’s use of Sprints to limit the risk of waste to at most a month. The artifacts ( the Product Backlog. Sprint Backlog and Increment ) are created to reflect what is currently known about the product , its requirements and the immediate next steps in its development as well as possible. They have to do this in a manner that is visible to those responsible for the respective outcomes and that everyone inspecting the artifacts has the same understanding of what they are seeing . The artifacts have to be transparent.

see the section on empirical process control on pages 2411.

9 Artifact Transparency

198

The artifacts further serve as the basis on which decisions are made. For example:

• The

Product Backlog provides the Scrum Team with an understanding of which next steps have priority for the upcoming Sprint and is the source from which items are pulled into the Sprint Backlog.

• The

Sprint Backlog allows the Development Team to inspect their progress towards the Sprint Goal and make adjustments to their plans if necessary.

• The

Increment provides the Scrum Team and its stakeholders an understanding of the current functionality and capability of the product , which in turn allows for common decisions to be made on the next steps.

To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent , these decisions can be flawed, value may diminish and risk may increase.

The best decisions can be made if the artifacts are completely transparent. The decisions made based on completely transparent artifacts may still be wrong, as in complex environments, even transparency does not create certainty ; however, they are more likely to be correct and more likely to limit risk and maximize value. This is what the Guide refers to as decisions having "a sound basis". If artifacts are, however, not transparent , decisions will have a less sound basis. The decisions made on this basis may still be correct: however, the likelihood of flawed decisions is increased, and subsequently, the risk may increase and value be diminished.

The Scrum Guide uses the expression ’[to] the extended" for both cases, implying that transparency is not a boolean parameter, that is either fully achieved or not achieved at all, but

9 Artifact Transparency

199

rather a parameter that can be more or less achieved for each of the artifacts. In the following sentences, the Scrum Guide explains the process of maximizing transparency.

The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent. The Scrum Master is tasked with ensuring the transparency of the artifacts. To do this, they have to work with those using the artifacts to gam a collective understanding of whether or not the artifacts are ’completely transparent” and if not to what extent they are not.

There

are practices for coping with incomplete transparency ; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency. If the inspection reveals a lack of transparency, the Scrum Master must work towards increasing transparency. However, as this

may be a lengthy process, the Scrum Guide outlines that mitigations for the time until complete transparency is achieved should be used. The Scrum Master is responsible for everyone understanding how best to make decisions and apply the best practices in the absence of complete transparency. This approach allows the Scrum Team to deliver the highest value it can. while at the same time adjusting their artifacts.

9 Artifact Transparency

200

A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.

In this sentence, the Scrum Guide provides broad pointers to the Scrum Master for how to determine whether or not transparency is complete. The advice given is:

• inspecting

the artifacts: this may reveal more obvious impediments to transparency, such as the missing visibility of the Product Backlog to the stakeholders

• sensing

patterns: this refers especially to patterns of behavior, such as Development Team members hiding technical debt from the Product Owner, thus lowering the transparency of the Increment

• listening

closely to what is being said: attentiveness to details in conversation may reveal implied statements on the lack of transparency; for example: a stakeholder criticizing the Product Owner during the Sprint Review for not providing a clear picture of the next steps may be an indicator that they do not have a good understanding of the Product Backlog

• detecting differences between

expected and real results: inspecting the delta between what is expected to happen and what actually hap>pens can provide indications of a lack of transparency; if the differences are minimal, transparency is likely achieved , while large, repeated differences may be due to a lack of common understanding, i.e., transparency

9 Artifact Transparency

201

The Scrum Master ’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.

The Scrum Master is responsible for ensuring transparency of the artifacts and increasing it if it is found to be improvable. This work is highly contextual, but the Scrum Guide outlines that it must be done in collaboration with the Scrum Team and the organization. As the Scrum Master is a servant leader1 . their approach is not to force through what they believe to be transparency, but rather to ensure understanding in others of why transparency plays a crucial role in empirical process control and thus in the product development.

-

Therefore, the Scrum Guide outlines that this may be a lengthy process, which usually involves learning on the part of the Scrum Team and the organization, convincing done by the Scrum Master through good arguments rather than hierarchical authority and change to the way this is currently done

.

2

see the definition of a servant-leader on pages 84 T

9 Artifact Transparency

202

9.1 Definition of ’’Done”

When a Product Backlog item or an Increment is described as ’Done”, everyone must understand what " Done ” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of Done " for the Scrum Team and is used to assess when work is complete on the product Increment. *

The definition of "Done" is given as an example for the requirement of common standards to achieve transparency earlier in the GukJe.3aln order for empirical process control to work, those doing the inspection must have a common understanding of what is being observed. One factor for this is a shared understanding of when a Product Backlog item or an Increment is "Done". The Guide defines no requirement regarding the contents of the definition of Done", as the specific requirements are highly contextual and may differ significantly even between Scrum Teams in the same field. It does, however, mandate that definition of "Done" must be transparent for those involved, to allow everyone to have the same understanding of what "Done" entails. The definition of "Done" is used for common understanding and as a required benchmark for whether a piece of work towards an Increment is completed. Thereby, the definition of "Done" acts as a de facto minimal quality standard, as all work done by the Development Team must adhere to it.

3

see page Jfl

9 Artifact Transparency

203

The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning.

The definition of "Done

is an input into the Sprint Planning. Understanding the requirements of what it means to deliver a '’ Done'’ Product Backlog item towards a "Done” Increment provides the Development Team with guidance on how much it believes to be able to implement during the Sprint "

.

If. for example, the definition of "Done" is very tight and includes several automated testing levels, implementing a new Product Backlog item may include writing automated tests. This creates additional effort, which needs to be factored in when forecasting how many Product Backlog items can likely be implemented in a Sprint.

The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team s current definition of ’ Done ”.

The purpose of Scrum Teams is iteratively to deliver product Increments to maximize the opportunities for feedback . 4 These have to be potentially releasable to ensure a potentially useful version is always available " The iteration of Scrum is the Sprint; therefore, the purpose of a Sprint is the delivery of an Increment. According to this sentence of the Scrum Guide, this Increment has to adhere to the current definition of "Done", ensuring that the Increment adheres to the current quality standards and is "Done" in a way that all involved have the same understanding.

4 '

see pages 59 ff. see page ft}

9 Artifact Transparency

204

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.

These sentences further emphasize that a Sprint s purpose is the delivery of an Increment, specifically one with added product functionality. As this Increment has to adhere to the definition of "Done", which includes everything the Development Team deems necessary for Product Backlog items and the Increment to be releasable, the Product Owner may at their discretion decide to release it . This includes the possibility of releases before the end of a Sprint.

If the definition of ’’Done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If 'Done for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of ' Done ' appropriate for the product.

When developing products, the development organization may have its own definitions for what is acceptable to be released. The development organization is the parent organization within which the development takes place, or a subset thereof. If such definitions exist, these become the minimum definition of “Done”. The Development Team may choose to add their own requirements for "Done” on top of it, however, it may not remove any of the external requirements from their definition of "Done ". If there are no definitions from the development organization, the Development Team is responsible for creating its own definition of "Done". The Guide again gives no prescription of what it must entail and merely points out that it must be " appropriate for the product"

.

9 Artifact Transparency

205

If there are multiple Scrum Teams working on the system or product release , the Development Teams on all the Scrum Teams must mutually define the definition of " Done ".

If the work of multiple Scrum Teams affects the same ( potential) release, their definitions of "Done" cannot be contradicting each other Therefore, the respective Development Teams need to " mutually define the definition of "Done ”" , which means they have to agree on a minimum common definition of "Done" shared across all teams. This minimum definition must be followed, cannot be changed unilaterally by any team and no further rules contradicting it may be made. The individual Development Teams are, however, allowed to define stricter requirements for their own work.

.

Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. With this sentence, the Scrum Guide requires that the definition of "Done" must ensure that additions to the previous Increment to form the new Increment must be working together and that this must be thoroughly tested How this is ensured is left to the development organization or the Development Team.

.

As Scrum Teams mature, it is expected that their definitions of Done " will expand to include more stringent criteria for higher quality. The Guide suggests that the quality of the work delivered by the Scrum Teams, particularly by the Development Teams, should increase over time. Its definition of "Done reflects the quality standard of a team". Therefore, over time the definition of "Done” should become stricter and aiming at a higher quality Increment. This may include a wide variety of issues, for example, tighter

9 Artifact Transparency

206

User Experience requirements, more thorough security testing or a higher level of technical documentation.

New definitions, as used, may uncover work to be done in previously Done ’ increments. *

When adding new criteria to a definition of "Done” and applying the new complete definition of "Done”, it may be revealed that existing parts of the product do not comply with the definition of "Done". These parts, delivered in previous Increments, adhered to the definition of "Done valid at the time, but fail to comply with the newer, usually tighter, definition of "Done”.

The work revealed to be un-"Done" must then be completed to adhere to the current standard in order to have an Increment that complies with the most recent requirements.

Any one product or system should have a definition of is a standard for any work done on it.

’’Done ” that

The use of the expression "any one" rather than simply "any" implies that this sentence expresses the idea that each product or system should have its own, separate definition of “Done ’. Should a Scrum Team contribute work to another product or system than their own, the definition of that product or system would be applicable, ensuring that any work done for it fulfills the minimum standards laid out in its definition of "Done”.

10 Endnotes

207

10 Endnotes Scrum is free and offered in this Guide.

Scrum as a framework is openly available and shared in the Scrum Guide, which is freely accessible under a Creative Commons license.

Scrum's roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

The Scrum Guide defines the roles, events, artifacts and rules of Scrum. All of them are carefully attuned to maximize the possibilities of empirical process control. Creating only partial implementations leads to loss of crucial aspects in this balance and is, therefore, not Scrum. Example: A team is applying Scrum, but leaves out the Sprint Retrospectives, as they are seen as taking too much time. Through this, the team loses a key opportunity tor inspection and subsequent adaptation of its development process. It is thereby foregoing a possibility for improvements. This setup of "Scrum without a Sprint Retrospective" is not Scrum.

Scrum is conceptualized as a container, within which other techniques, methodologies , and practices may be applied as long as they don't contradict the Scrum Guide's ideas. These may

10 Endnotes

208

further improve collaboration and coordination within the teams , lead to fast feedback cycles or raise the quality and speed of product development . Example: Kanban principles can be applied within a Scrum environment. A Scrum Team may use a Kanban Board to track its Sprint Backlog , limit its work in progress ( WIP) and use cycle times to make predictions about future delivery capacity. A Development Team may employ test-driven development ( TDD), which leads to higher product quality, lower technical debt , and a higher level of transparency about the current state of the Increment.

11 Acknolwedgements

209

11 Acknolwedgements The following lines speak for themselves and need no explanation. Despite this, they are reproduced here out of respect for individuals and organizations' contributions in the creation of Scrum.

11.1 People Of the thousands of people who have contributed to Scrum, we should single out those who were instrumental at the start: Jeff Sutherland worked with Jeff McKenna and John Scumniotales, and Ken Schwaber worked with Mike Smith and Chris Martin, and all of them worked together. Many others contributed in the ensuing years and without their help Scrum would not be refined as it is today.

11.2 History Ken Schwaber and Jeff Sutherland worked on Scrum until 1995, when they co-presented Scrum at the OOPSLA This presentation essentially Conference in 1995. documented the learning that Ken and Jeff gained over the previous few years, and made public the first formal definition of Scrum.

11 Acknowledgements

210

The history of Scrum is described elsewhere. To honor the first places where it was tried and refined, we recognize Individual, Inc., Newspage, Fidelity Investments, and IDX (now GE Health).

The Scrum Guide documents Scrum as developed, evolved, and sustained for 20-plus years by Jeff Sutherland and Ken Schwaber. Other sources provide you with patterns, processes, and insights that complement the Scrum These may increase productivity, value, framework. creativity, and satisfaction with the results.

License of the Scrum Guide

211

License of the Scrum Guide © 2018 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share- Alike license of Creative Commons, accessible at http:/ /creativecommons.orq/licenses/bv-sa74.0/leqalcode and also described in summary form at http:/ /creativecommons.orq , licenses/by-sa/ 4.0/. By utilizing this Scrum Guide you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution ShareAlike license of Creative Commons. The full Scrum Guide can be found in a web version and as a PDF in English and various other languages at: https:// www.scrumauides.orQ/

Postface

212

Postface Thank you for reading this book. I hope it has granted you a deeper insight into and understanding of the Scrum framework. If you have made it this far, you will undoubtedly understand that no product is ever finished. Rather , this book is to be understood as a hopefully high- value first increment released into the market for feedback . Should you have found anything in the book difficult to understand , if you believe I have made any factual error, or if you have found spelling or grammar errors please have the courage to utilize your openness with me and do let me know. ,

For these and other feedback or questions around Scrum, feel free to reach out to me under : scrumauide@ moritz-knueooel.eu.

Bibliography

213

Bibliography ( 1J Cynthia Kurtz and David Snowden. The new dynamics at strategy . Sense-making a complex and compfccaled world. 2003. URL brooka/atot ybi 2/k.ur tz.pdf.

tn

-

[2] IntornvMonsiechnkuentrum Bund. V-Modell XT Bund - Das Referee/ mode fur Systernemwckkjngsprofekte in dec Bundesverwaltung ( German). 2009. URL htto://download .gab. bund.de/BundeaCIO/V » Modeli XT _ Bund/ > .&dt. V«?tode l » XT»Sund«2.Q» GeSdS.

*

_

>

[3] Jeffrey Viclor Sutherland and Ken Schwaber Business object design and implementation : OOPSLA 95 workshop proceedings University of Mchigan. 1995. ISBN 9783540760962 [4] Ken Schwaber Agile 9780735619937

Protect

Management with Scrum

.

(51 Scrum ( software development ) 2020

Microsoft Press. 2015

ISBN

URL

Scruafsottwaredevelocment >.

* . 2000 ISBN

(6) Roger Sermon. Modem Phdosophy: An Introduction and Survey . Penguin Grot 9780140249071.

)

.

(7J Norman Kecth. Project Retrospectrves A Handbook tor Team Renew. Dorset House Publishing Co Inc. 2001. ISBN 9780932633446. [8] Ken Schwaber and Jeffrey Vdor Sutherland Software in 30 Days : How Agie Managers Beat the Odds. Delight Ttmr Customers and Leave Competitors m the Dust Wiley. 2012. ISBN ,

9781118206669 (91 Robert K Greenleef Servant leadership. 2016. what ia»servant*leader ah ip/

-

.

[10| Ken Schwaber. Se -organizaton and our belief that we are in charge. 2012. URL //bit.ly/2CcjlL2.

*

(11J Cyril N. Parkinson Partason's law The Economist. 19 November 1955. 1955 ( 121 Cyril N. Parkinson. Parkmson's Law. or The Pursuit of Progress. Penguin Books Lid. 2002. ISBN 9780141186856 ( 13] Jeffrey Viclor Sutherland Satan: The art of doing twice the work in had the tme Random House. 2015. ISBN 9781847941107. .

[14] Manifesto for agile software development. 2001. URL ot

^

^ £ao^ « ^ ^

httpf

/

e nan

ea

3

List of Figures

214

List of Figures 1.1 Image from the cover of the November 2017 Guide. Scrum be found at to https :/ /www . scrumquides .ora/download.html . . .

4

2.1 Published under CC BY 3.0, all relevant information can be found under https://w wiki/UnZ

7

8.1 Illustration by Moritz Knuppel, published under license CCO 8.2 Published under CCO, all relevant information can be found under https://w.wiki/Unc 8.3 Published under CC BY- SA 4.0, all relevant information can be found under https //w wiki/WtC . 8.4 Published under CC BY- SA 3.0, all relevant information can be found under httpsV/w. wiki/WtH , 8.5 Published under CC BY- SA 2.5, all relevant information can be found under https:/ /w. wiki/Wsi .

180

185 185 186 192