001-2022-1129 DLMPREEPMS01 Course Book

PROCESS MANAGEMENT
WITH SCRUM
DLMPREEPMS01
PROCESS MANAGEMENT WITH
SCRUM
MASTHEAD
Publisher:
IU Internationale Hochschule GmbH
IU International University of Applied Sciences
Juri-Gagarin-Ring 152
D-99084 Erfurt
Mailing address:
Albert-Proeller-Straße 15-19
D-86675 Buchdorf
media@iu.org
www.iu.de
DLMPREEPMS01
Version No.: 001-2022-1129
Bar Schwartz
© 2022 IU Internationale Hochschule GmbH

This course book is protected by copyright. All rights reserved.
This course book may not be reproduced and/or electronically edited, duplicated, or dis-
tributed in any kind of form without written permission by the IU Internationale Hoch-
schule GmbH.
The authors/publishers have identified the authors and sources of all graphics to the best
of their abilities. However, if any erroneous information has been provided, please notify
us accordingly.
2
PROF. DR. MARGIT SARSTEDT
Since January 2021, Ms. Sarstedt has been a professor in the field of project management at
IU International University of Applied Sciences. Having been active in both the academic and
private sectors, she has gained a deep understanding of technology and project manage-
ment from theoretical and practical application. After studying physics at the Johann Wolf-
gang Goethe University in Frankfurt am Main, Germany, she completed her doctorate project
concerning the construction of ion beam equipment. She presented the results of her
research at international conferences. Later, she spent several years as a postdoctoral
researcher at universities in both the United Kingdom and the United States, where she
spearheaded the development efforts of many industrial projects designed to aid in the crea-
tion of innovative semiconductor equipment.
Ms. Sarstedt has experience teaching in Germany, the United Kingdom, and the United
States. After her time spent in academia, she worked for various international companies as a
project and program manager, department head of project management, and managing
director. Her interests in change management and project management led her to start work-
ing freelance as a change and interim manager for reorganization projects. She returned to
teaching in 2020.
3
TABLE OF CONTENTS
PROCESS MANAGEMENT WITH SCRUM
Module Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Introduction
Signposts Throughout the Course Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Basic Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Required Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Learning Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Unit 1
Scrum Origin, Basic Idea, and Fields of Application 15
Author:
1.1 The Birth of Scrum – How and Why it All Began . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2 The Agile Manifesto and a Change in Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 The Approach of Iterative and Incremental Development . . . . . . . . . . . . . . . . . . . . . . . . 23
1.4 Defining Fields for Scrum and Fields Not for Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Unit 2
Scrum Roles 33
Author:
2.1 The Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2 The Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3 The Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4 The Customer Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.5 The Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Unit 3
Product Backlog and Sprint Planning 45
Author:
3.1 Principles of a Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2 Refinement Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3 Definition of Ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4 Determining Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.5 Selecting Items and Defining the Sprint Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4
Unit 4
Executing the Scrum Process 63
Author:
4.1 The Scrum Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2 Sprint Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5 Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Unit 5
Helpful Tools 77
Author:
5.1 Requirements and User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2 Planning Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3 Communication Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.4 Tracking Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.5 Available Software Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Unit 6
Implementation and Scaling of Scrum 97
Author:
6.1 Implementation of Scrum in a Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.2 Chances, Risks, and Limitations of Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3 Scrum of Scrums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.4 The Nexus Framework for Scaling Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.5 Other Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Appendix
List of References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
List of Tables and Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5
INTRODUCTION
WELCOME
SIGNPOSTS THROUGHOUT THE COURSE BOOK
This course book contains the core content for this course. Additional learning materials
can be found on the learning platform, but this course book should form the basis for your
learning.
The content of this course book is divided into units, which are divided further into sec-
tions. Each section contains only one new key concept to allow you to quickly and effi-
ciently add new learning material to your existing knowledge.
At the end of each section of the digital course book, you will find self-check questions.
These questions are designed to help you check whether you have understood the con-
cepts in each section.
For all modules with a final exam, you must complete the knowledge tests on the learning
platform. You will pass the knowledge test for each unit when you answer at least 80% of
the questions correctly.
When you have passed the knowledge tests for all the units, the course is considered fin-
ished and you will be able to register for the final assessment. Please ensure that you com-
plete the evaluation prior to registering for the assessment.
Good luck!
8
BASIC READING
Highsmith, J. (2002). Agile software development ecosystems. Addison-Wesley Professio-
nal.
Schwaber, K. (2004). Agile project management with Scrum. Microsoft Press.
9
REQUIRED READING
UNIT 1
Rigby, D., Sutherland, J., & Takeuchi, H. (2021, August 27). The secret history of Agile inno-
vation. Harvard Business Review. Paragraphs 1–11.
http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=bsu&AN=11868
6060&site=eds-live&scope=site
UNIT 2
Aime, F., Humphrey, S., DeRue, D. S., & Paul, J. B. (2014). The riddle of Heterarchy: Power
transitions in cross-functional teams. Academy of Management Journal, 57(2), 327–
352.
http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edsjsr&AN=eds
jsr.43589261&site=eds-live&scope=sit
UNIT 3
Rubin, K. S. (2012). Essential Scrum: A practical guide to the most popular Agile process.
Chapter 6
http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=cat05114a&AN
=ihb.52492&site=eds-live&scope=site
UNIT 4
Rubin, K. S. (2012). Essential Scrum: A practical guide to the most popular Agile process.
Chapter 4
http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=cat05114a&AN
=ihb.52492&site=eds-live&scope=site
UNIT 5
Viscardi, S. (2013). The professional ScrumMaster’s handbook (pp. 141–163). Packt Publish-
ing.
http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edsbvb&AN=e
dsbvb.BV041770025&site=eds-live&scope=site
10
UNIT 6
ing.
ing.
11
FURTHER READING
UNIT 1
Hohl, P., Klünder, J., van Bennekum, A., Lockard, R., Gifford, J., Münch, J., Stupperich, M., &
Schneider, K. (2018). Back to the future: Origins and directions of the “Agile Manifesto”
– views of the originators. Journal of Software Engineering Research and Development,
6(1), 3—27.
http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edsdoj&AN=ed
sdoj.62376a63021d4054b9f838312fb1a362&site=eds-live&scope=site
UNIT 2
Spiegler, S. V., Heinecke, C., & Wagner, S. (2019). Leadership gap in Agile Teams: How
Teams and Scrum Masters mature. Lecture Notes in Business Information Processing,
37–52.
http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edsbas&AN=ed
sbas.87645E72&site=eds-live&scope=site
Sverrisdottir, H. S., Ingason, H. T., & Jonasson, H. I. (2014). The role of the Product Owner
in Scrum-comparison between theory and practices. Procedia - Social and Behavioral
Sciences, 119, 257–267.
http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edselp&AN=S1
877042814021211&site=eds-live&scope=site
UNIT 3
Everett, J. (2021, October 19). Practical Fibonacci: A beginner’s guide to relative sizing.
Scrum.Org.
Available online
Mkrtchyan, E. (2022, March 30). User stories vs. product requirements - Agile Insider.
Medium.
Available online
12
UNIT 4
Alfonso, A. (2018, July 6). The 4 Scrum ceremonies made simple: A quick guide to Scrum
meetings. Medium.
Available online
UNIT 5
Gralha, C., Pereira, R., Goulao, M., & Araujo, J. (2021). On the impact of using different tem-
plates on creating and understanding user stories. 2021 IEEE 29th international
requirements engineering conference (RE), 209–220. IEEE.
http://search.ebscohost.com.pxz.iubh.de:8080/login.aspx?direct=true&db=edseee&AN=e
dseee.9604704&site=eds-live&scope=site
Aston, B. (2022, January 2). 10 best online Scrum tools for 2021. The Digital Project Man-
ager.
Available online
UNIT 6
Scrum.org. (2021). The NexusTM guide.
Available online
Sutherland, J. (2006). The Scrum@Scale guide | Scrum@Scale framework | Dr. Jeff Suther-
land. Scrum@Scale Framework.
Available online
13
LEARNING OBJECTIVES
The Process Management with Scrum course introduces the Scrum framework as a proc-
ess management approach to support the production and delivery of products. On the
completion of this course, you will be able to understand and describe what Scrum is,
what it is not, and in what ways it should be implemented. In Unit 1, the focus is on the
Scrum origin, the core idea behind it, and the fields of application where it is relevant and
useful. Unit 2 goes deeper into the framework by describing the roles required to imple-
ment the Scrum framework, including the responsibilities and tasks associated with the
roles. Unit 3 focuses on the Scrum artifact, the Product Backlog, and how to utilize it best
throughout the planning process. Unit 4 dives into execution by elucidating the Scrum
flow, learning cycle, and the Scrum events throughout that cycle. Unit 5 provides addi-
tional support to the implementation of Scrum by offering helpful tools to track progress
and facilitate Scrum events. Lastly, Unit 6 discusses the implementation of Scrum, includ-
ing its impact on an organization and what is required to successfully scale it. Together,
those units complement each other to deepen your understanding of the Scrum frame-
work.
14
UNIT 1
SCRUM ORIGIN, BASIC IDEA, AND FIELDS OF
APPLICATION
STUDY GOALS
On completion of this unit, you will be able to ...
– explain Scrum.
– understand the idea behind Agile methods.
– discuss the core value proposition of the iterative and incremental development.
– decide when Scrum is the appropriate development approach.
1. SCRUM ORIGIN, BASIC IDEA, AND FIELDS
OF APPLICATION
Case Study
Bianca is the Chief Executive Officer of one of the business units of a large, German-based
manufacturing company. Her department consists of over 2,000 employees working
worldwide to support internal business units and external customers in process improve-
ment. Their products, solutions, and services include operational excellence consulting
and customized implementation of off-the-shelf software solutions to interpret data.
Since the COVID-19 pandemic, the demand for data-driven process optimization tools has
increased as more businesses digitalize their product offering and organizational work-
flows. However, the tools requested by customers changed due to their need to accommo-
date a combination of working from home and the office. Thus, Bianca’s existing software
solutions are no longer aligned with market needs. As a result, Bianca is considering
developing new software solutions in-house.
A team of ten engineers was carefully selected to carry out the implementation effort of
one new in-house business process management tool. However, unfamiliar with in-house
software development, Bianca decided to hire AgileABC consultancy to support the team.
Her wish was that they invest six months into training her team and building the product
simultaneously. The rest, she hoped, would happen organically.
AgileABC brings years of experience in Agile training, particularly Scrum. They have multi-
ple certifications recognized by internationally known knowledge bodies. Also, they suc-
cessfully introduced Scrum in multiple organizations of similar industries and sizes. Thus,
they felt confident suggesting a multi-phase Scrum implementation project plan aligned
with their best practices, including training and implementation phases. According to the
plan, Bianca’s wish seems reasonable and achievable.
After six months, the newly established team has not succeeded in deriving business value
from their Scrum implementation. The product is not ready and is completely unusable.
AgileABC consultants are slowly phasing out, suggesting that they provided the teams
with everything they need to succeed. At the same time, the team struggles with the new
development approach, suggesting their stakeholders are not Agile enough and are ques-
tioning whether they should revert to the way they worked before. Also, Bianca is highly
concerned about whether implementing Scrum was the right decision for this project. At
the end of this unit, you will be able to answer Bianca’s question.
16
1.1 The Birth of Scrum – How and Why it
All Began
Scrum is a development methodology embodying the iterative and incremental develop-
ment principles introduced by Walter Shewhart in 1939 (Manuele et al., 1940). This cycle is
also known as Plan-Do-Study-Act (PDSA) and Plan-Do-Check-Act (PDCA) as it refers to the
cycle of learning from an outcome or validating its correctness. In other words, the initial
purpose of the iterative and incremental development approach was to improve existing
products by generating learnings from testing small and short improvement hypotheses.
However, following World War II and the emergence of information technology (IT) in the
1990s, iterative and incremental development evolved beyond quality management and
was adapted as a new product development approach for manufacturing and software
development. Today, this approach serves as the foundation for agility (Whiteley et al., Agility
2021) and the Scrum framework. the ability of an individ-
ual, team, and organiza-
tion to detect and
Following the events of World War II, Japan pioneered workstreams that brought together respond to change by
American quality management techniques and Japanese manufacturing principles to effectively integrating
feedback into their core
improve efficiency and Japan’s international manufacturing reputation (Whiteley et al., development process
2021). For example, Toyota hired W. Edwards Deming, a mentee of Shewhart, to train their Toyota
managers on the PDSA approach. That led to the evolution of the Toyota Production Sys- The Toyota Motor Corpo-
ration is a Japanese mul-
tem. The system is now considered the origin of lean thinking and a significant factor tinational automotive
behind the success of the X-15 hypersonic jet development in the 1950s (Rigby et al., manufacturer headquar-
2021). tered in Toyota City, Aichi,
Japan (Toyota, 2022).
Hirotaka Takeuchi, a Harvard Business School professor, and Ikujiro Nonaka, a Tokyo Lean thinking
Hitotsubashi University professor, developed the principles of PDSA to support new prod- A thinking approach that
focuses on the organiza-
uct development in their publication “The New New Product Development Game” in the tion of human activities
Harvard Business Review (Takeuchi & Nonaka, 2014). Inspired by rugby, an English close- to maximize value while
contact team sport and the ability of Japanese manufacturing companies to release inno- reducing waste (“Lean
Thinking,” 2022)
vative products fast (Rigby et al., 2021), Takeuchi and Nonaka (2014) introduced six char-
acteristics to “move the Scrum downfield” when developing new products:
1. Built-in instability: the idea that innovation and creativity are fostered by top man-
agement generating pressure on a group of experts by giving them a broad strategic
direction and goals with the freedom to craft a solution independently
2. Self-organizing project teams: the idea of teams operating like a start-up company,
empowered to define their scope and make decisions independently and in collabora-
tion with their stakeholders
3. Overlapping development phases: the idea of team members with expertise in a
diverse aspect of product development working together in a rhythm instead of hand-
ing over work to one another
4. “Multilearning”: the idea that team members are expected to experiment with the
product, stakeholders, and ways of working, learning new skills, and improving their
ability to solve problems
17
5. Subtle control: the idea that control reduces creativity, so the development process
requires minimal control mechanisms to ensure “self-control,” such as selecting the
right people, encouraging close stakeholders and customers interaction, and aligning
reward systems
6. Organizational transfer of learning: the idea that sharing knowledge outside of the
project team is essential for improving the organization’s capabilities and future new
products
Together, they suggested, these characteristics affect an organization’s ability to innovate.

Alone, however, each characteristic is insufficient in improving time-to-market or agility
(Takeuchi & Nonaka, 2014).
Honoring Takeuchi and Nonaka’s approach from 1986, Jeff Sutherland, John Scumnio-
tales, and Jeff McKenna developed the Scrum process during their employment with Easel
Corporation in 1993. The combination of the time pressure to develop a critical software
product in less than six months and Sutherland’s familiarity with PDSA cycles and rapid
application development inspired him to utilize a manufacturing development approach
for software development. His success in finishing his project on time and with better
quality led to the birth of the Scrum framework (Rigby et al., 2021). Two years later, Scrum
was officially documented and shared with the public in Ken Schwaber’s paper on how to
use Scrum in product development (Schwaber, 1997).
In 1989 in the United Kindom, Central Computer and Telecommunication Agency (CCTA),
also later known as the Office of Government Commerce (OGC), introduced the first revi-
sion of PRojects IN Controlled Environments (PRINCE). PRINCE2® emerged as the first
project management method developed with IT projects considered. However, it applies
to IT and non-IT projects (Ghosh et al., 2015).
PRINCE2®, like Scrum, introduced flexible concepts and principles to improve project
management effectiveness. However, PRINCE2® suggested a linear development
approach, while Scrum suggested an incremental and iterative development approach.
Ultimately, both approaches focused on a process-based approach to managing project
complexity, milestones and stages, and communication between the business, executing
team, and stakeholders.
18
Figure 1: Linear Versus Incremental and Iterative
Source: Bar Schwartz (2022).
Software and information systems projects were a “risky undertaking” in the late 1990s
(Cule et al., 2000, p. 65). With over 50 percent of these projects running late or exceeding
budget, project failure and cancellation costs were estimated to exceed $140 billion per
year in American companies (The Standish Group, 1994). The responsibility for this failure
typically fell on the project manager. However, the reality of these projects is highly varied,
creating a unique context given the project scope, the people involved, and the relation-
ship between them far beyond the control of one individual (Cule et al., 2000). Hence, it
challenged the power dynamics and decision-making hierarchies that existed in most
organizations at the time.
Driven by his success at Easel Corporation, Jeff Sutherland partnered with Ken Schwaber
and fifteen other software developers to create the Agile Manifesto. They aimed to
“uncover better ways of developing software by doing it and helping others do it“ (Beck et
al., 2001a, para. 1). In the same year, Schwaber cooperated with Mike Beedle to publish
their book Agile Software Development with Scrum (Schwaber & Beedle, 2001). The book
established Scrum as an Agile software development approach and introduced the role of
a Scrum Master to support the adaptation of the values and principles introduced by the
Agile Manifesto.
19
Agile Project Management with Scrum (Schwaber, 2004) introduced the Scrum approach as
a framework for project implementation, including the core process, information flow,
roles, and artifacts. This approach contributed to creating the Scrum Guide in 2010
(Schwaber & Sutherland, 2020) and the emergence of Scrum knowledge bodies such as
Scrum Alliance and Scrum.org.
1.2 The Agile Manifesto and a Change in

Perspective
February 2001, in Snowbird, near Salt Lake County, USA, seventeen software developers
came together to uncover potentially better ways to develop software. Led by Kent Beck,
the group intended to create a supportive and protective environment for software devel-
opers (Hohl et al., 2018). The manifesto was meant to mitigate project risks and the impli-
cations of changing requirements that often result in unsustainable workloads on Devel-
opment Teams.
The Agile Manifesto (Beck et al., 2001a) suggests four values framed as spectrum-based
sentences where the left side is more desirable than the right side, as follows:
1. “Individuals and interactions over processes and tools

2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan” (para. 2).
The manifesto also introduced twelve principles to support the adoption of the above val-
ues. These are listed in the graphic below.
20
Figure 2: Twelve Agile Principles Behind the Agile Manifesto
Source: Bar Schwartz (2022), based on Beck et al. (2001b, para. 1–12).
Considering the vagueness of the values and principles suggested by the manifesto, multi-
ple publications attempted to elucidate its statements, such as Abrahamsson et al. (2002)
and Highsmith (2002). However, the manifesto’s creators suggested that learning it
through implementation and supporting others was the better approach.
Understanding the Agile Manifesto Perspective
In the year following its publication, many software developers saw the manifesto as the
go-to approach when developing software projects. While some software professionals
truly believed in the values shared, others considered it a “best practice” or a “marketing
gimmick” (Hohl et al., 2018, p. 2), introducing the idea of “doing Agile” versus “being Agile”
(p. 5). According to Hohl et al. (2018), organizations “doing Agile” follow the rituals without
believing the values and principles, while organizations “being Agile” believe the values
and principles in their core (p. 5). Thus, organizations “doing Agile” sabotage themselves
with opaque management and bureaucracy layers that hinder Agile initiatives due to a
lack of focus on value creation, team enablement, and end-to-end collaboration.
In the 1990s, standards for IT development suggested control mechanisms, such as clear
project scope and milestones. For example, they utilized phases in PRINCE2®. These
approaches were considered rigid, as they lacked the consideration of individuals’ unique-
21
ness (Highsmith, 2002). According to Highsmith (2002), the manifesto’s creators suggested
that processes should be tailored to people’s communication needs. Hence, the unique
combination of the people part of the project and their interaction should derive from the
process rather than following standardized approaches. This idea was considered mis-
aligned with the common perception that people should follow processes.
Standard IT project management methods include comprehensive documentation for

each implementation stage. This documentation was utilized for planning purposes,
handover, and knowledge transfer between functions throughout the development
(Ghosh et al., 2015). While documentation is not an issue in software development, the
manifesto suggested focusing on the final working software and customer collaboration
(Highsmith, 2002). Hence, aligning with the test-and-learn approach suggests customers
can provide valuable feedback when using the product rather than reading about it.
Indeed, close interaction with customers is vital.
According to Highsmith (2002), the manifesto’s creators were trying to avoid the overhead
of time and effort dealing with contracts due to the frequency of changing requirements.
Thus, limiting the contract to the project objectives while maintaining a collaboration
agreement increased both parties’ motivation to deliver the project successfully (High-
smith, 2002). Together with the last value to “respond to change” (Beck et al., 2001a, para.
2), the team can continue testing their approach with the customer and improve their
development according to their learnings instead of rigidly following an outdated plan
promised by a contract.
The change in perspective
The Agile manifesto gained popularity in the software community, however, not without
criticism. Its vagueness and ambiguity led to misinterpretations influencing the imple-
mentation of Agile methods in organizations. For example, the initial motivation was to
improve software developers’ working conditions and provide them with more safety
(Hohl et al., 2018). However, focusing on short iterations can also put high pressure on
programmers, mainly when business people and customers are too far from the team to
collaborate effectively.
Another criticism was raised due to the unique setup Agile methods required, such as
close cooperation with clients and their agreement to accept minimal contracts. Shifting
the decision authority to the developers and customer representatives also required trust,
authority, and sufficient information to make these decisions (Hohl et al., 2018). Not every
organization could accommodate this due to politics, existing organizational systems and
hierarchies, and market requirements (e.g., the regulatory documentation requirements
in healthcare or the strict contracts in logistics).
Highsmith (2002) suggested that organizations ask themselves where they want to be on
the spectrum. For example, can the project succeed without documentation? or without
working software? Where is the right balance? Abrahamsson et al. (2002) also cited McCau-
ley (2001) and Glass (2001), suggesting that there is no one size fits all, and most experts
agree with that. Ultimately, where an organization is on the spectrum matters less than
the perspective of the people. Hence, the belief is that
22
• people matter,
• only minimal documentation is required,
• communication is crucial, and
• modeling tools and deep analysis of scope and design up-front are optional.
Ideally, agility is achieved by developing software in short, rapid cycles, collaboratively

within the team and with the stakeholders and customers, and by learning and evolving.
Considering that the standard approach for projects was plan-driven and controlled, a
process-oriented method was considered novel (Abrahamsson et al., 2002).
1.3 The Approach of Iterative and

Incremental Development
The iterative and incremental development approach in Scrum is based on the belief that
software development projects require a more “lightweight” development approach
(Ghosh et al., 2015, p. 28). According to Ghosh et al. (2015), a project is a temporary, time-
restricted activity to deliver a predefined result. Hence, facilitating a plan-driven process
that results in that predefined objective is necessary. Thus, project management is the dis-
cipline that enables the timely delivery of the project objective within the constraints of
people and budget (Ghosh et al., 2015).
Based on Dr. Martin Barnes’s project management objectives from the mid-1980s, a com-
mon approach toward projects was to predict and fix the scope, effort, and timeline (Lock,
2019). Therefore, a project can be managed and controlled linearly or sequentially to
deliver the specific predefined goal. However, this is not always the case in software and
new product development, where scope, effort, and timeline can frequently change (Cule
et al., 2000).
23
Figure 3: Project-Driven Versus Process-Driven
Iterative and incremental development aims to reduce the risk of delivering an outdated
scope as the project timeline evolves. It is driven by the assumption that plans can
change. Therefore, the best way to ensure we adapt to the change is by working in smaller
increments that allow frequent checking that all particpants are aligned (Team Inovector,
2022).
Scrum was initially inspired by Shewhart’s (Manuele et al., 1940) PDSA cycle, as well as
Takeuchi and Nonaka’s (2014) approach to product development and iterative and incre-
mental software development approaches, such as object-oriented and rapid program-
ming. Hence, Scrum is a process-driven approach rather than a plan-driven one.
As described by the Scrum Guide (Schwaber & Sutherland, 2020), Scrum includes a core
development process consisting of five meetings known as ceremonies. The scope of work
is sliced incrementally to fit time-bound iterations called Sprints. Typical Sprint duration is
one to four weeks, with a preference for shorter cycle time and maintaining a regular
cadence once the duration is selected.
Each Sprint starts with a Sprint Planning ceremony purposed to generate understanding
and commit to the work. During the Sprint, the Development Team comes together in a
Daily Standup ceremony during the Sprint to discuss their progress and raise impedi-
ments. At the end of the Sprint, the team demos the completed work to a preselected
group of stakeholders, customers, and users in a Sprint Review ceremony. That ceremo-
ny’s purpose is to generate feedback that supports the team in improving their future
work. This feedback is captured and reflected upon in a team-internal ceremony called the
Sprint Retrospective. Ultimately, this reflection generates learnings and actions that
directly influence the following Sprint Planning. To fully capture feedback, the team also
24
invests time in a Sprint Refinement ceremony where they explore upcoming work and dis-
cuss the implementation effort considering previous feedback. The Scrum Process is
depicted below.
Figure 4: The Scrum Process
According to Schwaber and Sutherland (2020), three roles are introduced as part of the
framework to support the adaptation of the Scrum approach: Development Team, Prod-
uct Owner, and Scrum Master.
1. The Development Team’s responsibility is to implement the work increment. Thus, it

often consists of up to nine experts with the knowledge and skills needed to develop
the product or solution they are tasked with.
2. The Product Owner’s role is to maximize customer value by facilitating the communi-
cation between the Development Team and various stakeholders, including custom-
ers and users. The Product Owner clarified the product objectives and goals. Thus,
Product Owners are typically business experts.
3. The Scrum Master’s role is to support the Development Team and Product Owner in
adopting the Scrum development process. Scrum Masters ensure that Scrum ceremo-
nies run successfully. Also, they support the team in identifying challenges and
impediments interfering with their ability to follow the process and complete their
committed work (Schwaber & Sutherland, 2020).
Together, these three roles enable a group of experts to come together as a team (the
Scrum team) and independently develop a product or solution increments for their target
customers. Hence, Plan the work, Do the work, Study from the outcome, and Act accord-
ing to their learnings (PDSA).
According to Ozkan and Kucuk (2016), there is no project, program, or portfolio manager
role in the Scrum framework. Scrum relies solely on the Development Team, Product
Owner, and Scrum Master to facilitate the Scrum process rather than the classical com-
25
mand-and-control approach associated with project management. However, in certain cir-
cumstances, Ozkan and Kucuk suggested that each Scrum Sprint could be considered a
project as those have a plan-driven, time-bounded setting.
1.4 Defining Fields for Scrum and Fields

Not for Scrum
Scrum has been discussed throughout this unit as an alternative development process
approach, where the plan-driven implementation approaches potentially fail due to the
high risk of changing requirements. While iterative and incremental development allows
us to reduce risk by learning and adapting as the project evolves, Scrum is not a one-size-
fits-all. Where does it fit?
What Problems Does Agility Solve Best?
With the emergence of IT, digital solutions, and the ability of people to relocate and work
from home, complexity and uncertainty has increased for organizations. According to Gor-
zeń-Mitka and Okręglicka (2014), organizations transitioned to “knowledge-producing”
work, increasing the need for creativity and the ability to learn (p. 403).
This shift also influences leadership and decision-making in organizations. Gorzeń-Mitka

and Okręglicka (2014) draw upon the complexity leadership theory developed by Uhl-Bien
et al. (2007). According to Uhl-Bien et al. (2007), the leadership approach influences organ-
izational outcomes and the ability to learn, innovate, and adapt. Therefore, it is suggested
that leaders evaluate the complexity level they operate in.
26
Figure 5: The Cynefin Model
Source: Bar Schwartz (2022), based on Snowden & Boone (2007).
Gorzeń-Mitka and Okręglicka (2014) suggest that complexity should be determined early
by utilizing questions about the area of work. For example, it could be useful to deal with
questions, such as
• Who is it for?
• What problem are we solving?
• What do we know about the solution?
• What do we know about developing such a solution?
• What skills and capabilities do we have in developing such a solution?
This process is also known as sense-making to determine the management and decision-
making approach suited for a particular development initiative. According to Gorzeń-
Mitka and Okręglicka (2014), a system is complex when
• it consists of multiple parts that interact dynamically with each other.

• interaction is random or simultaneous.
• short feedback loops are required to align short- and long-term objectives.
• patterns of interaction might result in history not being a predictor of the emerging out-
come.
In other words, complexity emerges from the vagueness of the work and the variability of
possible solutions. There is no clear solution to plan or judge the time and effort it would
take to develop it.
Cynefin (Welsh for “habitat” or “familiar”) is a sense-making framework to support people

in understanding the complexity of situations. Originating in knowledge management, the
Cynefin framework was initially purposed for analyzing culture and generating an under-
27
standing of communities. For example, understanding what type of communities require
straightforward training programs or more fluid learning structures (Snowden, 2000).
However, according to Snowden and Boone (2007), the approach is suitable for leaders
seeking to make appropriate decisions.
The Cynefin framework consists of the four quadrants with additional zones between
them:
1. Simple suggests that an obvious relationship exists between the cause and effect
(Snowden & Boone, 2007). Best practices, such as rules, policies, regulations, and pro-
cedures one can follow to solve problems within that space, are also obvious (Snow-
den, 2000). For example, cooking a meal according to a recipe guarantees the meal
tastes the same every time.
2. Complicated suggests that a relationship exists between cause and effect. However,
this relationship is not obvious (Snowden & Boone, 2007). Thus, expertise is required
to uncover the relationship and to judge which practices are appropriate for the chal-
lenge (Snowden, 2000). For example, there are multiple approaches to building a
bridge. An expert should select the most appropriate approach to building bridges
considering the location, available materials, timeline, and other known factors. Typi-
cally, the risks in building a bridge are due to external factors, such as weather and
suppliers. The bridge itself is predefined.
3. Complex suggests that the relationship between cause and effect can only be uncov-
ered retrospectively. Hence, there are multiple solutions to the problem depending on
the context. However, which solution is the right one is unpredictable (Snowden &
Boone, 2007). For example, process management tools are highly dependent on the
approach organizations choose to manage their processes. While some organizations
follow standards and best practices, no one process management tool can fit all
organizations. Hence, following expert judgment might increase the solution fit for
some customers but would not guarantee it.
4. Chaotic suggests that there is no relationship between cause and effect. Hence, the
solution is novel, and no practices can support predicting or guaranteeing the success
of the development. At the same time, a rapid response is required (Snowden &
Boone, 2007). For example, when a house is on fire, someone must assume leadership
and set the direction to move people out of the house. Then, when the situation is
safe, they can shift to one of the other domains, such as the complexity of finding a
new place to stay or avoiding future house fires.
5. Disorder represents the unknown zone in between the quadrants. Thus, it is placed in
the middle of the framework. When the situation is hard to make sense of, bringing
more perspectives to argue with one another can support sorting each element into
the right category (Snowden & Boone, 2007).
As a sense-making framework, Cynefin suggests that there is no correct answer. According

to Snowden and Boone (2007), leaders might also mistake the situation to be simple when
it is complicated or complicated when it is complex; “common sense” might differ
between people in the organization. According to Gorzeń-Mitka and Okreglicka (2014),
common sense in organizations derives from people, standard working practices, and
technology. As a result, the dynamic between these might require a different development
approach (Snowden & Boone, 2007).
28
Table 1: Approaches to Each Cynefin Domain
Problem-solving Development Leadership approach

approach approach How a leader should
How to find the solu- How the process behave
tion should look
Simple Best practices Sense-Categorize- Command-and-Con-

An obvious relation- Roles, recipe, standard Respond trol
ship exists between procedures Capture tasks, catego- Directive of the solu-
the cause and effect rize to a solution, and tion
act accordingly
Complicated Good practices Sense-Analyze- Democratic

A discoverable rela- Expert opinion Respond Cooperate with experts
tionship exists Capture tasks, analyze
between cause and with an expert, and act
effect accordingly
Complex Emerging practices Probe-Sense- Visionary

The relationship Learning from out- Respond Provide context and
between cause and comes Test a hypothesis, cat- trust others
effect can only be egorize task, and act
uncovered retrospec- accordingly
tively
Chaotic Novel practices Act-Sense-Respond Crisis management

No relationship exists Gut feeling Act first, categorize the Decisive and fast to act
between cause and task, and act again
effect accordingly
Disorder Unable to judge Unable to judge Unable to judge

Unable to judge
Source: Bar Schwartz (2022), based on Snowden & Boone (2007).
Agility and Scrum are designed to solve problems associated with significant risk due to
scope changes during the project, evolving technology, and increasing delivery urgency
from shifts in timelines and expectations (Highsmith, 2002). Hence, there is a suitable sol-
ution or solutions. However, this can only be discovered by experimenting with a cus-
tomer and learning from their feedback.
Considering the Cynefin model, Agile and Scrum are aligned with the Probe-Sense-
Respond approach suggested under the complex domain. A more linear approach is suffi-
cient in the simple and complicated quadrants, considering the solution is apparent or
can be clarified to details utilizing experts’ opinions. Thus, Agile and Scrum might become
an overhead. Lastly, in the chaotic quadrant, a singular decision authority is required to
speed-up decision-making. Hence, Scrum might be considered too slow, as there is no
sufficient information to determine a scope for a one-Sprint increment; other approaches
might be more suitable.
29
What Organizational Setup Fits Scrum Best?
When Takeuchi and Nonaka published their six characteristics for new product develop-
ment in 1986, they focused on the organizational ability to isolate one project team, pro-
vide them with context, and operate with minimal authority. Inspired by similar principles,
Scrum initially focused on singular, isolated projects where one team could own the entire
development. Ideally, the core process, ceremonies, roles, and artifacts should cover the
entire lifecycle, including continuous scoping and prioritization done by the team itself.
However, in a project context with multiple teams, multiple complications can harden the
Scrum implementation (Ozkan & Kucuk, 2016).
Another important aspect of Scrum rooted in Takeuchi’s and Nonaka’s (2014) approach is
the focus on people as the primary asset. Their approach to minimizing authority sugges-
ted that choosing the right people is crucial to ensure project teams can be self-organized
(Takeuchi & Nonaka, 2014). According to Dupret and Pultz (2022), for people to matter,
organizations should commit to shifting their culture to foster inclusiveness and belonging
instead of high performance. Also, people should develop the security to speak honestly
and share ideas with others, which requires breaking typical power structures in organiza-
tions.
Furthermore, Sithambaram et al.’s (2021) review of governance and management factors

in Agile projects suggests that process and people-related factors are the most important
to the success of these projects. For example, the ability to collaborate with customers
directly, the flexibility in project requirements, the competence and skill set of the team,
teamwork, and communication are important success factors. Also, these factors scored
higher than organizational and technical-related factors, such as existing organizational
politics, structure and size, or knowledge of tools. In other words, enabling the organiza-
tion to embrace the Agile process on a behavioral and mindset level highlights the impor-
tance of people and process over the scope of the work itself. The same can be applied to
Scrum.
SUMMARY
During the 1990s, software projects were associated with a high risk of
failure due to the likelihood of changing requirements. With a failure
rate of over 50 percent, software developers were inspired by manufac-
turing companies delivering innovative products to the market faster
than their competition.
Scrum is a process-based, incremental, and iterative development

approach that gained popularity during the early 2000s. Inspired by
PDSA cycles and rapid development concepts, Scrum fosters the devel-
opment of a working product incrementally by splitting the develop-
ment work into smaller slices of testable outcomes. Each delivered work
is tested with a customer to generate feedback that influences future
work. This approach was associated with reducing project risks and bet-
ter adapting to changing requirements.
30
Implementing Scrum requires more than following rules and ceremo-
nies. In 2001, Scrum became associated with the Agile Manifesto’s values
and principles of supporting an organization to develop better software.
The vagueness of the manifesto brought diverse perspectives and inter-
pretations to how Scrum is implemented in organizations. As a result,
Agile practitioners differentiate between “doing Agile” and “being Agile,”
referring to organizations which either implement Agile without believ-
ing the values and principles versus those who do.
When considering Scrum for a project, determine its complexity first.

The Cynefin model suggests that probe-based approaches best fit the
complex domain where predicting project scope, timeline, and expertise
is impossible. Lastly, Scrum best fits smaller projects where one team
owns the entire development. An organization is recommended to
embrace a collaborative culture that focuses on people rather than goals
to support Scrum adoption. At the same time, many organizations are in
a similar situation to Bianca’s company (see case study). Ultimately,
Scrum could fit Bianca’s project as their struggles seem to manifest in
people’s working habits, suggesting Scrum requires a long-term culture
change parallel to the framework implementation.
31
UNIT 2
SCRUM ROLES
STUDY GOALS
– explain which roles are in the Scrum framework.

– understand the purpose of each role.
– discuss how to involve customers effectively.
– understand the Scrum ecosystem.
2. SCRUM ROLES
Case Study
PharmaABC is a pharmaceutical company based in Germany and operating worldwide.
Since its establishment, PharmaABC has released hundreds of pharmaceutical solutions
to the market, improving the health of millions. A typical development time of a new med-
ication is ten years. Therefore, PharmaABC is continuously trying to find new ways to
reduce development costs. They invested heavily in technology solutions in recent years,
supporting their scientists to work together rather than alone. The technology team at
PharmaABC heard that Scrum is a great way to develop more innovative solutions, and
they created a new department called PharmaScrum to test the approach.
PharmaScrum consisted of five independent teams. Each one worked on a different solu-
tion with no dependencies on each other or the organization. They planned and reviewed
the work as a team. Without consulting the business, each team determined the problem
they cared about and wanted to solve. Each team also implemented their cadence
between one and four weeks, working on their solution. PharmaScrum executives were
delighted with the solutions that emerged.
After a few months of operation, the teams were invited to present their solutions to the
entire company. During the event, business stakeholders from PharmaABC criticized the
work done by PharmaScrum, and questioned its value. The developers were not used to
criticism as they had never demonstrated their product outside of PharmaScrum.
Puzzled by the feedback, PharmaScrum executives reached out to a consultancy special-

ized in Scrum. They learned that they were missing essential roles in their implementa-
tion: the Product Owner and Scrum Master. At the end of this unit, you will learn what
makes these roles essential and how they can reduce the risk of investing months in build-
ing the wrong products.
2.1 The Development Team

“Build projects around motivated individuals. Give them the environment and support
they need and trust them to get the job done” is one of the twelve principles in the Agile
Manifesto (Beck et al., 2001b, para. 5). It represents the core idea that creative work is fos-
tered by operating “like a start-up company,” empowering people of multiple functions to
work together independently and autonomously with their stakeholders to deliver an
emerging product they feel responsible for (Takeuchi & Nonaka, 2014, para. 16).
According to the Scrum Guide, the Scrum team is the “fundamental unit” of Scrum
(Schwaber & Sutherland, 2020, p. 5). It involves enough people to deliver a meaningful
product increment while not exceeding eleven team members ensures effective communi-
cation within the Scrum team. Furthermore, everyone is considered equal within the
34
Scrum team. In other words, all members are responsible for the product and the delivery
rather than their individual contributions. Hence, Scrum teams are considered cross-func-
tional and self-organized units, with all the capabilities needed to build the product incre-
ment without requiring the management to tell them how.
The Scrum framework introduces three core roles to support a Scrum team to operate
according to this approach: the Development Team, Product Owner, and Scrum Master.
While each role has a clear purpose, each organization interprets, modifies, and imple-
ments these roles differently, considering the organizational context, current operating
model and structure, and the scaling needs (Hron & Obwegeser, 2022). Nevertheless, rec-
ognized knowledge organizations such as Scrum.org and Scrum Alliance use the Scrum
Guide as their training baseline (Scrum.org, n.d.-e; Scrum Alliance, n.d.). However, despite
both organizations being founded by Ken Schwaber, Schwaber is no longer part of Scrum
Alliance as of January 2007 (Mayer, 2009). Therefore, this unit refers to the Scrum Guide
and Scrum.org as the standards for the Scrum framework.
The Scrum Team
The word “Scrum” was mentioned first in the context of implementing Rugby-inspired
principles into new manufacturing product development approaches (Takeuchi & Nonaka,
2014, para. 12). Scrum, as a framework, is most associated with software development
due to Sutherland and Schwaberʼs contribution in the 1990s (Schwaber, 1997). This asso-
ciation led to the Scrum team being first and foremost a product Development Team con-
sisting of up to nine developers, a Product Owner, and a Scrum Master. Together, the
Scrum team owns all aspects of delivering a product increment in each Sprint (Schwaber Product increment
& Sutherland, 2020). It includes ensuring each increment is valuable, usable, and testable This refers to a slice of a
product. In Scrum, prod-
to derive sufficient feedback from their customers to learn and adapt. ucts are delivered in small
batches. Each batch can
According to Schwaber and Sutherland (2020), Scrum teams consist of all members nee- be delivered to a cus-
tomer to gather feedback.
ded to deliver a product. Therefore, developers in each Scrum team are expected to vary
in skills and expertise in alignment with the task at hand. This expertise and skills enable Sprint
This refers to a four-week
them to timebox. In Scrum,
projects are split into
• plan what is possible realistically for them to deliver in each Sprint. multiple time-bounded
delivery cycles called
• make tradeoffs and adapt their plans for the Sprint. Sprints.
• support each other, also in domains in which they are not experts.
• ensure quality standards are met.
Ultimately, commitment and accountability are vital for such an implementation

(Schwaber & Sutherland, 2020). Each role in the Scrum team is responsible and accounta-
ble for different things. In this section, we focus on the developers – also known as the
Development Team.
The Development Team as a Cross-Functional Team
Cross-functional independent units emerged from the idea that decision-making and
implementation are more efficient when all individuals required to deliver the product can
operate without delays. It is based on lean thinking principles suggesting 80 percent of
35
Lean thinking process delays emerge from common “time traps,” such as having to wait for a formal sig-
A thinking approach nature, a personʼs response, and availability. It is translated into underutilized talent in
focusing on the organiza-
tion of human activities large quantities (Arunagiri & Gnanavel Babu, 2013, p. 1). Hence, cross-functional teams
to maximize value while bring people together to reduce the inefficiency of not working together.
reducing waste (“Lean
Thinking,” 2022)
According to Randel and Jaussi (2003), cross-functional teams bring together individuals
of diverse backgrounds. However, their performance is suggested to be low due to team
members potentially not giving their best effort in the attempt to maintain their individu-
ality. Alternatively, Aime et al. (2014) suggest that it is a power struggle. Power in the tradi-
tional functional hierarchy is formalized, while group power is emergent, opening the pos-
sibility for each team member to take charge according to the situation. However, this is
not always perceived as legitimate by the team and previous Product Owners. As a result,
it can hinder collaboration.
Another aspect of a structural change is the impact of location. Scrum fosters close daily
collaboration within a team. Hence, team members are recommended to be colocated.
When teams are not colocated, difficulties and delays due to time zone, language, and cul-
ture can occur. However, with the evolution of digital spaces, many organizations find it
challenging to employ all their talents in the exact location. Outsourcing solutions, free-
lancing, and working from home has also led to more organizations having distributed
teams (Hron & Obwegeser, 2022).
The Development Team as a Self-Organizing Team
Self-organization is the idea that when people are motivated and share common purposes
and objectives, they can organize themselves to achieve them with no oversight required
from their management. However, selecting the right people is vital (Takeuchi & Nonaka,
2014). In Scrum, the Development Team is expected to be self-organized and operate with
no internal hierarchy to allow all individuals in the team to focus on the product and
Sprint goals (Schwaber & Sutherland, 2020).
According to Moe et al. (2010), it is unrealistic to cluster a group of individuals together

under the expectation that they would emerge automatically as self-organized teams. This
transition requires developers and managers to build trust and new ways of thinking to
reorient them toward teamwork rather than operating as individuals. Often, new-to-
Scrum Development Teams feel ownership for their individual work rather than their col-
lective outcome.
Another aspect of self-organization is the ability of management to let go of their need to

control the development process. This could look like supporting the team in developing
the capabilities to monitor their work instead of overseeing it or allowing the team to
develop their plan rather than telling them what to do. When management takes a com-
mand-and-control approach, people tend to stick to their individual autonomy and focus
on their work. This can lead to a division of work that hinders the development of shared
accountability and reduce communication within the team (Moe et al., 2010). Lastly, it
reduces team willingness to follow the Scrum process, commit to a shared goal, and feel
responsible for the collective product delivery.
36
The Development Team as a Quality Advocate
When motivated individuals emerge as a team of cross-functional experts working

together to self-organize themselves to achieve a common goal, they are also expected to
become responsible for their delivery by owning their product quality . The Development
Team delivers a product increment in each Sprint and a customer should be able to use it.
Therefore, it must meet all quality standards in alignment with the customer’s expecta-
tions (Schwaber & Sutherland, 2020).
The Scrum Guide remains vague about what the requirement looks like in practice
(Schwaber & Sutherland, 2020). However, considering Scrum emerged as a framework for
delivering complex projects within a short timeframe, a high skill-level and senior level of
experience is required to allow such a team to operate unsupervised (Wysocki, 2019).
Hence, motivated senior experts are expected to be familiar with diverse development
and testing approaches to ensure the appropriate scoping for each Sprint, accommodat-
ing research, implementation, testing, and any other required activity to ensure delivery
quality.
2.2 The Product Owner

According to Unger‐Windeler et al. (2020), software companies have struggled for years to
satisfy the expectations to deliver high-quality products quickly to the market, especially
when hardware and software are combined.
The Product Owner role in Scrum originated from the agile incremental and iterative
method called eXtreme Programming (XP). In XP, the Product Owner is called an on-site eXtreme Programming
customer. They are someone with high business domain expertise and knowledge. Thus, software development
methodology advocating
they can make sense of business requirements, prioritize them, and judge their value for short release cycles
(Unger‐Windeler et al., 2020). In other words, the Product Owner supports the team in and frequent customer
determining the scope of the work and assessing its value. interactions (“Extreme
programming,” 2022)
In the Scrum Guide (Schwaber & Sutherland, 2020), the Product Owner is described as
“maximizing the value” (p. 5). What it means and how it is done varies considering the
organizational context, customer, Development Team, and the individual fulfilling the role.
Nevertheless, the Product Owner is typically responsible for the effective management of
the worklist, called the Product Backlog. Hence, the Product Owner
• develops and writes the objectives for the product, also known as Product Goal.
• develops and writes the business requirements to satisfy the Product Goal, also known
as Product Backlog items.
• explains and clarifies the purpose and value of each item according to their market
experience and familiarity with the customer.
• prioritizes what is important and what is less important.
• supports rescoping in case tradeoffs are needed to enable faster delivery.
37
Regardless of whether the Product Owner accomplishes the Product Backlog on their own
or delegates it to others, they remain accountable for the above activities (Schwaber &
Sutherland, 2020). For example, in organizations where multiple teams work together on
the same product, multiple owners might be required. However, the Scrum Guide
(Schwaber & Sutherland, 2020) specifies that “the Product Owner is one person, not a
committee” (p. 6). Hence, Product Owner teams typically nominate one person to be the
final decision-maker.
Considering the variability in the implementation of the Product Owner role, Unger‐Wind-
eler et al. (2020) suggest that the theory and practice differ as “no Product Owner role is
like another” (p. 13). Thus, the focus of this unit is on the two most critical roles the Prod-
uct Owner should have to ensure a successful Scrum implementation: communicator and
customer relationship manager.
The Product Owner as a Communicator
With over 65 percent of their time invested in formal and informal meetings, the Product
Owner is frequently identified as a communicator (Unger‐Windeler et al., 2020). In a
framework fostering self-organization and flat hierarchy such as Scrum, communication is
an essential activity for all individuals. However, this is the most important one for Prod-
uct Owners, considering they are expected to deliver a valuable product increment to a
customer without having authority on the team (Sverrisdottir et al., 2014). Hence, the abil-
ities to negotiate and influence others are preconditions to taking such a role.
Product Owners communicate in a variety of formal and informal ways. Formal ways
include their participation in Scrum ceremonies, such as Sprint Planning and Sprint
Review, and business meetings, such as quarterly reviews. Informal ways include on-
demand and recurring meetings with stakeholders, customers, and users (Unger‐Windeler
et al., 2020).
Sprint Planning
Sprint Planning’s purpose is to clarify and align the scope of the work of one Sprint
(Schwaber & Sutherland, 2020). Ultimately, the Product Owner is expected to continu-
ously maintain their market knowledge and familiarity with the needs of the product
stakeholders, customers, and users (Unger‐Windeler et al., 2020). According to Schwaber
and Sutherland (2020), Sprint Planning covers three main topics including what makes the
Sprint important to their stakeholders, what can be done, and how the work will get done.
The Product Ownerʼs role is to clarify the importance and propose a valuable Sprint goal.
Then, the Development Team decides what they can work on during the Sprint to meet
this goal. If needed, they also clarify it with the Product Owner.
Sprint Review
The Sprint Review’s purpose is to demonstrate the product increment developed by the
Development Team throughout the Sprint to a set of preselected stakeholders and cus-
tomers (Schwaber & Sutherland, 2020). It allows the Product Owner and the Development
Team to focus on gathering feedback from the stakeholders during the Sprint Review
38
(Unger‐Windeler et al., 2020). Also, this meeting is typically the platform to collaborate
with the stakeholders on the product’s status, including updating the next objectives and
expectations and highlighting the progress toward the product objectives (Schwaber &
Sutherland, 2020).
Formal business meetings
Product Owners attend diverse formal business meetings to gather information about the
current business context and align themselves with the organizationʼs work (Unger‐Wind-
eler et al., 2020). According to Unger‐Windeler et al. (2020), these meetings could be Prod-
uct Owner-specific meetings such as “Quarterly Prodc Owner Meetings” or company-wide
meetings such as “All-Hands Meetings” (p. 15).
Informal meetings
Product Owners are frequently pulled into ad hoc meetings to clarify information about
the product. These meetings can include “interruptions,” such as clarifying questions
about the product (Unger‐Windeler et al., 2020).
The Product Owner as a Customer Relationship Manager
For Scrum to accommodate changing requirements, a feedback loop should occur. Hence,
every product increment is tested with a customer, and their feedback informs future
development. This requires a solid and close relationship with a customer. Nevertheless,
the Scrum Guide does not refer to relationship management directly. According to
Schwaber and Sutherland (2020), the Product Owner is responsible for the Product Back-
log, a list of items representing the product needs in alignment with what is considered
valuable to the customer and other stakeholders. Thus, how Product Owners manage
their backlog might differ in practice.
According to Unger‐Windeler et al. (2020), relationship management is a crucial success

factor in Scrum. Moreover, the better the involvement and collaboration are with the cus-
tomer, the better the Scrum team can gather, clarify, and prioritize requirements. Ulti-
mately, planning is an organizational-wide effort with everyone across all roles, expertise,
and functions feeling comfortable sharing their perspective to support the Scrum team in
delivering the product (Kantola et al., 2022). However, fostering strong relationships with
customers is still associated with the Product Owner role. Thus, Kantola et al. (2022) sug-
gested that organizations “mind the Product Owner,” ensuring Product Owners have an
“active, collective, and structured channel for continuous improvement” (p. 1).
The Product Owner is expected to actively take responsibility for understanding the cus-
tomer, a task that was also previously associated with the role of user experience profes-
sionals (Hron & Obwegeser, 2022). Considering the organizational context, close collabora-
tion with customers is not always possible considering typical contracts, customer size
and location, and possible bias due to negative prior experience (Lohan et al., 2011). When
customer relationship management is officially part of the Product Ownerʼs role, some
companies might incentivize and support the Product Owner to find a way to foster that
relationship – a vital foundation for customer satisfaction.
39
2.3 The Scrum Master
Considering Scrum teams are expected to self-organize, the idea of the Scrum Master role
evolved later to accommodate the transition of teams to Scrum. Moe et al. (2010) sugges-
ted that clustering people together and labeling them is insufficient to develop their self-
organization capabilities. They require help and support.
With the rise of Agile and Scrum bodies of knowledge and certifications, the role of the
Scrum Master is implemented differently according to the knowledge body’s ideology
(Hohl et al., 2018). According to the Scrum Guide, their primary role is“establishing Scrum
as defined in the Scrum Guide” (Schwaber & Sutherland, 2020, p. 6). Thus, the Scrum
Guide should remain the foundation as new trends arise.
The Scrum Master is considered a “servant leader” (Schwaber & Sutherland, 2020). As
such, it is a supporting role that is suggested to have no direct responsibility to deliver the
product. However, the existence of the Scrum Master role is important to support the team
in feeling equipped to adopt Scrum (Holtzhausen & de Klerk, 2018). Also, Scrum Masters
are accountable for various tasks intended to support the Development Team, Product
Owner, and the entire organization to implement Scrum (Schwaber & Sutherland, 2020).
According to the Scrum Guide, the Scrum Master serves their team(s) by
• supporting them to develop self-organization capabilities.

• encouraging them to focus on value creation.
• supporting them in improving their delivery quality and ways of working.
• addressing external impediments and facilitating the process of solving them.
• facilitating Scrum ceremonies to ensure a positive experience, productivity, and out-
come delivery (Schwaber & Sutherland, 2020).
The Scrum Master also serves the Product Owner by
• teaching and practical mentoring approaches for defining product goals and backlog
items.
• closing the communication gap, ensuring business requirements are clear from busi-
ness and technical points of view.
• supporting them to understand the product and environment complexity to derive bet-
ter delivery plans.
• supporting them in facilitating stakeholders’ conversations and developing strong cus-
tomer relationships and collaboration (Schwaber & Sutherland, 2020).
Lastly, the Scrum Master also serves the entire organization by
• continuously leading, training, and coaching its Scrum adoption.

• consulting implementation of new Scrum team(s).
40
• supporting the development of awareness and understanding of complex work.
• closing communication gaps and removing silos to enable organizational-wide collabo-
ration (Schwaber & Sutherland, 2020).
Considering the variability in the implementation of the Scrum Master role, the focus of
this section is on the two most critical roles the Scrum Master should have to ensure a suc-
cessful Scrum implementation: change agent and accountability partner.
The Scrum Master as a Change Agent
Considering most Scrum teams start as a group of experts clustered together to deliver a
project or product, most Scrum teams do not start as self-organizing teams with strong
collaboration and communication capabilities. Thus, the Scrum Master role typically acts
as the change agent (Spiegler et al., 2019). According to Spiegler et al. (2019), the Scrum
Master takes upon the following roles to change the status quo:
• method champion. They continuously encourage people to utilize Scrum methods by

organizing meetings and demonstrating how to utilize these methods for planning, vis-
ualizing information, learning, and adapting.
• disciplinarian. They continuously point out and mirror the team when they do not fol-
low the values and principles and address resistance to following the framework.
• role model. They continuously demonstrate the desired behavior and supporting oth-
ers to change their habits within their context.
• helicopter. They maintain an oversight of the entire organization, its competencies, and
capabilities to adopt the framework, including understanding the organizational system
and structure and how it influences the team.
• knowledge enabler. They continuously encourage the team to share knowledge and
evolve their learnings by recommending conferences, promoting feedback cycles, learn-
ing from mistakes, and learning by doing.
Ideally, on a new team, the Scrum Master would have to actively demonstrate the role to
the team while the team members observe and learn what those roles entail. However, as
the team matures, team members should step up to take on these roles to mature as a
team and become self-organized (Spiegler et al., 2019). Then, the Scrum Master can take
on additional tasks or teams.
Scrum Master as an Accountability Partner
Scrum Masters are accountability partners as their service leadership evolves around the
enablement of others to go through the change. Scrum Masters who maintain a com-
mand-and-control approach, as sometimes happens when new in this role, typically hin-
der the team from evolving (Spiegler et al., 2019). Furthermore, teams in a traditional
industrial environment resist taking up the activities performed by the Scrum Master,
which hinders their ability to become fully self-organized (Spiegler et al., 2020). Thus, the
role of an accountability partner is vital for the successful implementation of Scrum.
41
Within the Scrum team, the Scrum Master is responsible to support their Development
Team toward self-management and cross-functionality (Schwaber & Sutherland, 2020).
Therefore, they are accountable for the team’s ability to work this way. Also, they support
the Product Owner and Development Team in evaluating the value and focus on deliver-
ing it according to customer standards. Moreover, Scrum Masters are expected to support
the removal of issues hindering delivery (Schwaber & Sutherland, 2020). Therefore, it is
suggested that the Scrum Master is accountable for a successful delivery. Lastly, this role is
accountable for all Scrum events, including facilitating them productively (Schwaber &
Sutherland, 2020).
Scrum also specifies the organizational level of accountability. For example, Scrum Mas-
ters are teachers, coaches, and change leaders, continuously supporting the organization
toward the Scrum adoption (Schwaber & Sutherland, 2020). Therefore, they are accounta-
ble for the organizational success in adopting Scrum.
The type of accountability and roles the Scrum Master play depends on the organizational
and team maturity, change willingness, and priority (Spiegler et al., 2020). Ultimately, it
can be challenging to determine the success of the role. Hence, it is essential to rely on its
purpose to support others and encourage better adoption of Scrum.
2.4 The Customer Involvement

“Customer collaboration over contract negotiation” writes Beck et al. (2001a, para. 2). Cus-
tomer involvement in Scrum is influenced by the idea that working closely with a cus-
tomer enables a team to develop a more aligned solution with the customer’s expecta-
tions. Considering the pace of change, frequent collaboration with the customer also
enables the team to negotiate and adapt their plans when new information arrives.
According to the Scrum Guide, the primary involvement of the customer is providing feed-
back on work items called “Backlog items” (Schwaber & Sutherland, 2020). In Scrum, cus-
tomers can do this via the following channels:
• ongoing conversations with the Product Owner

• attending the Sprint Review, where the team demonstrates their increment of the previ-
ous Sprint and asks for feedback for future ones
• joining the Sprint Planning, where the team aligns on the scope of the work for the
upcoming Sprint
• joining the on-demand conversations prior to the planning, where the team clarifies the
purpose of certain items
According to Lohan et al. (2011), the idea of focusing on customer needs is hard to imple-
ment considering the misunderstandings and communication challenges that can occur
due to the customer type, location, collaboration abilities, and prior experience working
with the Scrum team. For example, some Product Owners do not collaborate directly with
the customer. According to Lohan et al. (2011), large organizations might utilize a proxy to
represent the customer. This brings the challenge of a misaligned understanding of the
42
customerʼs needs. Also, the various collaboration styles might influence the Scrum teamʼs Proxy
perception of the customer. As a result, when a Scrum team attempts to improve its cus- A person representing the
customer to the Scrum
tomer-centricity, it should consider taking on tasks such as conducting customer and mar- team
ket research, setting up feedback systems, and continuously identifying opportunities to
improve the direct relationship with the customer (Lohan et al., 2011).
2.5 The Organization

In alignment with the Agile Manifesto, the organization is expected to “build projects
around motivated individuals [, give]e them the environment and support they need, and
trust them to get the job done” (Beck et al., 2001b, para. 5), suggesting that the organiza-
tion should accept the Scrum team and their way of operating. Moreover, the Scrum Mas-
ter role serves the organization as a whole rather than their team only. As suggested by the
Scrum Guide, Scrum Masters are expected to lead, train, and coach the organization to
adopt Scrum to remove implementation impediments between the organization and the
Scrum Team (Schwaber & Sutherland, 2020).
According to Sutherland (2001), “Scrum works in any environment and can scale into pro-
gramming” (p. 10). He goes on to describe how he implemented Scrum in five organiza-
tions, suggesting that Scrum can fit everywhere with suitable modifications. The five
organizations were the following:
• The Easel corporation is also known as the first implementation of Scrum for a software
Development Team delivering a new tool.
• The VMARK Group was the first adaptation of Scrum to senior management teams to
reinvent the company products on the internet.
• Individual Inc. was the first implementation of Scrum to develop digital products and Digital products
accommodate the rapidly shifting priorities. products available on a
computer or the internet,
• The IDX Systems corporation was the first adaptation of Scrum to include multiple such as online search
Scrum teams for the same product. engines and online stores
• Patientkeeper Inc. was the first integration of Scrum with teams working with eXtreme
Programming, combining the Scrum approach with other Agile methods.
While each organization adopted Scrum differently to support their product development
within their organizational setup, the commonality here is that each Scrum implementa-
tion was given complete trust to operate that way. Moreover, the senior management sup-
ported it by doing it themselves, which allowed a faster acceptance of the new operating
model. For example, at IDX System, where Scrum was implemented at scale, the entire
organization adopted Scrum, including support functions (Sutherland, 2001).
According to Schwaber and Sutherland (2020), the Product Owner accounts for stakehold-
ers influencing the product. Thus, they should be respected by them and maintain a con-
tinuous interaction. Also, the Scrum Master accounts for supporting organizational func-
tions (Schwaber & Sutherland, 2020). Hence, it suggests the Scrum team must account for
43
all stakeholders, including internal stakeholders, customers, and users. However, this is
not clearly defined in literature, and every organization and Scrum team is expected to
explore and discover what works best for them.
SUMMARY
Scrum is a process-driven framework supporting an organization in
delivering various projects and products. The framework introduces
three core roles to enable that: the Development Team, Product Owner,
and Scrum Master. Together, they are called the Scrum team.
Although Scrum could be used to develop various types of complex

projects and products, Scrum teams are mostly associated with product
development. To reduce process inefficiencies, the Development Team
consists of up to nine team members from multiple functions. Together
with the Product Owner and Scrum Master, they are expected to self-
organize themselves to deliver a product increment that meets their
customersʼ expectations and quality standards.
The Product Owner role is introduced to support the Scrum team in

determining the customerʼs expectations. Their role focuses on commu-
nicating continuously with the team, stakeholders, customers, and users
to ensure clarity and alignment on product requirements. Also, they are
the primary person responsible for building better customer relation-
ships. Sometimes, the Product Owner is also known as the on-site cus-
tomer.
The Scrum Master role supports new Scrum teams in implementing and
adapting their working methods to the Scrum framework. They act as a
servant leader, supporting the team, Product Owner, and the organiza-
tion to get better using Scrum, mainly when complete adaptation is not
possible. The Scrum Master role remains vital to maintain accountability
on product delivery in the Scrum approach.
Scrum also requires taking a different approach to involving customers.

It challenges many organizations due to their customer types, location,
and operating models. However, ultimately, Scrum relies on customer
focus, which can also be achieved in challenging setups.
Similarly, Scrum requires the organization to be open and supportive of

the Scrum implementation. Each Scrum team should familiarize them-
selves with the organizational ecosystem, ensuring they receive the
trust, support, and information they require, and that they communi-
cate effectively with the functions they impact.
44
UNIT 3
PRODUCT BACKLOG AND SPRINT
PLANNING
STUDY GOALS
– explain a Product Backlog.

– explain what the refinement process entails.
– understand what makes a Product Backlog item ready for development.
– explain how Scrum teams measure capacity.
– explain how Scrum teams prioritize and select what to work on.
3. PRODUCT BACKLOG AND SPRINT
PLANNING
Case Study
FurnitureABC is an American online retail furniture company headquartered in the USA
and Germany. Since its establishment, FurnitureABC’s competitive advantage remained in
its speed of delivery. Their great success is associated with their in-house software for the
entire operations pipeline, including suppliers onboarding, warehouse, and transporta-
tion management. Over the years, FurnitureABC success translated into business and
organizational growth. Recently, the market demand for buying furniture online led to
hundreds of new suppliers joining the online space, with FurnitureABC as their first choice
of a partner. As a result, the number of customers buying furniture online increased. Also,
FurnitureABC had to hire hundreds of new employees to keep up with the pace.
With the exponential growth of suppliers, customers, and employees, the technology
team at FurnitureABC kept warning the executive management that their software system
was not designed to support the high volume of new users and requests. In recent
months, the furniture website was barely accessible due to the high number of customers.
Orders started running late, arriving faulty or not at all, leading to FurnitureABC’s competi-
tive advantage being questioned. As a result, the executive team nominated a new Scrum
team to rebuild FurnitureABC’s operating software with the latest technology.
FurnitureABC’s Scrum team consisted of nine expert engineers, a Product Owner, and
Scrum Master. Together, they brought diverse experiences and skillsets in building internal
operations solutions and understanding the online retail market. Therefore, they felt moti-
vated and confident they knew how to develop such a software product. The Product
Owner had also worked as an operations consultant before joining FurnitureABC. Thus,
they felt fully equipped.
After two weeks of conversations with FurnitureABC’s executive management about the
product requirements, the Product Owner introduced a requirements list, a Product Back-
log. They planned that the entire team would come together every two weeks to choose
requirements to work on. The developers would then build, test, and review these with
the Product Owner. However, after a few weeks, the developers began insisting that cer-
tain topics could not be worked on. Also, items seemed never to get done as they were
pushed from one planning to another.
Puzzled by the situation, the Scrum Master investigated what was preventing the develop-
ers from getting things done. The investigation highlighted potential issues. For example,
the Product Backlog seemed too vague, and the Development Team seemed to lack
important context on user behavior. Lastly, there appeared to be no alignment between
the amount of work to be done and team capacity. What were they doing wrong? At the
end of this unit, you will be able to answer that.
46
3.1 Principles of a Product Backlog
The Product Backlog is a Scrum artifact utilized to capture and keep track of the work to Artifact
be done on a product. In Scrum, the Product Backlog represents a singular to-do list of the In a Scrum context, arti-
facts refer to the content
Scrum team. As such, it consists of a list of prioritized work items (Schwaber & Sutherland, the Scrum team creates;
2020). it can be a living docu-
ment or stored digitally in
a tool.
Figure 6: Ordered Product Backlog
Source: Bar Schwartz (2022), based on Scrum.org (n.d.-d).
In Scrum, teams work in a cadenced-based approach where the Scrum team works in one
to four weeks of recurring cycles called Sprints. In each Sprint, the team selects a set of
work items they intend to work on throughout the Sprint. These items are then clarified,
sized, and committed to being worked on by the Development Team. Together, the work
items selected for a Sprint represent a product increment that can be tested with the cus- Product increment
tomer (Schwaber & Sutherland, 2020). These are selected user
stories for development
for the duration of a
Product Goal Sprint. Each increment
can be delivered to a cus-
tomer to gather feedback.
In Scrum, a product has a future target representing the core value proposition of the
product. The Product Goal reflects the purpose and scope of the product, supporting the
Scrum team to focus and orient themselves when they are planning their work (Schwaber
& Sutherland, 2020).
The Product Goal is not an aspirational vision. It is a precise target image that captures
potential customer needs (Nettleton, 2021). This image is captured in the Product Backlog
by work items called Product Backlog items (Schwaber & Sutherland, 2020).
47
Product Backlog Items
Product Backlog items differ from product requirements in the perspective they provide.
Both Product Backlog items and requirements describe the product’s functionality,
including intention and potential benefits. However, product requirements describe it
from the product perspective, while the Product Backlog items describe it from the cus-
tomer perspective (Mkrtchyan, 2022).
Product Backlog items represent hypotheses the Scrum team can test by collaborating
with their customers (Partogi, 2021). Product Backlog items change and evolve. Ideally,
continuously revising the Product Backlog items generates an inspect and adapt process
in the Scrum team, enabling them to learn and improve the Product Backlog (Schwaber &
Sutherland, 2020).
Sprint Backlog
The Sprint Backlog consists of the set of selected Product Backlog items the team is inten-
ded to work on throughout the Sprint. Similar to the Product Backlog, the Sprint Backlog
is prioritized and sized to capture each item’s value and potential work to be done. To ach-
ieve this, the Product Owner and Development Team are engaged in a process called
“Product Backlog refinement” (Schwaber & Sutherland, 2020, p. 10) or “backlog groom-
ing” (Agile Alliance, 2022, para. 1). In this process, the Product Owner clarifies the purpose
and scope of the Product Backlog item, and the Development Team evaluates the work to
be done (Schwaber & Sutherland, 2020). Ultimately, by the end of the Sprint, all items
selected for the Sprint Backlog are completed during the Sprint (Zverugo, 2018).
Sprint Goal
Like the Product Goal, the Sprint Goal captures the future state of the product. However,
while the Product Goal can consist of multiple customer needs and objectives, the Sprint
Goal consists of one objective. Also, the Sprint Goal is a precise target image of what the
product increment should be. This allows the team to focus and orient themselves toward
a concrete Sprint outcome. Ultimately, a Sprint Goal remains the point of reference for
negotiating the scope tradeoffs, allowing the Development Team flexibility on how to
develop the product (Schwaber & Sutherland, 2020).
Sprint Planning
Ceremony Sprint Planning is a Scrum event, previously known as a ceremony, to ensure understand-
In older Scrum Guides, ing of the Product Backlog items and generate the Development Team’s commitment to
the Scrum events are also
called ceremonies due to developing it (Schwaber & Sutherland, 2020). According to Schwaber and Sutherland
their reoccurance and rit- (2020), Sprint Planning includes three parts:
uals.
48
1. Value definition. The Product Owner proposes a product increment consisting of pre-
selected Product Backlog items. The Development Team and Product Owner define a
Sprint Goal collaboratively to reflect the Sprint target. This goal is also communicated
to the stakeholders.
2. Refinement and negotiation. The Product Owner and the Development Team refine
the preselected Product Backlog items. The Development Team reflects on their pre-
vious work, upcoming Sprint’s Product Backlog items, desired Sprint Goal, and
capacity to determine what they can commit to. The Development Team must fully
understand the Product Backlog items and Sprint Goal before committing. That
allows them to negotiate with the Product Owner an achievable scope. Otherwise,
they should not commit. If needed, tradeoffs are made in alignment with the Sprint
Goal.
3. Tasks breakdown. The Development Team invests in breaking the Product Backlog
items into smaller work items. Each work item consists of all activities and work to be
done to produce the product increment and deliver the Sprint Goal. Ultimately, the
Product Owner can then release that product increment to the customer.
After Sprint Planning, the Development Team starts working on the tasks clarified. During
the Sprint, they come together daily in an event called the Daily Scrum. In this event, the
Development Team aligns on their progress toward the Sprint Goal. This allows the Devel-
opment Team to escalate potential risks early. If scope changes are needed, the Product
Owner supports the Development Team in adjusting their upcoming work without failing
to deliver the Sprint Goal (Schwaber & Sutherland, 2020).
Figure 7: From Product Backlog to Sprint Backlog
Source: Bar Schwartz (2022), based on Zverugo (2018).
49
3.2 Refinement Process
The refinement process is an activity undertaken by the Scrum team with the intention to
improve the clarity of Product Backlog items. In Scrum, the scope of work of each Sprint is
emergent. As a result, the Scrum team comes together every Sprint to “break down” Prod-
uct Backlog items, ensuring their preciseness before the Development Team can plan how
to develop them during the Sprint. At this stage, the Development Team is also encour-
aged to “size” Product Backlog items and negotiate the scope with the Product Owner if
necessary (Schwaber & Sutherland, 2020, p. 10).
Schwaber and Sutherland (2020, p. 10) discuss three main activities as part of the refining
process of a Product Backlog:
1. “Adding details” refers to the activity of clarifying information by adding context and
descriptions.
2. “Order” refers to the activity of prioritizing the sequence of the work to be done.
3. “Size” refers to the activity of providing estimates by evaluating what needs to be
done.
These activities occur in a meeting at least once a Sprint (Alblas, 2018). However, this
meeting is not officially a Scrum meeting, and the only reference to refinement in the
Scrum Guide is in the context of an activity undertaken by the Scrum team (Schwaber &
Sutherland, 2020, p. 10).
The “Refinement Meeting”
According to Alblas (2018, para. 5), refinement is a positive standard practice for the Scrum
team to engage in. Ultimately, whether the team conducts it as a meeting or a set of activi-
ties, the purpose remains the same – to discover together what needs to be done and how
to approach the development. However, considering each role in the Scrum team’s
responsibilities in the refinement, Alblas (2018) suggests it is more suitable to be a set of
activities rather than a meeting. The following objectives are the core responsibilities in
the Scrum team during the refinement process:
• The Product Owner focuses on defining the most valuable scope of work to develop or
produce.
• The Development Team focuses on determining the best way to build the scope of
work.
• The Scrum Master focuses on the feedback cycle of learning from previous activities
(Alblas, 2018).
These responsibilities can be met in diverse ways outside of a meeting.
Product Owner refinement activities
Product Owners are responsible for managing the Product Backlog and setting a Product
Goal (Schwaber & Sutherland, 2020). As a result, they are continuously engaged in activi-
ties that support them in refining the Product Backlog items, such as creating a product
50
vision and a product roadmap, writing and organizing Product Backlog items, and refining
their understanding of the customers and stakeholders by testing product hypotheses
(Alblas, 2018).
Product Owner refinement activities include taking different perspectives. These are
explained below.
Long-term thinking
Product vision interprets the product’s purpose (Schuurman, 2017). According to Schuur-
man (2017), a product vision is about setting the intention of the product by defining the
problems it intends to solve. A Product Goal, similar to the product vision, interprets the
product’s future state by specifying customer needs and expectations (Nettleton, 2021).
Creating both is a collaborative effort with the stakeholders, customers, and the Develop-
ment Team. It is also a learning experience, as the product vision can evolve with the
learnings about the product (Schuurman, 2017). Thus, its creation can support refining a
Product Owner’s understanding of what is valuable to build.
Feedback learning cycles
Product Backlog items capture customer needs from the customer perspective (Nettleton,
2021). Product Owners write product hypotheses that they can test with stakeholders and
customers. Also, Product Backlog items are expected to include a target state and objec-
tives to be met to guide the team on what success could look like. The activity of writing
and organizing these items according to stakeholder and customer feedback supports the
Product Owners and Development Team in refining the Product Backlog (Schuurman,
2017).
According to Wolpers (2022), Product Owners should avoid treating their Product Backlog
as an idea repository. A long list of Product Backlog items that are too abstract to deter-
mine value can be overwhelming to maintain and continuously refine. Product Owners are
recommended to avoid seeing themselves as solely responsible for the Product Backlog
items in order to avoid taking over writing the development approach for the Develop-
ment Team or mistaking themselves as the customer. Ultimately, Product Owner refine-
ment activities are a collaborative process.
Development Team Refinement Activities
The Development Team is responsible for splitting the Product Backlog items into smaller
explicit items (Schwaber & Sutherland, 2020). However, they are responsible for refining
the Product Backlog items as the Product Owner. According to Alblas (2018), lack of infor-
mation is a common concern of the Development Team.
Development team refinement activities are intended to happen in preparation and dur-
ing the Scrum ceremonies. For example, creating a Sprint Goal during Sprint Planning
encourages the team to slice items creatively and negotiate tradeoffs with the Product
Owner (Alblas, 2018). Alblas (2018) also suggests the following activities for the Develop-
ment Team to refine the Product Backlog items:
51
• sizing items to generate an idea of what can fit into one Sprint
• treating backlog items as experiments to test a hypothesis to generate learnings and
validate assumptions
• defining metrics to understand customer behavior and usage of the product
Wolpers (2022) advocates for the Development Team not to become passive and accept
Product Backlog items from the Product Owner. A passive Development Team that strug-
gles to negotiate with the Product Owner might develop a less fitting product for their cus-
tomers. Also, the Development Team is recommended to allow a time gap in their plan-
ning for potential corrections, rework, and learnings instead of assuming best outcomes
scenarios when refining the Product Backlog.
Scrum Master Refinement Activities
The Scrum Master’s responsibilities include facilitating and moderating Scrum events
effectively to allow the Product Owner and Development Team to achieve the Scrum
event outcome (Schwaber & Sutherland, 2020). As such, the refinement activities of the
Scrum Master include facilitating workshops for slicing, estimating, and prioritizing Prod-
uct Backlog items. In these meetings, the Scrum Master supports the Development Team
in estimating the value, effort, and complexity of Product Backlog items. Also, Scrum Mas-
ters might encourage their teams to utilize development metrics to reflect on their previ-
ous work. For example, measuring the number of items they started and completed dur-
ing the Sprint to evaluate their average capacity (Alblas, 2018).
Scrum Masters are also responsible for coaching and training their teams to adopt the
Scrum values and flow (Schwaber & Sutherland, 2020). Thus, the Scrum Master is respon-
sible for highlighting to the team when they engage in unproductive ways to refine the
product (Alblas, 2018). Lastly, every team is encouraged to find the right level of refine-
ment that works for them. There is a tradeoff between refining too few Product Backlog
items or too many backlog items (Iqbal, 2022). Scrum Masters support their teams in dis-
covering what works and what does not (Alblas, 2018).
3.3 Definition of Ready

In Scrum, a refined Product Backlog is also known as “ready for selection in a Sprint Plan-
ning event” (Schwaber & Sutherland, 2020, p. 10). Thus, the “definition of ready” refers to
the standards of what is required of a Development Team to understand the scope of work
and feel confident enough to work on it to deliver their Sprint Goal (Mitchell, 2017).
The refinement of Product Backlog items can be a challenging process (Mitchell, 2017).
Scrum teams can struggle to determine how many items from their Product Backlog they
should refine to avoid not having enough refined items for the Sprint or refining too many
items that might need to be refined again if new information arrives (Iqbal, 2022). Also, the
Development Team might not plan sufficient time for refinement, leading to unrefined
Product Backlog items being selected for the Sprint with the risk of not being able to effec-
tively develop them (Mitchell, 2017).
52
Product Backlog items are recommended to be in a size and granularity that allows them
to be completed within the Sprint duration. Also, they are recommended to include suffi-
cient context information about what needs to be done, the intent behind it, and what cri-
teria will be used to determine its completeness (Mitchell, 2017). In other words, the defi-
nition of ready ensures the Development Team does not add items that do not fulfill these
criteria.
User Stories
To support Product Owners and Development Teams to write Product Backlog items, a
common belief of Scrum adopters is that they have to use a concept called “user stories”
(Overeem, 2017c, para. 1). Kent Beck introduced user stories in the 1990s as an alternative
to writing requirements (Chec, 2020). According to Chec (2020), Beck’s purpose with user
stories was to clarify the scope and intent of the product before developing it.
A common user story includes a definition of a user, a function or activity they want to
accomplish, and the intent behind wanting it (Chec, 2020). For example, a student wants
easy access to library resources, focusing on assignments rather than struggling with the
tools.
User stories are not a standard in Scrum. User stories provide one approach to structuring
a Product Backlog in a consistent style and encourage Scrum teams to think about their
Product Backlog items from a user’s perspective with needs and intentions (Overeem,
2017c). However, the primary purpose of the refinement is to ensure the Development
Team can commit to the Sprint Goal (Schwaber & Sutherland, 2020). Therefore, Product
Owners are expected to ensure that Product Backlog items are clear so that the Develop-
ment Team can engage in a productive conversation about the work to be done. User sto-
ries is one technique to potentially achieve that (Overeem, 2017c).
INVEST
Another approach to ensuring the readiness of user stories is called INVEST. INVEST is an
acronym introduced by Wake (2003) to determine the quality standards of user stories.
However, it can also be used with requirements. INVEST stands for independent, negotia-
ble, valuable, estimable, small, and testable:
• Independent suggests that work items should be completed independently without

relying on other work items to depend on them. While this is not always achievable, it is
a recommended practice to allow selecting work items in any desired order (Wake,
2003).
• Negotiable suggests that work items should not be final when given to the Develop-
ment Team. A work item should capture the concept rather than detail implementation.
The details should be uncovered through negotiating the scope (Wake, 2003).
• Valuable suggests work items should be needed by the customer. When Development
Teams split work into smaller items, it can become challenging to ensure smaller items
remain valuable. However, it is recommended that Development Teams work only on
items that are needed by their customers (Wake, 2003).
53
• Estimable suggests work items should provide enough details for Development Teams
to roughly determine their implementation. Vague work items might require an initial
analysis before they are estimable. Also, large work items might require splitting them
smaller before they are estimable (Wake, 2003).
• Small suggests work items should require a limited effort that can be completed within
weeks rather than months or years. As mentioned, large items are not estimable. Also, a
large estimate typically highlights a potential lack of understanding of the scope (Wake,
2003).
• Testable suggests work items should include sufficient information on how complete-
ness will be determined. Also, it allows a customer to test the work item and provide
feedback on it (Wake, 2003).
Whether a Scrum team chooses to utilize user stories, INVEST criteria, both or none, the
most essential idea behind them is ensuring that the Product Owner and the Develop-
ment Team invest a sufficient amount of time in refining the Product Backlog items to a
state where they are ready for selection during the Sprint Planning (Schwaber & Suther-
land, 2020).
3.4 Determining Capacity

Capacity is mentioned in the Scrum Guide as an activity that is part of the Sprint Planning
event (Schwaber & Sutherland, 2020). According to Schwaber and Sutherland (2020), the
Development Team determines their “upcoming capacity” based on their previous Sprint
capacity (p. 8). Thus, Development Teams new to Scrum might struggle with it at first.
However, they suggest that it improves with time.
When Scrum was introduced by Schwaber (1997) in the context of software development,
information technology (IT) projects experienced a high failure rate and were considered a
high risk to develop (Cule et al., 2000). According to Cule et al. (2000), over half of informa-
tion systems projects fail by exceeding budget and timelines (The Standish Group, 1994),
suggesting predictability is an issue in IT development projects (van der Meulen, 2021).
Estimating capacity and effort in IT projects influences the implementation efficiency, sug-
gesting Development Teams’ capability to estimate well is vital. At the same time, familiar
Scrum estimations techniques are based on “expert estimation” where the team deter-
mines their capacity and effort, unlike using algorithms or quantitative models (Rola &
Kuchta, 2019, p. 1). For example, relative sizing and story points are particularly favored
(van der Meulen, 2021).
Relative Sizing
Struggling to estimate is a common human challenge. The more unpredictable and

ambiguous something is, the harder it is to estimate (Everett, 2021). Thus, methods relying
on individuals’ expertise can vary in quality. Also, as those estimates rely on individual
expertise, they are highly influenced by the level of expertise, clarity of scope, and previ-
ous familiarity with the task at hand (Rola & Kuchta, 2019).
54
According to Everett (2021), Development Teams raise typical concerns when estimating.
Those concerns include ambiguity about the process of estimating and what is being esti-
mated, for example, complexity, effort, and time. Also, there is a potential fear resulting
from lack of experience, time pressure, and unpredictable scope changes and implemen-
tation approaches. As a result, Development Teams struggle with absolute estimations.
The alternative to absolute estimations is known as relative sizing. Relative sizing is a

process of determining an item’s size compared to another. While the item size is a num-
ber, that number reflects a combination of complexity, effort, and uncertainty (Everett,
2021). Thus, teams might size and order items differently considering their experience and
familiarity with that item. For example, what is a bigger task – taking a pet to the vet or
organizing a family vacation?
Story Points
Product Backlog items in Scrum as also known as user stories. While Scrum teams do not
have to use user stories in their Product Backlog, many believe it is a common practice
(Overeem, 2017c). As the name suggests, story points are a technique to measure the size
of a user story with points. For example, a story is worth five story points. This method
relies on relative sizing, as the Development Team is expected to integrate complexity,
effort, and uncertainty into their one number points estimate of a Product Backlog item
(Everett, 2021).
Story points often rely on a Fibonacci scale to reflect exponential complexity (Everett, Fibonacci
2021). However, relative sizing can be done in other scales and translated to story points refers to a mathematic
sequence of numbers in
later. For example, some Development Teams in organizations estimate with T-shirt sizes which each number sums
first and translate it to Fibonacci numbers afterward (XS = 1, S = 2, M = 3, L = 5, XL = 8). the previous two num-
bers (“Fibonacci number,”
2022)
T-shirt sizes
refers to an estimation
technique where T-shirt
size reflects the item size
(zehengl, 2016)
55
Figure 8: Relative Sizing With a Scale
Source: Bar Schwartz (2022), based on zehengl (2016)
Estimation Principles
Whether the Development Team chooses to estimate with relative sizing, story point, or T-
shirt sizes, Rola and Kuchta (2019, p. 2) suggest that the Development Team follows three
principles when estimating:
“Fuzzy” numbers 1. Estimate with “Fuzzy” numbers rather than absolute numbers.
refers to numbers that 2. Estimations should be agreed upon by everyone on the team.
describe possible values
rather than one singular 3. The estimations process should account for the human factor in estimating.
value (“Fuzzy number,”
2022) Rola and Kuchta (2019) align with the favored estimating methods such as relative size
and story points (van der Meulen, 2021). As measured in Fibonacci, story points are con-
sidered non-absolute estimations that capture complexity. Also, Development Teams are
expected to generate that estimation as a team, using process facilitation techniques such
Planning poker as planning poker. For example, in “Planning Poker in a Nutshell”, a Development Team
a facilitation technique to of five members are estimating a Product Backlog Item. They can select from a deck of
capture the estimation of
all team members at once card numbers between 1 and 40 as their suggested item’s estimation. First, all members
to identify diverse opin- reveal their estimation at once. Then, if the estimations vary, team members with the
ions (Cohn, 1998) highest and lowest estimation share their reasons for selecting the estimated value. After-
wards, all members repeat the voting process until their cards reveal the same estimation
number.
56
Figure 9: Planning Poker in a Nutshell
Source: Bar Schwartz (2022)
Velocity
As mentioned earlier in this unit, newly established Scrum Development Teams might
require time to gain confidence in their estimations. Previous experience plays an impor-
tant role in that (Schwaber & Sutherland, 2020). Therefore, metrics such as velocity can
support the Development Team in reflecting on their estimates (Doshi, 2018).
The velocity metric supports a Development Team in maintaining an overview of their

estimations from previous Sprints and their delivery reality (Doshi, 2018). For example, the
Development Team might estimate a Sprint Goal consisting of five Product Backlog items.
Each item is estimated with a Fibonacci number, suggesting they can work on a sum of 20
story points in the upcoming Sprint. In reality, they completed only four out of five Prod-
uct Backlog items. Thus, after subtracting the estimation of the uncomplete item, the
Development Team delivered 15 story points and not 20 as planned. They repeat this proc-
ess at every Sprint.
57
Figure 10: Velocity Chart of Three Sprints
Source: Bar Schwartz (2022), based on Doshi (2018)
Development teams are encouraged to utilize the velocity information for reflection. It
supports them to determine their capacity based on previous commitments and question
what is an appropriate scope for one Sprint. Also, it provides the Product Owner with an
indicator of the delivery speed, suggesting when a product increment will be delivered to
the customer (Doshi, 2018).
Velocity metrics also bring a risk of being misunderstood. For example, estimates are seen
as absolute numbers and lead to Development Teams being questioned for not delivering
on their story points commitment. Also, managers might use the metrics to compare
Development Teams, dismissing the uniqueness and subjectiveness of the story points
approach (Doshi, 2018). Lastly, it can confuse the Development Team’s commitment.
According to the Scrum Guide, the Development Team commits to delivering a Sprint
Goal, not Product Backlog items, as those are expected to be adapted during the Sprint
(Schwaber & Sutherland, 2020).
Determine capacity
While there are favored methods supporting Scrum teams to estimate their Product Back-
log items and generate an emerging understanding of their capacity, it is important to
refer to the purpose as defined by the Scrum Guide. Development teams are expected to
determine their capacity based on their previous experience and learnings (Schwaber &
58
Sutherland, 2020). They can utilize relative estimations, story points, and metrics as long
as they are utilized to capture the complexity and different points of view and generate
conversations and consensus (Rola & Kuchta, 2019).
3.5 Selecting Items and Defining the

Sprint Goal
In Scrum, the Scrum team works together to define a Sprint Goal that is aligned with the
Product Backlog item they intend to develop during the Sprint (Schwaber & Sutherland,
2020). According to Schwaber and Sutherland (2020), the Product Owner “proposes” a
potential product increment that allows the entire team to think together about what a
“valuable” Sprint Goal would be to their stakeholders (p. 8). Along with that, the Develop-
ment Team selects Product Backlog items from the prioritized backlog. Those items are
then refined with the Sprint Goal in mind, allowing the team to commit to the Sprint Goal
rather than specific Product Backlog items.
Product Backlog Prioritization
Scrum training and Agile consultancies typically refer to the idea of Product Backlog pri-
oritization as a mechanism to organize Product Backlog items (Mahapatra, 2022). Accord-
ing to Mahapatra (2022), prioritizing the Product Backlog is useful to improve the business
value generated, customer satisfaction, and management of dependencies. Also, it can
contribute to reducing the risk and selection time of items by the team, as well as improv-
ing the refinement process.
Scrum does not speak of prioritization but of ordering. It is about sorting the Product
Backlog to determine which item should be delivered first rather than which item is more
important (Scrum.org, n.d.-a). However, prioritization techniques might support refining
the Product Backlog and generating a shared understanding of the value of items. For
example, when the Product Owner, stakeholders, and Development Team engage in pri-
oritization activities, they clarify factors such as customer interest and impact, business
value, cost of development, risks, and perceived complexity. That allows determining
what functionality is important to deliver and what can be scoped out in case of con-
straints (Mahapatra, 2022). Hence, Product Backlog prioritization can be a useful refine-
ment exercise to support the Product Owner in envisioning the next product increment.
Product Increment and Sprint Goal
Envisioning a product increment is the Scrum-aligned approach to prioritization. Accord-

ing to the Scrum Guide, the Product Owner is expected to suggest to the team a scope of
work that would increase the product value. That scope is expected to be a useful and
usable increment, a “concrete stepping stone towards the Product Goal” (Schwaber &
Sutherland, 2020, p. 11).
59
At the end of the Sprint, the team is expected to deliver the Sprint Goal as a product incre-
ment (Schwaber & Sutherland, 2020). Therefore, the Sprint Goal determines the scope of
the Sprint and the constraints the Development Team has when selecting what backlog
items they would like to work on (Agile Alliance, 2021).
The Scrum Guide suggests that the Product Owner and development cooperate to deter-
mine what the Sprint Goal should be in alignment with the proposed product increment
(Schwaber & Sutherland, 2020). However, it is a common myth in Scrum teams that it is
the role of the Product Owner to determine the Sprint Goal alone (Ageling, 2019). Thus, it
is vital to clarify that a product increment set an objective, not a goal. The Product Owner
suggests an objective that describes what the customer need is, and the entire Scrum
team selects the Sprint Goal to describe the desired product increment.
Selecting a Sprint Goal can be challenging. The Scrum team should ensure that they are
clear and precise about the outcome. They should focus on a Sprint Goal that is realistic to
deliver within their Sprint duration. Also, the Sprint Goal should feel valuable so that the
team cares about it and focuses on it during the Sprint (SeaLights, 2020). SeaLights (2020)
suggests a structure that could be useful for teams in creating their Sprint Goal:
• purpose: Clearly define and state the intent behind the Sprint Goal. What is the value,
and what makes it important to deliver that value in the upcoming Sprint?
• approach: Clearly define how that goal should be met. What methods does the Devel-
opment Team intend to use to reach the goal?
• measurements: Clearly define how the outcome is going to be measured. How would
the Development Team know that they accomplished their goal?
According to SeaLights (2020), Scrum teams typically select their Product Backlog items as
the scope for implementation and the measure of success in reaching their goal. However,
a Sprint Goal can also be met by conducting research, building a prototype, along with
other approaches.
The Commitment
The Sprint Goal suggests an implementation scope. However, the Development Team is
also expected to commit to the Sprint Goal. Thus, an important aspect of selecting Prod-
uct Backlog items is also determining items’ readiness, sizing them, negotiating the effort,
and matching it with the Development Team determined capacity. The Development
Team can only commit when they feel confident that they can deliver the Sprint Goal. The
60
Product Backlog items selected represent the intention of what they would like to work on
(Agile Alliance, 2021). The commitment itself is to the Sprint Goal rather than the selected
items (Schwaber & Sutherland, 2020).
SUMMARY
The Product Backlog is an artifact in the Scrum framework that repre-
sents the scope of work for the Scrum team to deliver their Product
Goal. A Product Backlog consists of a list of Product Backlog items. The
items are ordered, sized, and expected to change and evolve as the
Scrum team learns more about their product and customer.
The Product Backlog is managed by the Product Owner. Every Sprint,

the Product Owner refines their understanding of the product and envi-
sions a potential product increment. That increment is then proposed to
the Development Team during the Sprint Planning to set the overall
objective for the Sprint.
The Product Owner and Development Team cooperate to create a Sprint

Goal. That goal provides the team with context on what a Sprint out-
come should look like. Then, the Development Team selects items from
the Product Backlog to refine and estimate.
The refinement process is shared by all roles in Scrum. It is intended to

support the team to slice Product Backlog items into smaller work items
that are easier to scope and estimate. Product Backlog items are refined
until they reach a definition of ready where the Development Team feels
comfortable with the size, scope, and estimates.
The Development Team determines its capacity based on historical data.

This allows them to continuously reflect on their performance and
determine what scope of work they can finish during a Sprint. This also
allows them to effectively negotiate selected items’ scope to ensure suc-
cessful delivery of their defined Sprint Goal.
FurnitureABC falls into a common challenge of Scrum teams not suffi-

ciently refining Product Backlog items. The Scrum Master role is vital to
support the team in finding the right balance.
61
UNIT 4
EXECUTING THE SCRUM PROCESS
STUDY GOALS
– explain the Scrum process.

– explain the purpose of the different Scrum events.
– describe how to run each Scrum event.
4. EXECUTING THE SCRUM PROCESS
Case Study
Jo is the software engineering department lead at a fintech startup based in Berlin, Ger-
many. The company consists of 40 employees, of which half are part of the software engi-
neering department.
Jo’s department has grown in the last year since their product’s launch in the market, and
the software engineering department has decided to split the 20 engineers into cross-
functional teams, including a business representative and all engineering roles required to
develop their finance product. Jo thought it was a great opportunity to introduce the
Scrum framework to the teams.
In the first week since Scrum was introduced, everyone in the company was excited to
learn the Scrum framework. The business representatives became Product Owners, which
they perceived as a promotion. On every team, one of the engineers in the team took over
the Scrum Master role and received a two-day training. Overall, Scrum was welcomed with
a keen interest to become more self-organized and empowered to make decisions.
In each team, the Scrum Master introduced to the team the Scrum process and Sprint
cycle. From now on, each Scrum team participate in two week-Sprints where they plan
their work in the Sprint Planning and demonstrate it in the Sprint Review. In between, the
team comes together for a 15-min Daily Scrum to check on how they are doing. Each cycle
also includes an event called Retrospective to allow the Development Team to recap their
Sprint, and generate perspectives and insights that support them in improving their future
work.
Three months in, the Scrum teams struggled to deliver anything new. Different engineers
came to Jo frequently to complain about the number of required meetings. Also, Scrum
Masters complained that the Product Owner was never there when needed. Not to men-
tion, half of the week goes into planning activities on things that are never being deliv-
ered, and the Retrospective became all about complaining and blaming.
Puzzled by this feedback, Jo started attending some of the Scrum events to identify what
had gone wrong. Soon he discovered that the Product Owners kept deprioritizing the
Scrum events due to conflicts with other business meetings they attended. As a result,
Product Backlog items were not ready when introduced in the Sprint Planning, resulting in
a long process of refinement at the beginning of every Sprint. The Scrum Masters had real-
ized this but felt uncomfortable telling their team to stick to the event-prescribed time or
challenging their team to hold each other accountable for their commitment.
This unit focuses on the Scrum process, the Sprint cycle, and the Scrum events. At the end
of this unit, you will know how to support teams such as Jo’s team with common Scrum
adoption challenges, ensuring Scrum teams can benefit from the Scrum events rather
than wasting their time in meetings.
64
4.1 The Scrum Process
Scrum is a process-driven product development approach centered around feedback Process-driven
cycles. In Scrum, development is split into time-constrained cadences called Sprints. In refers to development
approaches where the
each Sprint, four events take place intending to support learning and reflection conversa- process and procedures
tions that influence future Sprints: Sprint Planning, Daily Scrum, Sprint Review, and Sprint remain constant rather
Retrospective (Schwaber & Sutherland, 2020, p. 7). than the plan itself
In every Sprint, the Scrum team is committed to developing a Sprint Goal. This Sprint Goal
is a product increment that represents a valuable slice of the product and is potentially
deliverable to a customer at the end of the Sprint (Schwaber & Sutherland, 2020).
Figure 11: The Scrum Process
Source: Bar Schwartz (2022), based on Scrum.org (n.d.-a)
For a product increment to be developed successfully, the Scrum team follows the Scrum
process and events to continuously “inspect and adapt” their Scrum artifacts: Product
Backlog and Sprint Backlog. Each artifact is intended to support the Scrum team in shar-
ing information that supports planning, developing, and learning from the work to be
done (Schwaber & Sutherland, 2020, p. 7).
The Scrum Guide suggests that Scrum teams repeat the Scrum events in a fixed cadence Fixed cadence
to avoid the complexity of scheduling them and create process consistency. Also, Scrum Events in fixed cadence
occur repeatedly in a pre-
events are time-constrained and are intentionally designed to replace or reduce the defined rhythm.
Scrum team’s need for more meetings (Schwaber & Sutherland, 2020).
65
Inspect and Adapt
The Scrum process originated in the Plan Do Study Act (PDSA) learning cycle introduced
by Walter Shewhart in 1939 in the context of quality assurance product improvement
(Manuele et al., 1940). This learning cycle approach is also known as empiricism, a scien-
tific approach that is based on transparency, inspection, and adaption (Reindl, 2014). In
other words, the Scrum process is designed to create learning opportunities for the Scrum
team as they engage in developing a product.
According to the Scrum Guide, the Scrum events depend on the implementation of the
empirical approach (Schwaber & Sutherland, 2020):
• Transparency ensures the work is visible. Visibility of work is vital to ensure decisions
are made effectively and based on the right information. Also, it is vital for generating
alignment (Deneir, 2021a).
• Inspection ensures detecting changes early. Early detection is vital to surface impedi-
ments and issues in the development progress. Also, it is vital to continuously ensure
that development is aligned and on track with its intended goal (Deneir, 2021f).
• Adaption ensures the ability to act. The ability to change and improve is vital to reduce
risks and handle the pace of changing requirements. Also, it is vital to allow an effective
response to the changes identified during the inspection and reduce unintentional
modification of the intended goal (Deneir, 2021k).
Together, each of the pillars is built upon each other. Adaptation requires inspection, and
inspection requires transparency (Schwaber & Sutherland, 2020). Thus, each Scrum event
is focused on generating learnings and insights collaboratively and transparently to detect
and respond to change early.
Scrum events create intentional opportunities for the Scrum team to “inspect and adapt
the Scrum artifacts” (Schwaber & Sutherland, 2020, p. 7). Thus, Scrum events are centered
around the creation, adaptation, improvement, and revision of the product and Sprint
Backlogs.
As mentioned, the events are designed to repeat consistently in each Sprint and reduce
the need for additional meetings (Schwaber & Sutherland, 2020). This creates a constant
pace for the team. Also, meetings are time constraints (Schwaber & Sutherland, 2020). For
example, a one-month Sprint is recommended to invest the following time constraints to
their Scrum events.
Table 2: Scrum Events and Times
Daily 15 minutes
Sprint Planning 8 hours (maximum)
Sprint Review 4 hours (maximum)
Sprint Retrospective 3 hours (maximum)
Source: Source: Bar Schwartz (2022)
66
Although newly formed teams typically welcome the idea of organizing themselves
around learning opportunities, a common complaint is that the Scrum framework has too
many meetings (Overeem, 2017a). According to Overeem (2017a), Scrum teams struggle
with meetings due to reasons such as lack of preparation. Hence, it is suggested that the
core of the Scrum process is in the effective execution of the Sprint events within the
Sprint cycle discussed in the next section.
4.2 Sprint Cycle

A Sprint is a time-constraint “container” in the center of the Scrum framework. According
to the Scrum Guide, the Sprint is “the heartbeat of Scrum,” where ideas are turned into
value. This metaphor is derived from the Sprint being at regular intervals. Hence, Sprints
have a steady duration and structure. When one Sprint ends, the next starts promptly
afterward (Schwaber & Sutherland, 2020, p. 7).
The purpose of the Sprint cycle is to progress toward realizing a product goal. All Scrum
events that are part of the Sprint are shaped to support that. Each Sprint results in a prod-
uct increment, a slice of the product goal (Schwaber & Sutherland, 2020, p. 7). Thus, each
Sprint is a time-limited smaller project that requires planning, execution, review, delivery,
and reflection (Ozkan & Kucuk, 2016). Ultimately, all steps necessary to deliver a slice of
the product goal take place within the Sprint’s boundaries (Schwaber & Sutherland, 2020).
The Learning Cycle
A Scrum event’s purpose is to generate learning opportunities. Events create a learning

cycle for the Scrum team where they come together to create a shared understanding and
alignment (Deneir, 2021e), inspect, and reflect concrete content (Deneir, 2021j), and
develop a plan on how to act in future Sprints (Deneir, 2021o). They include the events
described below (Schwaber & Sutherland, 2020).
Sprint Planningʼs purpose is to generate a shared understanding of and commitment to

the Sprint outcome, also known as the Sprint Goal. It starts by aligning everyone on the
desired scope of work by generating an effective conversation about the Sprint Goal and
Product Backlog items (Deneir, 2021a). Continue by inspecting the work to be done and
relating it to the original product goal, the desired Sprint Goal, and learnings generated
throughout previous Sprints (Deneir, 2021f). Lastly, a shared plan on how to achieve the
Sprint Goal is created by the Scrum team through negotiation and adaptation of the Prod-
uct Backlog items (Deneir, 2021k).
Daily Scrumʼs purpose is to create inspection opportunities for the Scrum team toward
their Sprint Goal. This allows the Development Team to escalate impediments early and
adapt their committed work in the Sprint as needed. It creates an opportunity for the
Scrum team to share what they are working on to ensure everyone remains aligned on the
Sprint Goal (Deneir, 2021b). Then, they identify potential deviations from the original plan
and discuss those deviations (Deneir, 2021g). Lastly, impediments are acted upon as
required, for example, a negotiation with the Product Owner on scope (Deneir, 2021l).
67
The Sprint Reviewʼs purpose is to create inspection opportunities of the Sprint Goal deliv-
ered. This allows the Product Owner and Development Team to receive feedback on the
value created and adapt their future Sprint Goals accordingly. It creates an opportunity for
the Scrum team to share their results with their stakeholders and customers, aligning
them with what has been accomplished (Deneir, 2021c). Then, they inspect any deviations
from the original plan communicated at the beginning of the Sprint and discuss the
impact of it on the long-term product goal (Deneir, 2021h). Lastly, the Product Backlog is
adapted to accommodate the feedback (Deneir, 2021m).
Sprint Retrospectiveʼs purpose is to create opportunities for the Scrum team to improve
their ways of working. This allows the Scrum team to reflect on their work and how they
have been working together as a team to improve in future Sprints. It creates an opportu-
nity for the Scrum team to share their experience of the Sprint without judgment (Deneir,
2021d). Then they inspect what goals, processes, and interaction variations and what
made those variations occur (Deneir, 2021i). Then, the most important issues are dis-
cussed and a plan of how to act on them is generated (Deneir, 2021n).
During the Sprint
For Empiricism to work and learning to happen, some aspects need to remain the same
(Reindl, 2014). According to Schwaber and Sutherland (2020), Scrum teams should adhere
to the following guidelines during the Sprint execution:
• “No changes are made that would endanger the Sprint Goal;
• Quality does not decrease;
• The Product Backlog is refined as needed; and,
• Scope may be clarified and renegotiated with the Product Owner as more is learned” (p.
7).
A Sprint is considered a short time frame of up to a month of work, ensuring that a small
enough scope of work can be committed without becoming obsolete. A Scrum team is rec-
ommended to choose the appropriate Sprint duration that balances the size of their work
and the risk of delivering the wrong objectives. The more complexity and uncertainty a
team experiences, the shorter Sprints they are recommended to have (Schwaber & Suther-
land, 2020).
Considering Sprints are intended to generate learnings around the delivery of a Sprint
Goal, they are designed to create a small enough increment that remains predictable
(Schwaber & Sutherland, 2020). As mentioned earlier, quality should be considered during
the Sprint and should not be reduced due to deviation from the original plan. Instead, the
Scrum team ensures progress toward the Sprint Goals that remains constant throughout
the Sprint. If needed, they continue to clarify their Product Backlog items and negotiate
their scope. However, the Sprint Goal is a constant.
The Scrum Guide mentions a variety of ways to maintain an overview of how the team is
doing. It is recommended for Scrum teams to attempt to predict how they are progressing
by utilizing metrics and diagrams such as a burndown chart (Schwaber & Sutherland,
2020).
68
However, Schwaber and Sutherland (2020) also warn Scrum teams that these metrics are Burndown chart
not an alternative to the learning cycle the Scrum events create. They remind us that the a chart diagram visualiz-
ing the progress toward
Scrum framework was introduced to address complexity and uncertainty, so predictability the completion of a pre-
measures are there to encourage inspection and allow effective adaptation. Ultimately, if a dictable and fixed scope
Sprint Goal cannot be achieved, the Product Owner is authorized to stop the Sprint cycle (Rubin, 2012)
and start a new Sprint.
4.3 Daily Scrum

Product Backlog items selected for the Scrum Sprint are listed in an artifact called the
Sprint Backlog. For each Sprint, the Scrum team comes together in the Sprint Planning
event to define a Sprint Goal and select Product Backlog items that align with this goal. At
the end of the Sprint Planning, the development commits to a Sprint Goal rather than the
list of Product Backlog items added to the Sprint Backlog. However, the Sprint Backlog is
the primary artifact they utilize to capture their Sprint plan (Schwaber & Sutherland,
2020).
Failing to deliver the Sprint Goal is a common anti-pattern in Scrum teams (Wolpers,
2022). While the Scrum Guide suggests Scrum teams focus on the Sprint Goal and avoid
any changes that might risk its successful delivery (Schwaber & Sutherland, 2020), Scrum
teams, unfortunately, sometimes confuse the commitment to the Sprint Goal and Sprint
Backlog items (Wolpers, 2022), suggesting it is more important to follow the original plan
than adapting it to enable a successful Sprint Goal delivery.
The Daily Scrum is a Scrum event that occurs daily for a duration of up to 15 minutes
(Schwaber & Sutherland, 2020). The intention of the Daily Scrum, as described by
Schwaber and Sutherland (2020), is to create a daily opportunity for the team to observe
their progress toward the Sprint Goal and adapt their Sprint Backlog items with necessary
changes.
Scrum teams typically operate with many unknowns (Reindl, 2014). The longer a Sprint is
and the more complexity the team experience, the higher the risk of a Sprint Goal becom-
ing irrelevant (Schwaber & Sutherland, 2020). In real life, Scrum teams might have to deal
with the dilemma of having to respond immediately to customers’ issues rather than con-
tinuing to follow their plan, for example, due to technical issues. Also, it is common for
Development Teams working on complex topics to realize they lack skill and information
and that Product Backlog items cannot be delivered, only after they started the develop-
ment (Wolpers, 2022). The Daily Scrum’s purpose is to address these type of issues.
During the Daily Scrum, the Development Team comes together to identify issues that
could stop them from realizing their Sprint Goal. This event occurs daily at a fixed time
and place to avoid the complexity of scheduling (Schwaber & Sutherland, 2020). Also, it is
limited to 15 minutes to avoid a status meeting reporting style (Blinov, 2018). However,
this time limitation is solely for the event itself. Developers are encouraged to continue
conversations with their Product Owner and each other during the day to resolve impedi-
ments and adapt their scope as required (Schwaber & Sutherland, 2020).
69
The Daily Scrum is an event for the Development Team rather than their management
(Blinov, 2018). It is supposed to encourage self-management in the Development Team,
supporting them to advance their interactions and rapid decision-making skills (Schwaber
& Sutherland, 2020). While it is the Scrum Master’s responsibility that the meeting occurs
and remains within the prescribed time, the Development Team owns the Daily Scrum. It
is a tool for them to revise their progress in any structure they deem fit for purpose
(Scrum.org, n.d.-c).
Figure 12: Daily Scrum in a Nutshell
Daily Scrum Structure
While the Development Team should find a structure that works for them (Scrum.org, n.d.-
c), there are structures recommended to support Scrum teams to effectively conduct the
Daily Scrum event (Alfonso, 2018). Development teams are encouraged to answer three
questions during the Daily Scrum:
• “What did you do yesterday?

• What will you do today?
• Are there any impediments in the way?” (Alfonso, 2018, Daily Scrum section)
The first two questions focus on inspecting their Sprint Backlog items’ progress and evalu-
ating how aligned it is with their original plan for the Sprint. The third question focuses on
identifying issues that might result in changes to the original plan (Alfonso, 2018). Ulti-
mately, the Daily Scrum is an “inspection, synchronization and adaptive daily planning”
(Rubin, 2012, p. 24). Thus, it enables the Development Team to organize their work, iden-
tify problems, and identify whether the over or under-committed. Thus, if a change is
required to the scope of the Sprint due to a problem or a new Product Backlog item that
needs to be implemented, the Development Team can discuss the impact of adding that
item to the Sprint during the Daily Scrum.
70
Alfonso (2018) suggests that the Product Owner is optional in the Daily Scrum. Also, stake-
holders are invited at times. However, the most important participation and focus are of
the Development Team. Nevertheless, Rubin (2012) suggests that the Product Owner’s
absence can impact the Development Team’s commitment.
4.4 Sprint Review

Scrum teams collaborate during the Sprint to deliver a Sprint Goal. At the end of the
Sprint, the Scrum team comes together with their stakeholders to review the delivered
Sprint Goal in an event called the Sprint Review. This is another opportunity for the Scrum
team to receive feedback from their stakeholders that influences their future Sprint Goals
Sprint Reviews are neither status meetings (Schuurman, 2017) nor demos of the product
to the stakeholders (Pavlichenko, 2017). They are intended to review how the Sprint dif-
fered from its original plan and discuss the value of the achieved outcome of the Sprint.
Ultimately, the Sprint Review is a workshop, not a meeting. The participants are expected
to work together on the Product Backlog rather than listen to a presentation. Thus, the
Sprint Review is limited to four hours on a month-long Sprint (Schwaber & Sutherland,
2020).
The Sprint Review event is owned by the Scrum team. Like the Daily Scrum, it is the Scrum
Master’s responsibility that the event occurs for every Sprint. Also, the Scrum Master sup-
ports the team by educating them on how to realize the meetingʼs purpose; thus, they
support the flow to inspect the outcome and adapt the Product Backlog, as well as adhere
to the time constraints (Schuurman, 2017). The Development Team is responsible for
demonstrating the Sprint outcome. The Product Owner is responsible for the review and
revision of the Product Backlog (Pavlichenko, 2017).
71
Figure 13: Sprint Review in a Nutshell
Sprint Review Structure
While there is no recommendation on how to facilitate the Sprint Review event in the
Scrum Guide (Schwaber & Sutherland, 2020), there are structures recommended to sup-
port Scrum teams in facilitating an effective Sprint Review. A Sprint Review flow could
look like the following:
1. The Sprint Review event starts with the Product Owner welcoming the stakeholders
and providing an overview of the Sprint Goal accomplished by the Development Team
during the Sprint.
2. The Development Team presents their Sprint outcome by demonstrating their work to
the stakeholders.
3. The Product Owner recaps the Product Backlog and discusses what the current out-
come means for the future Product Backlog items, including adjusting the timeline
and expectations as needed.
4. All participants contribute to discussing the upcoming Sprint objectives and adapting
the next Product Backlog items accordingly.
5. The Sprint Review ends with a review of dependencies, risks, and timeline (Pavli-
chenko, 2017).
This flow is tailored to generate and respond to feedback, as feedback is one of the most
important aspects of the Sprint Review. However, Pavlichenko (2017) also reminds Scrum
teams that stakeholder collaboration is just as vital. Ultimately, stakeholders can cancel
the development of the product, reduce financing of Product Backlog items, and make
commitments to customers based on the Sprint Review assumptions. In real life, some
Scrum teams silo themselves from their stakeholders, leading to stakeholders feeling
excluded and that their opinion on the product does not matter. As a result, they might
72
question the Product Owner’s authority. This goes against the Scrum framework, as the
primary responsibility of the Product Owner is to be the voice of the stakeholders
4.5 Sprint Retrospective

The Sprint Review event in Scrum focuses on the Sprint outcome. The Sprint Retrospec-
tive is a crucial event focusing on the way the Scrum team worked together to achieve that
outcome. This reflection is vital to allow the team to evaluate their ways of working to
improve future collaboration and deliverables (Schwaber & Sutherland, 2020).
The entire Scrum team attends the Sprint Retrospective, including the Product Owner. In
real life, some organizations implement the role of the Product Owner as higher in the
hierarchy or as a part-time business role that is not part of the Scrum team (Ageling, 2018).
However, the Scrum Guide states that the Product Owner is a Scrum team role, and the
Sprint Retrospective is for the Scrum team (Schwaber & Sutherland, 2020). Thus, Product
Owner attendance is mandatory.
Similar to other Scrum events, the responsibility of the Scrum Master is to educate the
team on realizing the Sprint Retrospective purpose, as well as ensuring its occurrence and
adherence to the time constraints (Schwaber & Sutherland, 2020).
In the Sprint Retrospective, the Scrum team discusses variations from their original Sprint
plan. They reflect on issues that occurred during the Sprint and identify changes and
improvements for future Sprints (Schwaber & Sutherland, 2020). Schwaber and Suther-
land (2020) also recommend including work-related improvements in the upcoming Sprint
Backlog.
Sprint Retrospective is also the last event in the Sprint and is limited to three hours for a
month-long Sprint (Schwaber & Sutherland, 2020). Thus, it occurs after the Sprint Review
and before the Sprint Planning of the next Sprint.
73
Figure 14: Sprint Retrospective in a Nutshell
Sprint Retrospective Structure
While there is no recommendation on how to facilitate the Sprint Retrospective event in

the Scrum Guide (Schwaber & Sutherland, 2020), there are structures recommended to
support Scrum teams in facilitating an effective one. A Sprint Retrospective flow includes
two parts: inspection and adaption.
Inspection can include collection information on the following elements: “What went well;
what didn’t go well; ideas for improvement” (Iqbal, 2021, para. 5). Alternatively, Scrum
teams can utilize an analogy, such as a speedboat drawing or a car drawing, to reflect on
what went well and what held them back (Iqbal, 2021). For example, in the speedboat ret-
rospective drawing, the anchor in the drawing represents potential blockers and impedi-
ments that occurred during the Sprint while the wind represents positive forces that sup-
ported the Development Team in achieving their goals. By reflecting on that metaphor,
each team member can reflect on their Sprint. Alternatively, the team can utilize a drawing
of their Sprint’s task completion timeline of the last Sprint, including the pace that Prod-
uct Backlog items were completed and feelings that occured throughout (Caroli & Caetano
Coimbra, n.d.).
74
Figure 15: Speedboat Retrospective
Source: Bar Schwartz (2022), based on Hectorhjure (2021)
Adaption includes prioritizing the most important opportunities for improvement. Then,
the Scrum team can evaluate what opportunities can be changed by them directly or
require additional support from the management or others (McMillan, 2021). Lastly,
improvement items are recommended to be written precisely and added to the upcoming
Sprint Backlog (Schwaber & Sutherland, 2020).
Scrum teams are advised to focus on things within their control. There are various
improvement opportunities Scrum teams can implement without requiring the permis-
sion of others. This supports the team in developing ownership. Also, Scrum teams are
encouraged to be courageous and open as it provides them with an opportunity to come
together as a team (McMillan, 2021).
After the Sprint Retrospective, another important aspect is concluding improvement

items. Sprint Retrospectives go beyond specifying what needs to be improved; they are
about committing to at least one improvement item to implement. Refining the item to
75
identify how to implement it is also important. Thus, Scrum teams should be as eager
about their continuous learning and improvement as they are about their product devel-
opment (Krebs, 2022).
SUMMARY
The Scrum process is based on the empirical scientific approach. Thus,
the Scrum process is based on three main pillars: transparency, inspec-
tion, and adaption, where each pillar relies on the other, creating the
learning cycle of inspect and adapt.
The Scrum framework splits development work into short sections

called Sprints. The Sprint is considered the heartbeat of Scrum because
it creates a reoccurring cadence-based approach to the Scrum process.
In each Sprint, the Scrum team engages in four Scrum events to create
the learning cycle within the Sprint duration: Sprint Planning, Daily
Scrum, Sprint Review, and Sprint Retrospective.
Every Scrum Sprint is designed to deliver a Sprint Goal. That Sprint Goal
is created during the Sprint Planning as a collaborative effort between
the Product Owner and the Development Team. The Sprint Goal also
defines the scope of the Sprint as the team commits to it and scopes
their Sprint Backlog to achieve that Sprint Goal.
76
UNIT 5
HELPFUL TOOLS
STUDY GOALS
– write Scrum user stories.

– facilitate Scrum estimation in a Scrum Planning event.
– describe how the Development Team operates during the Scrum Sprint.
– explain common practices for tracking progress in Scrum.
– discuss software communication and progress-tracking tools.
5. HELPFUL TOOLS
Case Study
Maria is a Product Owner in a newly established Scrum team developing a data analytics
software tool for human resources. Due to the fast growth of Maria’s company in recent
years, the demand for people analytics increased. While there are many solutions on the
market, the executives found that none aligned with their unique needs. Thus, the com-
pany decided to establish Maria’s team to develop internal tools. People from the entire
company were selected to take part.
As a newly established team, Maria and her colleagues were new to Scrum. Coming from
project management experience, Maria wanted her team to have a plan for the develop-
ment, including writing down detailed requirements. However, the Scrum Master and the
Development Team pushed back on that, suggesting they don’t need a plan and can plan
from Sprint to Sprint.
Over the first two Sprints, Maria felt lost. While she knew the Development Team was com-
mitted to a Sprint Goal, when Maria was able to attend the work discussions during the
Daily Scrum, she often felt lost and out of context. She kept asking the Development Team
what they are working on. Also, it was hard to judge whether there were any issues, as no
concrete impediments were raised during any Scrum meetings.
After sharing her concerns with the Scrum Master, they agreed that the Development
Team needed support visualizing their work in progress. Thus, the Scrum Master intro-
duced the team to a task board to support them in visualizing what they were working on.
Nevertheless, the Development Team seemed to never finish the scope they committed
to, and tickets kept being pushed from Sprint to Sprint. As a result, Maria, the Scrum Mas-
ter, and the Development Team decided to investigate helpful tools to support them in
planning, visualizing, inspecting, and adapting. These are discussed throughout this unit.
5.1 Requirements and User Stories

Scrum teams capture the work to be done for their product in a Scrum artifact called the
Product Backlog (Schwaber & Sutherland, 2020). The Product Backlog consists of Product
Backlog items representing a value hypothesis to test with a customer (Partogi, 2021).
Those value hypotheses are a form of capturing product requirements from the custom-
er’s perspective with the intention of capturing the requirement’s value rather than
desired functionality (Mkrtchyan, 2022).
Capturing requirement value is vital in Scrum. Compared to finite projects where the
scope and requirements details are fixed at the beginning of the development, Scrum pro-
ducts’ requirements are emergent. Thus, the Development Team requires a “degree of
freedom” on how they accomplish them (Rubin, 2012, p. 79). Writing the requirements in a
78
way that enables negotiation makes it cheaper to change them later in the process, as it
reduces detailed work on requirements that might become obsolete. For example, Rubin
(2021) suggested that it is common for customers to realize what they are missing only
after seeing the product developed no matter how much upfront planning is done.
Scrum requirements, the Product Backlog items, are suggested to be a conversation base-
line. They encourage a dialog in the Scrum team intending to “facilitate a shared under-
standing of what needs to be built” (Rubin, 2012, p. 81). This allows the Product Owner,
Scrum Master, and Development team to align on a shared goal in every Sprint Planning
and attempt to predict a realistic scope of work to achieve within the Sprint. Also, it pro-
vides them with sufficient clarity to determine whether they reached the goal (Deneir,
2021a).
Fixed requirements are typically documented in a long and detailed way that does not
allow for conversations. Thus, user stories are introduced as an alternative form to captur-
ing Product Backlog items (Rubin, 2012). According to Chec (2020), Kent Beck introduced
user stories in the 1990s as a form of capturing product scope and intent before develop-
ing it.
Mere functionality can also be misunderstood. User stories suggest a “lightweight” alter-
native to capturing Product Backlog items that is clearer for business stakeholders and
technical people. This form is intended to allow conversations while serving as a “central
placeholder” to capture relevant information and emerging details of a requirement
(Rubin, 2012, p. 83).
The Three Cs
Jeffries (2001) suggests that user stories should fulfill three vital elements known as the
three Cs:
1. Card. A size of a card limits the user stories description length. The card is described
as a physical card that indicates what the user story is about and reflects its priority
and cost. It should not include all requirements details as it represents the work, not a
specification.
2. Conversation. user stories are written to allow customers and developers to inter-
change them over time. Conversations are intended to be primarily verbal and replace
documents. They should occur promptly when the user story is due for planning
before its implementation.
3. Confirmation. user stories include a set of criteria for the Development Team to
determine how to test for successful implementation. Those acceptance criteria mani-
fest from the conversations with the customer. Defining them early allows the Devel-
opment Team to capture the customer’s desire and scope their work to meet that
desire.
Jeffries’s (2001) three Cs were initially described for teams working in eXtreme Program-
ming. Thus, developers are expected to work with a customer directly. In Scrum, the Prod-
uct Owner replaces the customer (Jeffries, 2019).
79
Capturing User Story Details
User stories come in varying levels of detail concerning their progress throughout the
Scrum flow. When user stories enter the Scrum flow, they might include a lower level of
details. As they progress through the flow, more details emerge until they are clarified fully
and committed to being developed during the Sprint Planning (Rubin, 2012). During the
Sprint, additional implementation details are discovered. However, the user story inten-
tion and success criteria are expected to remain fixed (Overeem, 2017b).
According to Rubin (2012), user stories can capture details for the various levels of abstrac-
tion of customers’ needs. A high level of abstraction can include an implementation scope
for a few months. A lower level of abstraction can fit a Sprint duration of a couple of days
or weeks. Thus, people might call those user stories by the following names:
• Epics refer to higher-level user stories as they provide a more holistic view of the scope
of work and the target rather than a well-defined scope of work for one Sprint. Duration
is typically captured in months.
• Features refer to user stories that describe a well-defined functionality for a release and
cannot be accomplished in one Sprint. Duration is typically captured in weeks.
• Stories refer to well-defined user stories that describe a slice of work that can fit into a
Sprint. This might be a well-defined functionality or a slice of it that can be delivered
independently. Duration is typically captured within the Sprint time and in weeks.
• Tasks refer to well-defined implementation work items to realize a Story during the
Sprint. Duration is typically measured in hours.
Product Backlog items might reflect a functionality or need. The implementation of multi-
ple user stories achieves that. Those might be captured in a cluster of user stories called a
Theme (Rubin, 2012). Nevertheless, Rubin (2012) suggests that the name matters less than
understanding how details emerge throughout the Scrum flow and are captured within
the user story until fully developed. Jeffries (2019) confirms this by suggesting people tend
to focus too much on the card itself and its level of information. The most important
aspect of capturing details is having conversations and confirmations throughout the
development.
Principles of User Stories
Conversations are a tool to clarify details, not documentation (Rubin, 2012). Thus, writing
high-quality user stories is vital to enable the continuous flow of detailing them. According
to Wake (2003), there are six principles user stories should follow to meet quality stand-
ards. They are summarized with the acronym INVEST:
80
• Independent suggests user stories should be self-reliant and provide value without
sequencing with other user stories (Wake, 2003). Ideally, Product Backlog items can be
ordered continuously without requiring a sequential development order to allow
removing lower value items when development time is insufficient to develop them
(Rubin, 2012).
• Negotiable suggests user stories should capture a concept rather than implementation
details to allow a conversation on those implementation details (Wake, 2003). Ideally,
Scrum requirements are written in a way that gives the Development Team room for
change and reduces the time of detailing requirements that might become obsolete
(Rubin, 2012).
• Valuable suggests user stories capture customer needs, providing value to the cus-
tomer (Wake, 2003). user stories with a technical focus should also capture the value to
the customer rather than the developer. This allows the Product Owner to determine its
appropriate budget and priority (Rubin, 2012).
• Estimatable suggests user stories should be clarified and refined sufficiently to allow
the Development Team to roughly determine implementation effort. Thus, vague user
stories should be refined and split into smaller user stories before the team can esti-
mate them (Wake, 2003). This is vital to allow the Product Owner to determine the user
story cost and order in the Product Backlog (Rubin, 2012).
• Small suggests user stories should be in a size that fits a Sprint duration. Larger items
can be harder for the team to estimate, resulting in higher estimates due to their vague-
ness (Wake, 2003). Also, larger user stories might require a longer duration to get scoped
down during the Sprint so the work might be carried to the next Sprints. Hence, user
stories should be small or captured as Features or Epics (Rubin, 2012).
• Testable suggests user stories should include sufficient information on what deter-
mines their completion (Wake, 2003). As suggested by Jeffries’s 3Cs, the Development
Team requires a way to determine what success looks like and confirm that they ach-
ieved the intended purpose of the user story (Jeffries, 2001).
According to Rubin (2012), there are times when user stories are valid without fulfilling the
criteria to be testable. Software product requirements can include system-level require-
ments that are non-negotiable for the customer and cannot be easily tested. For example,
the guarantee that a website is accessible online at any given time. These are called “non-
functional requirements” (p. 93). Nonfunctional requirements should be tested with every
user story rather than reflected as an independent user story (Rubin, 2012). For example,
Scrum teams developing a website might want to test it across browsers after any new
functionality they introduce.
Exploration user stories might also not fit the INVEST approach. Rubin (2012) suggests that
user stories describing gaining knowledge work should be captured in names, such as
“prototype” and “spike” (p. 93). These stories should be time-bound and have a clear
question to answer. This allows the Product Owner to determine the value of the informa-
tion gained and prioritize it accordingly.
81
Writing and Capturing User Stories
Product Backlog items intend to capture the customer perspective (Mkrtchyan, 2022).
Similarly, user stories are an approach to writing Product Backlog items, focusing on the
scope and its intent (Chec, 2020). Various templates attempt to capture that information
in a form that intends to increase clarity and alignment. Gralha et al. (2021, pp. 209–210)
refer to four of them:
1. “As a <type of user>, I want <goal>, so that <benefit>”

2. “In order to <benefit>, as a <type of user>, I want <goal>”
3. “As <persona>, I want <goal>, so that <benefit>”
4. “In order to <benefit>, as <persona>, I want <goal>”
Target user Each template captures information on the target user or persona, their intended goal to
the real user, the person accomplish with the product, and the benefit they receive by achieving those goals. For
who is using the system,
product, or service example, Jorge, a 21 to 45 year-old student in a part-time distance-learning program,
wants to have an easy way to defer the submission of his home assignment so that he has
Persona
more control over the pace of his studies.
aform of describing a user
using a “prototypical indi-
vidual” presentation User story writing workshops
deriving from aggregated
characteristics of their
role (Rubin, 2012, p. 96) Rubin (2012) suggests that one approach to capturing user stories using the above tem-
plate is conducting a “user story writing workshop.” In such a workshop, the Scrum team,
and their stakeholders “collectively brainstorm” what could create value for their custom-
ers and write the user stories.
According to Gralha et al. (2021), the different templates might impact the creation and
understanding of the user stories. For example, templates specifying a persona rather
than a type of user were faster to write. Also, templates starting with the persona were
more intuitive to write than those starting with the benefit. However, this effort was not
significantly felt by the workshop’s participants. In conclusion, Gralha et al. (2021) sugges-
ted that there might be no significant difference between the templates beyond the posi-
tive visual value of utilizing a persona.
82
Figure 16: Persona Example
User story mapping
Deriving user stories from ideation on customer value is one approach. An alternative is
deriving value from the activities the customer aims to accomplish with the product. This
technique is called Story Mapping (Patton & Economy, 2014).
“User Story Mapping is a dead simple idea” write Jeff Patton & Associates (n.d., para. 1).
Patton & Economy (2014) suggest that it is a simple way to tell and capture user stories.
In user story Mapping, there are five core elements:
1. User, typically represented by a persona

2. Activities, tasks done by the persona as they attempt to reach their goal
3. Narrative flow, a horizontal list of actions taken by the user as they attempt to reach
their goal
4. Details, breakdown or translation of the narrative into higher-level tasks to enable the
user to go through the narrative flow
5. Release slice, a form of capturing the details of which complete a product release to
the user
Ruben (2012) suggests that Story Maps can be translated into user stories. Activities can be
captured as epics, describing the overall intention. Actions derived from the Epics can be
captured as Themes or Features depending on their granularity. Details can be written as
user stories. The release prioritization process can similarly reflect a product release and
Sprint scope. Ultimately, the Story Mapping technique is suggested to be “complemen-
tary” to the user story writing workshop, as it provides an additional dimension to writing
and capturing user stories (Ruben, 2012, p. 98).
83
Figure 17: User Story Map Example
5.2 Planning Poker

Scrum teams can utilize diverse approaches to writing Product Backlog items. Regardless
of their chosen method, those Product Backlog items are continuously sized by the Devel-
Sizing opment Team. Sizing is a vital prerequisite for the Development Team to determine what
Refers to a quantifiable they can fit into the Sprint (Schwaber & Sutherland, 2020).
measurement agreed by
the Scrum team to
describe the amount of Sizing, also known as estimates, has no standard approach. Some Development Teams
work to be done on a prefer to work with story points captured in the Fibonacci sequence. Others prefer more
Product Backlog item
realistic methods, such as Ideal Days captured in days and hours. Regardless of the meth-
ods, development should be mindful of misinterpreted numbers (Rubin, 2012). Thus, fuzzy
numbers are favored for estimations as they describe a possible value rather than a fixed
value (Rola & Kuchta, 2019).
In Scrum, the entire Development Team is expected to agree on the estimations. Sizing is
expected to capture all work required to produce the product increment. Also, typical
Scrum estimation techniques rely heavily on the Development Team’s previous experience
and expertise. Thus, the facilitation process to derive those estimates must account for the
human factor (Rola & Kuchta, 2019). In other words, it must ensure that everyone voices
their opinion, facilitates discussion, and builds consensus.
Planning poker is one common technique for facilitating Product Backlog item sizing
(Rubin, 2012). At its core, it is consensus-based, focusing on engaging the experts in the
Development Team in conversations. These conversations are designed to reveal assump-
84
tions and derive a shared understanding of the implementation effort (Rubin, 2012).
Development teams can use it with any Product Backlog item approach and estimation
unit (Cohn, 1998).
Planning Poker Prerequisite
Successful facilitation of the Planning Poker technique requires the team to first have a
shared understanding of their Product Backlog items and the estimation scale they are
using to capture size. This allows the team to associate Product Backlog items with a size
on the scale by leveraging historical estimates. In other words, Scrum teams must refine
their Product Backlog items prior to the Planning Poker session to ensure they have suffi-
cient information to estimate and discuss the Product Backlog items. Also, Scrum teams
must decide on a scale before the Planning Poker session. The scale remains consistent
between Planning Poker sessions. The scale also captures the most fitting estimate for a
Product Backlog item (Rubin, 2012).
A typical Cohn’s Sequenceincludes numbers such as 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ?, Cohn’s sequence
and π (Rubin, 2012, p. 130). According to Rubin (2012), that typical scale is commonly an alternative and simpli-
fied sequence of num-
interpreted as the following: bers, inspired by the
mathematic Fibonacci
scale (1, 2, 3, 5, 8, 16, 32,
Table 3: Typical Scale
…) and proposed by Mike
Cohn (Rubin, 2012)
0 So small that it requires no estimation
½ Tiny items
1, 2, 3 Small-sized items
5, 8 Medium-sized items
13 Medium-sized items that should be sliced down

into smaller items
20, 40 Large items that potentially reflect work for multi-

ple Scrums
100 Extra-large item that potentially reflects work for

months (e.g., epic)
∞ Items so large that it is impossible to estimate

them
? The person estimating feels that they are unable to

estimate the item
π The person indicates their need to take a break
Source: Bar Schwartz (2022), based on Rubin (2012).
Development teams can choose to utilize this default scale or adapt their own. Online
tools allow that adaptation (Cohn, 1998), for example Planning Poker® (2022).
85
Another prerequisite is that the entire Scrum team is present when facilitating Planning
Poker. Each Scrum role has an important task:
• The Product Owner describes the Product Backlog items to the Development Team. Fur-
thermore, the Product Owner supports clarifying emerging questions during the esti-
mation discussions (Cohn, 1998).
• The Development Team estimates and negotiates estimations of the Product Backlog
items (Cohn, 1998).
• The Scrum Master continuously observes and ensures everyone voices their opinion
(Rubin, 2012).
Full participation also identifies when consensus cannot be achieved on a particular Prod-
uct Backlog item. The item is not estimated and is deferred until it can be fully refined
(Cohn, 1998).
Planning Poker Facilitation Flow
Planning Poker starts with the entire Scrum team coming together. Each Development
Team member receives a deck of Planning Poker cards adjusted to their agreed-upon
scale (Rubin, 2012).
The Product Owner selects a Product Backlog item to estimate and describe it to the
Development Team. In response, the Development Team discusses the Product Backlog
item. If anything is unclear, this is the time to ask questions to the Product Owner (Rubin,
2012).
When the Development Team feels confident to estimate, each member selects a Planning
Poker card privately to reflect their estimation of the Product Backlog item. At the count,
they reveal their estimation together. This allows for quickly identifying whether the
Development Team shares the same number or not (Rubin, 2012).
When the estimates align, the Product Backlog item is estimated. Then, the Product
Owner can move forward with describing the next Product Backlog item to estimate.
When the estimates differ, the team member is expected to engage in a conversation to
reveal the assumptions they made to derive their estimation. Typically, the higher and
lower estimators are the first to share their assumptions (Rubin, 2012).
When the Development Team feels confident to estimate again, they repeat the private
selection and reveal process. They continue clarifying assumptions every time the estima-
tion differs. Typically, it takes up to three rounds to align estimations (Rubin, 2012). How-
ever, suppose the Development Team cannot reach an agreement and the Product Owner
is unable to resolve it. In that case, they can decide to stop the estimation process and
differ until they refine the Product Backlog item further.
The Planning Poker flow overall is optimized to facilitate the “expert estimation method,”
as those suggested to “outperform” or align with other estimation methodsʼ performance.
The usage of a fuzzy number scale, such as the Cohn’s sequence, supports experts in the
Development Team to intuitively integrate risk and uncertainty into their estimations.
86
Also, it facilitates vital conversations on the potential solution in a similar manner to other
estimation methods. However, the lack of long-term data from previous research on the
topic suggests that it is premature to conclude the accuracy of those estimates over time
(Rola & Kuchta, 2019, p. 1).
5.3 Communication Tools

The ability of teams to work together on complex problems is at the foundation of the
Scrum framework. In Scrum, the product emerges through the process implemented by
the Scrum team. This process is empirical. Thus, it relies heavily on the team’s ability to
• make work transparent, visible, and understood by all.

• track their progress and inspect it frequently.
• reflect on deviation and adapt required changes.
Together, these three abilities enable the Scrum team to continuously “inspect and adapt”
(Schwaber & Sutherland, 2020, p. 8). For example, a Daily Scrum encourages the Develop-
ment Team to track their progress toward their Sprint Goal. If a deviation occurs or is iden-
tified to potentially occur during the Sprint, the Development Team is expected to act on it
by negotiating with the Product Owner on the scope or finding another solution.
The Scrum Guide does not refer to specific tools that enable Scrum teams to communicate
effectively. However, it does require Scrum teams to continuously work on artifacts such
as the Product Backlog, Sprint Backlog, and Increment (Schwaber & Sutherland, 2020).
A task board is a straightforward approach to enable Scrum teams to increase transpar-

ency during the Sprint. Its purpose is to communicate the Development Team’s progress
toward their Sprint Goal (Rubin, 2012). The task board can be a physical board or an online
board using tools such as Jira (Atlassian, n.d.), Trello (Trello, n.d.), and many other soft-
ware tools for Agile development tracking.
According to Rubin (2012), a simple task board includes the following statuses:
• Sprint Backlog includes the Product Backlog items the Development Team has com-
mitted to during the Sprint Planning. The items are ordered by order of execution.
• Tasks To Do include the breakdown of the Product Backlog items into concrete work
items, also called tasks, that are planned by the Development Team to realize the Sprint
Goal. The Product Backlog items cluster the tasks.
• Tasks In Progress include the tasks being worked on by the Development Team.
• Tasks Completed include the tasks the Development Team produced and consider
done.
In Scrum, work is only considered done when it meets certain criteria called “definition of
done.” This is a state where the entire Scrum team is aligned on the work that has been
completed. Moreover, the work can be presented in the Sprint Review as it meets all qual-
ity criteria (Schwaber & Sutherland, 2020, p. 13). Scrum teams can choose to make those
87
verification states explicit in their process. For example, add status for verification, specific
testing, and Product Owner review (Mountain Goat Software, n.d.), if it is useful to the
Development Team (Rubin, 2012).
The task board flow aligns with the Sprint flow. The Development Team moves the tasks
on the task board from Tasks To Do to Tasks In Progress, and to Tasks Completed (Rubin,
2012). If new information requires changes to the tasks, the Development Team adds a
new task or removes a task as necessary (Mountain Goat Software, n.d.).
In terms of ownership, there is no right or wrong. According to Nedre (2020), the Scrum
team should typically own the task board, while the updates on it are facilitated by the
Scrum Master. However, considering the responsibility of the Scrum Master to ensure the
sound implementation of Scrum and the usefulness of the Scrum events (Schwaber &
Sutherland, 2020), Scrum Masters are perceived to be the sole responsible person for the
task board (West, n.d.). Regardless of who is officially responsible for moving the tasks on
the board, the task board’s primary goal is to encourage a visible presentation of the
Development Team’s progress toward their Sprint Goal. Hence, it should be updated at
any given time.
Figure 18: The Task Board
Source: Bar Schwartz (2022), based on Rubin (2012)
88
5.4 Tracking Tools
The task board creates a transparent way for the Development Team to inspect their pro-
gress toward the Sprint Goal. However, for the team to grasp how they are doing, the
Scrum Guide encourages Development Teams to“forecast progress” (Schwaber & Suther-
land, 2020, p. 9). Schwaber and Sutherland (2020) refer to the common metrics of burn-
downs and burnups.
The burndown and burnup charts are traditionally used in project management to visual-
ize the progress of completing a fixed scope on a fixed date. It assumes that the scope is
planned and can be tracked by burning it down or up (Rubin, 2012). According to Rubin
(2012), both burndowns and burnups visualize the amount of scope completed over time.
The main difference is that burndowns focus on remaining work, while burn-ups focus on
progress toward a goal line. Hence, in burndowns, the work is finite; in burnups, the goal
line can move up. Rubin (2012) suggests two levels of burndown charts and burnup charts.
Fixed-Scope-Release Burndown Chart
The fixed-scope release associates a set of estimated Product Backlog items to a release
goal. The vertical axis, in this chart, is the scale used by the team to estimate Product
Backlog items such as story points. The horizontal axis is in Sprints. The graph plots three
lines to forecast potential outcome scenarios and one line to reflect the “actual” progress.
With each Sprint, the chart is updated with the Sprint outcome and the “actual” line is
adapted (Rubin, 2012, p. 327). For example, a release goal can be predicted to be accom-
plished by ten user stories with estimations summing up to 50 story points. The Develop-
ment Team estimates their capacity to be ten story points per Sprint. Thus, in the ideal
scenario, the release would be completed within five Sprints. However, based on the
teamʼs historical performance, the Product Owner can also predict that the Development
Team delivery might vary from delivering the entire scope within four to six Sprints.
89
Figure 19: Fixed-Scope-Release Burndown Chart
Fixed-Scope-Release Burnup Chart
Like the Burndown chart, the axis reflects the estimation scale versus the Sprints. Burnup
charts vary as they track progress toward a goal line rather than completing a fixed
amount of story points. Thus, that line can change if the release scope changes (Rubin,
2012). For example, a Development Team with a capacity of ten story points per Sprint
could ideally achieve a scope of 50 story points within five Sprints. However, Scrumʼs
scope is typically not fixed and might change as more information occurs. Thus, the Prod-
uct Owner could change the scope and move the goal line to accommodate the estima-
tions of the added or removed user stories.
90
Figure 20: Fixed-Scope-Release Burnup Chart
Sprint Burndown Chart
A Sprint burndown chart focus on how the team is progressing toward their Sprint Goal.
Thus, the vertical axis is the estimation effort in hours and not story points. Also, the hori-
zontal axis reflects the hours left in the Sprint, which allows the team to track “real work”
on their tasks (Rubin, 2012).
Figure 21: Sprint Burndown Chart
91
Sprint Burnup Chart
The Sprint burnup chart, like the fixed-scope-release burnup chart, tracks the progress
toward the goal. In this chart, the focus is on the Sprint goal. However, a Scrum team
might choose to have two lines reflecting both release and Sprint goals in one line. In this
case, some teams might prefer to visualize estimations effort in story points rather than
hours (Rubin, 2012).
Figure 22: Sprint Burnup Chart
5.5 Available Software Tools

As discussed throughout this unit, different tools are available to support teams in
improving their transparency and inspection capabilities. Maintaining Scrum events out-
comes, and tracking changes in Scrum artifacts and previous Sprints performance data
can become cumbersome when done on paper. Also, organizations nowadays might oper-
ate in environments where people work around the world. Software tools are available to
support Scrum teams in visualizing and tracking their work. Furthermore, software tools
can support stakeholder management, Scrum ceremonies, and making sense of historical
data.
Visualize and Track Work
A variety of software tools exist to visualize and track the work of Scrum teams. Most of
those tools are project management tools that include functionality that supports Scrum
product development. Others are tailored to support Development Teams using Scrum.
92
Regardless of the intended purpose of the tool, a set of product features must exist in visu-
alization and tracking software for an organization to utilize it as a Scrum tool (Aston,
2022). According to Aston (2022), there are five vital features a Scrum tool should have:
1. The Product Backlog is an essential artifact in the Scrum framework. It allows Scrum
teams to plan their work in the Scrum approach. Thus, a Scrum tool must include the
ability to create, edit, and manage Product Backlogs and Product Backlog items.
2. Sprints are an essential element of the Scrum framework. It allows the Scrum team to
cluster work in repeatable cycles. Thus, a Scrum tool must include the ability to soft
work items from the backlog into time constraints containers.
3. Charts and other visual representations of product development progress are vital to
support the Scrum team to generate insights. Thus, a Scrum tool must include basic
functionality to visualize charts, such as burndown and burnup charts.
4. Visualizations are important to generate transparency between Scrum team mem-
bers. Thus, a Scrum tool should include visualizations of real-time work in progress,
team tasks, and a task board.
5. Reports are essential to allow a Scrum team to report their progress to their stake-
holders. Thus, a Scrum tool should include the ability to do that, at least on a basic
level.
While many projects and product development tools support the features above, project
management tools, such as Jira, are considered the “best” for Scrum teams in 2022
(Aston, 2022, para. 1). While other tools are also proposed by Aston (2022), Jira is particu-
larly recommended, as it is the most familiar tool in the project management tools cate-
gory and is specifically designed to support Agile development. However, for smaller
teams seeking to merely visualize their task board without the larger project management
complexity, the most popular alternative to Jira is Trello.
Jira
Jira is a long-established software tool targeted to Agile development. It gained popularity

due to the ease of integrating it with other tools and the ability of Scrum teams to tailor it
to their needs (Aston, 2022).
Jira includes the ability to manage both projects and products developed in Scrum. It con-
tains the ability to create a tailored task board, including visualizing the Development
Team’s work process. Also, it contains features to cluster and visualize differences between
work items. Lastly, it can create visual reports and dashboards that contain valuable infor-
mation, such as a release plan, testing statistics, and other valuable information for the
Scrum team and their stakeholders to reflect on (Aston, 2022).
Trello
An alternative to Jira for Scrum teams seeking a simpler tool is Trello. Trello’s focus is cre-
ating a smart task board. The board is easily created, shared, edited, and tailored to the
Development Team’s needs. It allows integration into other communication tools the
Development Team might be using. Also, it allows the team to manage their schedules
within the board and generate insights based on board movement statistics.
93
Facilitation Support
Further to project or product management, the Scrum team might benefit from tools that
make the facilitation of Scrum events online easier. Those tools can be used for a specific
Scrum event or serve as a space for facilitating all Scrum events using recommended tem-
plates.
Online whiteboards such as Miro, Stormboard, and Mural, allow Scrum teams to collabo-
rate online. They are available everywhere and include templates for different events,
such as Planning and Retrospective. Also, they allow users to include files, present per-
sonal screens, and create spaces to vote on items (Guinness, 2022). They might be useful
for Scrum teams that run their Scrum events online and require a shared space.
Tools such as Planning Poker® (2022) focus on facilitating one Scrum event instead of
allowing free space for Scrum teams to collaborate on any content. Planning Poker®
(2022) allows teams to facilitate the Planning Poker activity and focuses on making it eas-
ier for teams to select their scale and run the estimation flow.
Like Planning Poker® (2022), Reetro (2021) focuses on facilitating one Scrum event – the
Retrospective. Reetro allows Scrum teams to create a collaborative space and includes
features to tailor the board, create items, and vote for them. The tool also integrates with
Scrum management tools, such as Jira and Trello, to maintain the data over time.
SUMMARY
A wide variety of tools are available for Scrum teams to implement
Scrum effectively. For example, while there is no one standard for creat-
ing and maintaining a Product Backlog, Three Cs and user stories pro-
vide us with principles for effectively writing Product Backlog items.
Also, user story workshops and Story Maps support the Scrum team to
collaborate with their stakeholders to gather, write, and capture product
requirements in this approach.
Planning Poker is one useful approach to bring the Development Team

to estimate Product Backlog items. As the estimation process requires
all team membersʼ expertise to be heard, it allows for capturing different
perspectives. Also, Planning Poker allows the Product Owner to identify
early what the cost of a Product Backlog item is and whether further
refinement is required.
Communication is essential for Scrum teams to inspect and adapt.

When combined with useful tracking tools, such as burndown and
burnup charts, the Development Team can surface deviations early and
act on them. The task board provides a visualization that allows the
Development Team to track their progress toward their Sprint goal. The
94
visualization allows the Development Team to have a meaningful con-
versation about their progress and determine whether they can still ach-
ieve the Sprint goal given their progress.
The Scrum team can utilize software tools to ease their communication
and tracking. Scrum tools provide an online mechanism to visualize,
inspect, and adapt work in progress. Also, additional tools to replace
whiteboards and facilitate Scrum events can ease the facilitation of
events online.
Throughout the Sprint, the Development Team comes together in the

Daily Scrum. The purpose of the Daily Scrum is to inspect the progress
toward the Sprint Goal and allow adaptation of the committed Product
Backlog items as necessary.
Scrum teams should avoid changing the Sprint Goal. If the Sprint Goal
becomes obsolete, the Sprint is canceled and replanned.
At the end of the Sprint, the Scrum team presents their outcomes to
their Stakeholders. This event’s purpose is to inspect the outcome,
gather feedback, and collaborate with the stakeholders to adopt the
future Product Backlog items.
The last event of the Sprint is the Sprint Retrospective. The Sprint Retro-
spective’s purpose is to inspect how the Scrum team worked together to
achieve their outcome. It allows the team to have an environment to
identify improvement items. Those items are then recommended to be
added to the upcoming Sprint Backlog, allowing the Scrum team to
adapt their ways of working and efficiently move forward.
95
UNIT 6
IMPLEMENTATION AND SCALING OF SCRUM
STUDY GOALS
– understand how to implement Scrum in a company.

– discuss the success criteria, risks, and limitations of implementing Scrum.
– describe principles for scaling Scrum.
– understand the principles behind common scaled frameworks.
6. IMPLEMENTATION AND SCALING OF
SCRUM
Case Study
ProcessABC is a young technology company located in Germany. Since 2010, ProcessABC
has been delivering software solutions to support organizations to make sense of their
processes. The demand in recent years for more data-driven organizational decision-mak-
ing processes raised their product awareness and sales. As a result, ProcessABC started
hiring more people and scaling.
Donna was hired by ProcessABC to identify what the software engineering function
required to deliver on their customersʼ demands. At a time, the software engineering
department included three small product Development Teams of up to 10 people per
product. Each team was also implementing Scrum and was sufficiently enabled to collab-
orate with their stakeholders and target customers directly.
ProcessABC demand came from business customers. Therefore, the level of quality and
the speed of delivering new features to the existing products had to improve. However,
the Scrum teams reached their capacity and were unable to extend their scope of work
further.
A few weeks of analysis led Donna to suggest to ProcessABC executives that it was time to
scale the Scrum implementation. While multiple approaches are available, Donna sugges-
ted introducing a concept called Scrum of Scrums where representatives from each Scrum
team come together at every iteration to align.
Three months into the implementation, the Scrum teams reported being more aligned.
Their products also started looking more similar, and people across teams enjoyed work-
ing together. However, the Product Owners were confused about how this approach
would help them scale. After all, the capacity remained the same, and each Product
Owner was responsible for a different product.
What did Donna mix up in the framework? In this unit, you will learn about implementing
and scaling Scrum. By the end, you will be able to recommend the right approach for the
ProcessABC challenge.
98
6.1 Implementation of Scrum in a
Company
Text BoxThe Scrum framework originates from an empirical process, allowing product
Development Teams to continuously “inspect and adapt” their product. This allows Scrum
teams to develop their product in an incremental and iterative approach, collaborate
closely with their stakeholders, and reduce the risk of deviation from their Product Goal Stakeholders
(Schwaber & Sutherland, 2020, p. 7). refers to both internal and
external influences of the
Scrum team, such as the
For Scrum teams to successfully “inspect and adapt,” the Scrum flow includes Scrum customer, sales, market-
events where they plan their work, track their progress, gather stakeholder feedback, and ing, and finance
reflect on how to improve their ways of working. In those events, the Scrum team utilizes
Scrum artifacts, such as the Product Backlog, Sprint Backlog, and the Increment, to con-
tinuously generate a shared understanding of the work to be done. This supports the
Scrum team in planning and refining their work, inspecting progress, and adapting to
changes that might occur throughout the execution (Schwaber & Sutherland, 2020, p. 7)
While each Scrum role contributes to this flow differently, the Scrum team is accountable
as a whole for the success of their product delivery. For example, the Product Owner
ensures that the Development Team has sufficient information about the customerʼs
needs and expectations. The Development Team executes as a cross-functional team to
produce the product increment. Lastly, the Scrum Master supports the Scrum team and
the organization in adopting Scrum (Schwaber & Sutherland, 2020).
The Scrum Guide describes the Scrum flow, events, roles, and artifacts. However, it does
not provide a standard implementation approach in an organization. Thus, Bröse (2020)
suggests the following steps for introducing Scrum in a company.
Provide a Change Reason
Introducing the concept of Sprints allowed the Product Owner to take time off, trusting
the Development Team to execute their clearly aligned goals. Regardless of the starting
point, a company needs to have clear reasons for introducing Scrum. Reasons might
include the desire to support the team in how they plan their work and being able to
respond to unpredictable changing requests (Bröse, 2020). According to Bröse (2020),
there needs to be a clear case that benefits the team. For example, she describes how the
growth in the number of people in her Development Team resulted in a higher scope of
work that needed to be planned better to allow the Development Team to work more
independently.
99
Propose Rather Than Decide
The change to move to Scrum should be a proposal rather than a decision taken for the
team. Hence, the team should buy into implementing Scrum and be convinced to imple-
ment Scrum or not implement it. According to Bröse (2020), the change initiator is recom-
mended to set up a team meeting to discuss the approach with the team. The following
questions should be answered:
• What is the willingness of the team to work in Scrum?

• What could be a suitable Sprint duration?
• How and when would the team like to hold the Scrum events?
• What approach is suitable to determine an initial Sprint capacity?
When people in the team do not have experience in Scrum, the framework needs to be
introduced first as an experiment for the team to try before they can decide. Alternatively,
if the team is familiar with Scrum but has a negative opinion of it, concerns and objections
should be discussed in the meeting. Ideally, this is the place to discuss the implementa-
tion principles and for the team to decide whether they would like to try Scrum again. If
yes, this is also where they discuss how they want to develop their product using the
framework (Bröse, 2020).
Let the Team Decide
After the team voices their concerns, agrees to implement Scrum, and familiarizes them-
selves with the Scrum flow, events, roles, and artifacts, they are ready to detail their Scrum
implementation strategy (Bröse, 2020). According to Bröse (2020), the team should be
clear on the following:
• their level of agreement to implement the Scrum framework and how willing they are to
live the roles, run the events, and work in Sprints
• what their Sprint duration is in weeks and when would they like to start it in the week
• when would they like to hold each Scrum event, including the day, frequency, and dura-
tion of the event
• how would they like to capture and write their Product Backlog items
• what scale would they like to use to measure their capacity and Product Backlog items
estimates
Experience a First Sprint
Once the team familiarizes themselves with the framework and agrees on how they would
like to implement it, they are ready to experience their first Sprint. For the first planning,
Bröse (2020) suggests the Development Team select reference work items and estimate
them on their estimation scale. For example, the newly established Scrum team might
choose user stories as their Product Backlog items and story points for estimating them.
Then they select three typical work items and match them with the story points estima-
tion. Those items would serve as a reference for future estimations.
100
Bröse (2020) also recommends Scrum teams start using a task board and burndown charts
from the first Sprint. This allows the team to track their work, understand their velocity,
and see whether the approach fits them. Ultimately, the best way to implement Scrum is
by doing it (Bröse, 2020).
Another important aspect of introducing Scrum is to start “small” (Patel, 2021, para. 4).
Patel (2021) suggests that companies evaluate first the cultural alignment between the
organization and Agile principles and values. Then select one product or project with a
feasible scope to demonstrate the approach and benefits of implementing Scrum. Also,
depending on the culture, Development Teams might object to short development cycles
and breaking down work items. However, this is part of the learning process, and the
Development Team should be challenged on that.
6.2 Chances, Risks, and Limitations of

Scrum
According to the fifteenth State of Agile Report, 66 percent of the organizations imple-
menting Agile methods implement Scrum. At the same time, respondents reported utiliz-
ing particular Scrum practices: Daily Scrum (87%), Retrospectives (83%), and Sprints or
short iterations (83%). The practices were found useful regardless of the chosen frame-
work (Digital.ai, 2021).
The Scrum framework is gaining popularity. In 2020, 40 percent of the organizations that
participated in the survey selected Scrum as their development approach. However,
implementing Agile methods and practices, such as Scrum, creates significant barriers
that hinder organizations from realizing their value. Some of those challenges include the
struggle to align processes and practices across the organization, the struggle to adopt the
culture and values, change resistance, and growing criticism about the lack of support,
contribution, and sponsorship from management (Digital.ai, 2021).
Implementation Failure of Scrum
According to Isom (2019), there are two common explanations for the implementation fail-
ure of Scrum:
1. Organizations apply the framework wrong.

2. Scrum is not sufficient for what the organization needs.
While the Scrum framework is considered straightforward and suitable for a wide range of
projects and industries (Isom, 2019), these reasons contribute heavily to the organization’s
chance to successfully implement it.
101
Wrong Scrum implementation
Scrum is often implemented in organizations without them fully grasping its values and
Task board principles. For example, Scrum teams might use a task board without familiarizing them-
the Scrum board where selves with its purpose. Instead of keeping it simple and focusing on inspecting their pro-
teams can track the status
and progress of their gress toward the Sprint Goal, Development Teams might use the board to log every small
Sprint Backlog in order to implementation detail, making the task board harder to maintain. It might also become
inspect and adapt their unreadable to non-technical people (Isom, 2019).
Sprint
Development teams require discipline to implement Scrum. Scrum events are time con-
straints and focus on a specific purpose. For example, the Daily Scrum is limited to 15
minutes to allow the Development Team to inspect their daily progress and raise potential
deviations. When events lose their constraints and purpose, people tend to become inat-
tentive and Scrum fails (Isom, 2019).
Product Backlog management is essential in Scrum. The Product Owner’s responsibility is

to continuously order the Product Backlog and scope the work to maximize the delivered
value. Items require the appropriate detail level in alignment with their progress through-
out the Scrum flow. Also, the Development Team needs to collaborate with the Product
Owner to continuously refine the Product Backlog items (Isom, 2019).
A common reason for struggling with Backlog management is the wrong implementation
of the Product Owner role. In Scrum, the Product Owner is also a Scrum team member.
While they have different responsibilities associated with their role, they are considered
equal in the hierarchy and not team managers. However, the Product Owner frequently
understands their role as above the Development Team. Thus, they demand instead of
proposing the work to be done. This leads to Development Teams undermining the Prod-
uct Owner role and blaming each other when the Sprint Goal is not achieved (Pereira,
2020).
Lastly, the understanding of predictability in Scrum teams differs from plan-based devel-
opment approaches. Scrum is designed to increase predictability within the Sprint scope.
However, it does not provide upfront predictability for the entire product development or
project. Nevertheless, stakeholders often misinterpret estimations as constants. There-
fore, when the scope or estimations changes, they are disappointed. This requires Scrum
teams to both educate their stakeholders and continuously challenge their velocity to
meet their stakeholders’ expectations (Isom, 2019).
Scrum is not sufficient
The Scrum framework is not a project management framework. Also, it was not meant as
such. Scrum provides principles to manage scopes for a complex project with changing
requirements, including the flow of communication. However, it leaves vague recommen-
dations on communicating with stakeholders, ranking and ordering the Product Backlog,
and other vital project management aspects (Isom, 2019). Thus, there are situations where
Scrum is either not enough or not what the organization needs.
102
Projects run in Scrum might utilize additional project management layers to support vital
project management aspects. For example:
• Scrum does not provide an approach to describe the project at a high level, including
discussing its benefits, the business case, budget, timeframe, and stakeholders. Project
teams might benefit from creating that upfront to create an understanding of what they
are developing, to whom, and at what cost (Isom, 2019).
• Scrum does not require having a project plan beyond the Product Backlog. However,
project teams might benefit from having a plan to align with their stakeholders’ needs,
expectations, and timelines. That plan can be then inspected and adapted (Isom, 2019).
• Scrum allows for ongoing negotiation and changes to the scope. However, it does not
account for ensuring promised requirements remain part of the plan and avoiding
unplanned work that might exceed the project’s constraints (Isom, 2019). While it is part
of the Product Owner's responsibility, Scrum teams might benefit from utilizing require-
ments metrics and scope change tracking mechanisms.
• Product Owners in Scrum are expected to be respected by the stakeholders (Schwaber
& Sutherland, 2020). However, they might sometimes need to utilize stakeholders’ com-
munication strategies beyond the task board and Sprint Reviews. Stakeholders might
differ in power and interest. Also, not all stakeholders might take part in the Sprint
Review. Thus, project management tools for stakeholder engagement and communica-
tion might be useful for Product Owners (Isom, 2019).
Not what the organization needs
The Scrum framework intends to solve a problem. While Scrum can benefit organizations
in multiple ways, there needs to be a specific reason for the Scrum implementation. How-
ever, some organizations attempt to solve the wrong personnel issue with Scrum. For
example, people are “tired” of their managers or want to shine in the organization by suc-
cessfully implementing Scrum (Viscardi, 2013, p. 250). For organizations to successfully
implement Scrum, they require “motivated, proactive, creative people” that seek
autonomy, challenging work, and want to develop products in such a way. However, it
might not be the right fit if the organization focuses on control and power (Viscardi, 2013, Control
p. 250). In some organizations,
managers are expected to
oversee people and their
Organizations implementing Scrum also need to ask themselves what value they expect to work closely.
see from the implementation. The value needs to be observed and measured (Viscardi,
Power
2013). In some organizations,
the hierarchy also implies
decision-making power.
Lastly, not every problem is complex. Organizations need to ask themselves whether they Managers thus have the
can predict their scope and how much change they are expecting to see in it (Maddox, power to decide what
2021). For example, they could use a sense-making framework, such as the Cynefin Frame- people work on and how
they do their work.
work, to determine the domain’s complexity and whether Scrum fits (Rubin, 2012).
To summarize, when an organization does not see a clear value in implementing Scrum,
their product is not complex, and their people are not interested in it for the right reasons,
Scrum is not a fit.
103
6.3 Scrum of Scrums
Whether Scrum is implemented in one or many teams, the framework and its principles
remain the same. However, for Scrum implementation to be successful, individuals in the
Scrum teams must follow the flow and approach and work on their individual mindset
(Viscardi, 2013).
Scrum might be easy to introduce initially in an organization. However, people might com-
plicate it by creating teams that are too small or too large, not sufficient for the product
they are working on, or require sharing people across teams. Moreover, Scrum does not
provide a standard approach to introducing or creating an environment that supports it,
regardless of whether the implementation is in one or many teams (Viscardi, 2013).
Viscardi (2013) suggests that scaling can be successful if organizations focus on starting
with one team, building an environment where they are motivated, and then introducing
new teams. Nevertheless, according to Spanner (n.d.), this might not be suitable in all
cases. Organizations tend to mix growth in people and scaling. When an organization
attempts to add more independent teams to its structure due to the growth in the number
of people they employ, the Scrum framework might be sufficient. However, when an
organization attempts to add more teams with the intention that those teams collaborate
toward the same objectives, it requires a different approach.
Since the Scrum framework’s official introduction by Sutherland and Schwaber, Suther-
land has continuously shared his experience implementing Scrum in different companies,
including environments with more than one Development Team (Sutherland, 2001).
“SCRUM of SCRUMs” was first introduced in 2001 (Sutherland, 2001, p. 10), followed by the
Scrum at Scale guide published by Sutherland in 2006 to support teams scaling Scrum.
Like Scrum, Scrum of Scrums focuses on scaling the empirical approach to product devel-
opment in teams collaborating on producing the same product. It focuses on the same
Scrum pillars of transparency, inspection, and adaption across multiple teams (Spanner,
n.d.).
Scrum at Scale, on the other hand, aims to provide a development approach that can be
scaled for an entire organization where Scrum of Scrum serves as the product develop-
ment approach. Sutherland (2006) suggests that the principles of Scrum of Scale can
result in the organization as a whole becoming more adaptive. He suggested that those
principles can be used across industries, governance, and products. If an organization is
not yet working in Scrum, implementing Scrum is its first step.
Sutherland (2006) suggests that the same culture required to successfully implement
Scrum in a Development Team is also required at scale. A value-driven culture is described
as a culture of “openness, courage, focus, respect, and commitment” (p. 6). Thus, people
are expected to be open to experimenting, to dare to speak up, to center their attention on
value creation, to respect each other as individuals, and to follow through with their obli-
gations (Sutherland, 2006).
104
Scrum of Scrums Approach
The foundation of the Scrum at Scale guide is in the Scrum of Scrums’ scaling approach.
Scrum of Scrums refers to the coordinating team responsible for a group of multiple
Scrum teams together to release an integrated product and coordinate their work (Suther-
land, 2006).
The Scrum of Scrums team similarly operates in Scrum to the grouped Scrum teams. They
are responsible for integrating the product increments produced by the teams and all
activities required to successfully deliver the integrated product to the customer (Suther-
land, 2006).
Like Scrum, a Scrum of Scrums should be enabled to deliver the product produced by the
group of Scrum teams independently. Thus, each Scrum team is expected to implement
Scrum and produce a product increment in the same cadence. Also, all Scrum roles should
exist in all teams: the Product Owner, Scrum Master, and the Development Team. The
teams should focus on improving their workflow to deliver their increment while main-
taining a viable development pace, and advance their ability to gather and act on cus-
tomer feedback (Sutherland, 2006).
Sutherland (2006) also suggests that the Scrum of Scrums approach can be scaled on its
own by grouping Scrum of Scrums teams similarly to grouping Scrum teams. In this case,
multiple Scrum of Scrums teams requiring coordination would be coordinated by a Scrum
of Scrums team. This is a linear scaling approach and can be repeated to any size neces-
sary by the organization. Unlike in Scrum, Sutherland (2006) suggests that each team size
include four to five Development Team members instead of up to nine.
105
Figure 23: Scrum of Scrums Grouping
Source: Bar Schwartz (2022), based on Sutherland (2006)
Scrum of Scrums Roles and Events
While the Scrum teams implement the Scrum framework and follow the Scrum events as
described in the Scrum Guide (Schwaber & Sutherland, 2020), the Scrum of Scrums team
also implements the same Scrum events from a scaled perspective. For example, the
Scrum of Scrums Planning is focused on clarification of what should be the product incre-
ment produced by the Scrum teams.
106
Scrum of Scrums roles are introduced to facilitate the scaled Scrum events and coordinate
the work across the different Scrum teams: the chief Product Owner and the Scrum of
Scrums Master. Also, to support these scaled roles, two organizational-wide teams are cre-
ated: the Executive MetaScrum (EMS) and the Executive Action Team (EAT) (Sutherland,
2006).
EMS scales the Product Owner role activities across the organization by bringing together
the Chief Product Owner, the Product Owners group, the executives, and key stakeholders.
This group of individuals serves as a leadership team to determine the strategic priorities
of the product and align them with the organizational strategic priorities. The Chief Prod-
uct Owner facilitates them.
EAT scales the Scrum Master role activities across the organization by bringing together
the Scrum Masters group. This group of individuals serves as both the change and execu-
tion team for the organization. Thus, they are responsible for the organization’s ability to
adopt Scrum. Also, as they operate in Scrum, they are expected to nominate a Product
Owner and Scrum Master in their team, create and maintain the Scrum artifacts (e.g., a
Backlog), and run the Scrum events.
In Scrum of Scrums, the Scrum teams share the Product Backlog. Thus, the Chief Product
Owner facilitates planning, prioritization, and refinements activities with the Product
Owners and across the teams to ensure the alignment and coordination of the cascaded
Scrum team’s work. The Scrum of Scrums Master focuses on overseeing, coordinating, and
resolving impediments together with the Scrum Masters in the teams, to ensure the over-
arching execution and delivery (Sutherland, 2006).
Sutherland (2006) also suggests synchronizing Scrum of Scrums events with the Scrum
teams’ cadences. For example, EMS and EAT should meet every Sprint, and Scrum Masters
should meet in a larger Scrum of Scrums Daily Scrum every day after the Scrum team’s
Daily Scrum.
Lastly, Product Owners and Scrum Masters are expected to align by utilizing the shared
product and release feedback. Different metrics should be introduced to support that, for
example, value delivery metrics (e.g., “business value per unit of team effort”) and produc-
tivity metrics (e.g., “change in amount of working product delivered per Sprint”) Reflec-
tion on these metrics, validating product and release assumptions, customer usage, and
emerging customer request, support bringing the Scrum teams together to align on the
product purpose and goal (Sutherland, 2006, p. 17).
107
6.4 The Nexus Framework for Scaling
Scrum
Scrum of Scrums, as implemented as part of the Scrum at Scale approach, attempts to
scale the Scrum implementation across an entire organization (Sutherland, 2006). Simi-
larly, Schwaber (Scrum.org, 2021) also proposes an approach to scaling Scrum, focusing
on the product development of one product rather than the organization as a whole.
Originally introduced by Schwaber in 2015, the Nexus approach groups three to nine
Scrum teams in the same Scrum flow to deliver the same product. Thus, like Scrum of
Scrums, the Scrum teams share their Sprint events. However, Nexus introduces an imple-
mentation approach to execute shared Sprint events: Nexus events.
Nexus Approach
Nexus is described as utilizing one Scrum flow with one Product Owner and one Product
Backlog. The Development Teams within the framework execute utilizing this one Product
Backlog. As a result, the extension to the Scrum framework is described in the Nexus
Guide as “minimal” (Scrum.org, 2021, p. 4).
Nexus attempts to offer a product and communication structure to support Development

Teams dependent on each other to integrate their product, resolve dependencies, and
work collaboratively toward delivering a shared and singular Sprint Goal. To accommo-
date this, the Nexus flow aligns with the Scrum flow. The scaling is enabled by extending
existing Scrum accountabilities, events, and artifacts (Scrum.org, 2021).
Figure 24: The “Nexus” Flow
Source: Bar Schwartz (2022), based on Scrum.org (2021).
108
Nexus Roles and Events
Nexus extends the Product Owner role beyond one team to the entire Nexus structure. As
a result, Development Teams in Nexus share a Product Owner, a Product Backlog, Sprint
Planning, Daily Scrum, and Sprint Review (Scrum.org, 2021).
The Nexus integration team is created to support this change. The team consists of the
Product Owner, a Scrum Master, and other Nexus integration team members. The Scrum
Master in the integration team might also have Scrum Master responsibilities in one or
more of the Scrum teams as part of the Nexus (Scrum.org, 2021).
The shared Product Backlog is the singular artifact to capture the work to be done to
deliver the Product Goal. Thus, it is continuously refined by the Scrum teams in a cross-
team refinement. Hence, the Product Owner works together with the different Scrum
teams to refine and surface dependencies across teams. Also, refinement might include
slicing the work in ways that allow effective execution across the Scrum teams (Scrum.org,
2021).
The purpose of Nexus Sprint Planning is to generate a shared understanding of the shared
Sprint Goal, including creating a Nexus Sprint Backlog and Nexus Sprint Goal that sup-
ports the Scrum teams in tracking their progress throughout the Sprint itself. Further-
more, the Scrum teams each create their own Sprint Backlog and Sprint Goal to align with
the Nexus Sprint Backlog and Goal. This enables the Scrum teams to increase the trans-
parency of their interdependent work and raise dependencies and risks early (Scrum.org,
2021).
Each Scrum team attends their Daily Scrum and the Nexus Daily Scrum during the Sprint.
The Daily Scrum plan and insights support recognizing potential deviations and risks to
the Nexus Sprint Goal (Scrum.org, 2021).
The Nexus Sprint Review supports the Scrum teams in gathering and addressing feedback
on the integrated product increment. Like in Scrum, the Scrum teams demonstrate their
work. However, considering the scale environment, the level of details they can share in
that event is limited. Nevertheless, stakeholders in Nexus are expected to contribute to
discussions on the integrated product increment and support shaping future increments
(Scrum.org, 2021).
Lastly, Nexus also introduces a Nexus Sprint Retrospective to inspect and adapt the entire
Nexus. Like in Scrum, the event is the Sprintʼs last event. The Nexus Sprint Retrospective
allows the individuals in the Scrum teams to reflect on different aspects of the Nexus
Sprint, including their teamwork, workflow, supporting tools, and delivery quality. The
input from the different Scrum teams is aggregated to the entire Nexus (Scrum.org, 2021).
109
6.5 Other Approaches
The co-creators of the Scrum framework created Scrum of Scrums and the Nexus frame-
work. Thus, they integrate the core of the Scrum framework with a different perspective
on how Scrum could be scaled. The primary difference between the approaches is the way
work is coordinated:
• Scrum of Scrums creates a new Scrum team. Thus, the Product Backlog is owned by a
Chief Product Owner rather than the individual Product Owners in the team. Similarly,
the Scrum Masters are coordinated by a Scrum of Scrums Master (Sutherland, 2006).
• The Nexus framework limits the number of Scrum teams in the Nexus and creates a new
Nexus integration team to support them. The coordination is done by shaping the
Scrum events to accommodate the scaled approach. Also, there is one Product Owner
(Scrum.org, 2021).
In 2017, Scrum of Scrums was considered the third most popular scaled framework, while
the Nexus framework struggled to gain popularity (Pinoystudium, 2017). In 2020, however,
Scrum of Scrumsʼ popularity decreased as more organizations preferred other approaches
such as Large Scale Scrum (LeSS) and Scaled Agile Framework (SAFe).
Large Scale Scrum (LeSS)
LeSS, also known as Large Scale Scrum, was created in 2005 by Craig Larman and Bas
Vodde at Nokia Siemens Network. Like Scrum of Scrums, LeSS intended to scale Scrum to
the entire organization by enabling multiple Scrum teams to work together on one Prod-
uct Backlog (Pinoystudium, 2017). LeSS focuses on reducing change costs. According to
Coleman (2018), LeSS supports an organizationʼs cost of change by encouraging organiza-
tions to learn fast from taking small risks. Hence, learnings and experiments are at the
core of the framework.
Like the Nexus framework, LeSS limits the number of Scrum teams to two to eight teams.
The second version of LeSS, called LeSS Huge, is adapted to support more than eight
teams (Pinoystudium, 2017).
Scrum teams in the LeSS frameworks also have one Product Owner and one Product Back-
log. However, in the LeSS Huge approach, each Scrum team also has a Product Owner, the
Area Product Owner responsible for the team-level Product Backlog (The LeSS Company
B.V., n.d.). Thus, LeSS includes concepts from both Scrum of Scrums and the Nexus frame-
work. Moreover, LeSS and Nexus are rather sibling frameworks, where Nexus focuses on
product development and LeSS extends to the entire organization to Scrum of Scrums
(Coleman, 2018).
110
Scaled Agile Framework (SAFe)
SAFe, also known as Scaled Agile Framework, was created in 2011 by Dean Leffingwell.
Unlike LeSS, Scrum of Scrums, and the Nexus framework, SAFe does not claim to be a
scaled Scrum approach. It is an organization-wide delivery approach for complex and
complicated products, focusing on the speed of delivering those solutions to customers in
a scaled environment (Pinoystudium, 2017).
SAFe does not scale Scrum, it scales Agile. It focuses on introducing a complementary
operating approach to product delivery that does not disrupt the existing organizational
structure and processes. Thus, compared to Scrum of Scrums, it is less tailored to the
organization and does not focus on scaling the Scrum empirical approach and culture
(Johnson, 2021).
SAFe introduces four levels: portfolio, solution, program, and team. Like Scrum of Scrums,
teams that work on the same product, a program, are grouped together. The program
structure is also called a Release Train, as all teams collaborate toward the same release
(Knaster, 2022).
Like Scrum of Scrums, SAFe introduces program-level roles for coordination, such as the
Product Manager, Release Train Engineer, and System Architect. The Product Manager acts
as the coordinator for the Product Owners in the teams, the Release Train Engineer acts as
the coordinator for the Scrum Masters, and the System Architect is responsible for the
technical product at scale (Knaster, 2022).
Teams on the Release Train share the same Sprint cadence called iterations. Every four to
six iterations, they come together in a scaled event called the Program Increment Planning
(Knaster, 2022). This approach is also similar to Scrum of Scrums. However, in Scrum of
Scrums, Scrum teams plan at scale at every iteration (Sutherland, 2006).
Organizations with multiple programs might benefit from introducing a Portfolio level
where programs can be aligned and coordinated. In addition, one Release Train might not
be sufficient for certain products. Thus, a solution layer is also implemented to coordinate
multiple interdependent programs toward one customer solution (Knaster, 2022).
111
SAFe is more prescriptive than Scrum of Scrums. Thus, it has gained popularity in large
enterprises (Pinoystudium, 2017). However, it is vital to remember that SAFe does not
focus on scaling the Scrum framework. Teams within the SAFe framework are allowed to
work in other development approaches as long as they align with other teams on a regular
cadence.
SUMMARY
The Scrum framework originates from empiricism, supporting a product
team to inspect and adapt utilizing learning and feedback loops. While
the Scrum Guide provides guidance on the roles, events, and artifacts
that support a team implementing Scrum, it does not provide a one-
implementation approach to introducing Scrum in a company.
Recommended approaches to implementing Scrum include the follow-

ing four primary steps: provide a change reason, propose the implemen-
tation idea, let the team decide on their tailored approach, and experi-
ence the first Sprint.
Organizations might fail to implement Scrum due to the wrong imple-

mentation of the framework and attempting to implement it in a project
context when Scrum is not enough. Also, at times, Scrum might not be
the right solution for the organization. Thus, when starting with Scrum,
starting small before scaling up is recommended.
Scaling Scrum requires an organization to invest in creating an environ-

ment that enables working in Scrum. However, scaling Scrum is not
always needed. An organization needs to evaluate the required interac-
tion between teams.
The co-creators of Scrum suggest two scaling approaches to support

teams working together toward the same product: Scrum of Scrums and
the Nexus framework. Scrum of Scrums focuses on coordinating multi-
ple Scrum teams by grouping them together and creating a coordination
team called the Scrum of Scrums. Alternatively, the Nexus framework
attempts to deviate minimally from the Scrum framework by having one
Product Owner and one Product Backlog shared by three to nine Scrum
teams.
Other scaling approaches include LeSS and SAFe. LeSS is considered a

sibling of Nexus extended to the organization. SAFe focuses on scaling
Agile rather than Scrum. Considering scaling Scrum often requires
112
changing the organizational structure and processes, SAFe is considered
a more popular scaling approach, as it allows organizations to maintain
their structure.
113
BACKMATTER
LIST OF REFERENCES
Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile software development
methods: Review and analysis. VTT Publication 478.
Ageling, W.-J. (2018, August 5). “The Product Owner is not allowed to attend our Sprint Ret-
rospective.” Medium. Retrieved July 17, 2022, from https://medium.com/serious-scru
m/the-product-owner-is-not-allowed-to-attend-our-Sprint-retrospective-d064672446
94
Ageling, W. (2019, December 10). Scrum — Who determines the Sprint Goal? Serious Scrum.
Medium. Retrieved July 15, 2022, from https://medium.com/serious-scrum/scrum-wh
o-determines-the-Sprint-goal-497dd3238b6
Agile Alliance. (2021, March 26). Sprint planning. Retrieved July 15, 2022, from https://www
.agilealliance.org/glossary/Sprint-planning
Aime, F., Humphrey, S., DeRue, D. S., & Paul, J. B. (2014). The riddle of heterarchy: Power
transitions in cross-functional teams. Academy of Management Journal, 57(2), 327–
352. https://doi.org/10.5465/amj.2011.0756
Alblas, J. (2018, November 13). Scrum from the trenches: Product Backlog refinement is a
Scrum Team responsibility. Scrum.Org. Retrieved July 14, 2022, from https://www.scru
m.org/resources/blog/scrum-trenches-product-backlog-refinement-scrum-team-resp
onsibility
Alfonso, A. (2018, July 6). The 4 Scrum ceremonies made simple: A quick guide to Scrum
meetings. Medium. Retrieved July 17, 2022, from https://medium.com/ideas-by-crem
a/the-4-scrum-ceremonies-made-simple-a-quick-guide-to-scrum-meetings-ea91fe60
4d88
Arunagiri, P., & Gnanavel Babu, A. (2013). Review on Reduction of Delay in manufacturing
process using Lean six sigma (LSS) systems. International Journal of Scientific and
Research Publications, 3(2), 1–4. https://www.ijsrp.org/research-paper-0213/ijsrp-p14
117.pdf
Aston, B. (2022, January 2). 10 Best online Scrum tools for 2021. The Digital Project Man-
ager. Retrieved August 18, 2022, from https://thedigitalprojectmanager.com/tools/bes
t-scrum-tools/#overviews
Atlassian. (n.d.). Jira: Issue & project tracking software. Retrieved August 15, 2022, from htt
ps://www.atlassian.com/software/jira
116
Beck, K., Beedle, M., Bennekum, A. V., Cockburn, A., Cunningham, W., Fowler, M., Grenning,
J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S.,
Schwaber, K., Sutherland, J., & Thomas, D. (2001a, February). Manifesto for Agile soft-
ware development. Agilemanifesto.Org. Retrieved May 29, 2022, from https://agileman
ifesto.org/
Beck, K., Beedle, M., Bennekum, A. V., Cockburn, A., Cunningham, W., Fowler, M., Grenning,
J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S.,
Schwaber, K., Sutherland, J., & Thomas, D. (2001b, February). Principles behind the
Agile Manifesto. Retrieved July 5, 2022, from https://agilemanifesto.org/principles.htm
l
Blinov, D. (2018, March 27). Daily Scrum: Stand-up meeting vs Status meeting — what’s the
difference? Medium. Retrieved July 17, 2022, from https://dblinov.medium.com/daily-
scrum-stand-up-meeting-vs-status-meeting-whats-the-difference-8e3921346845
Bröse, I. (2020, October 17). How to introduce Scrum to a team - Agile insider. Medium.
Retrieved August 19, 2022, from https://medium.com/agileinsider/how-to-introduce-s
crum-to-a-team-2db9794e14aa
Caroli, P., & Caetano Coimbra, T. (n.d.). Timeline driven by feelings. Funretrospectives.
Retrieved July 17, 2022, from https://www.funretrospectives.com/timeline-driven-by-f
eelings/
Chec, M. (2020, August 2). The story of user stories: UX Collective. Medium. Retrieved July
14, 2022, from https://uxdesign.cc/the-story-of-user-stories-part-1-e1c8e4995f7f
Cohn, M. (1998). Planning Poker: An Agile estimating and planning technique. Mountain
Goat Software. Retrieved July 15, 2022, from https://www.mountaingoatsoftware.com
/agile/planning-poker
Coleman, J. (2018, November 5). How do Nexus and LeSS Differ? Scrum.Org. Retrieved
August 21, 2022, from https://www.scrum.org/resources/blog/how-do-nexus-and-less
-differ
Cule, P., Schmidt, R., Lyytinen, K., & Keil, M. (2000). Strategies for heading off is project fail-
ure. Information Systems Management, 17(2), 61–69. https://doi.org/10.1201/1078/431
91.17.2.20000301/31229.8
Deneir, S. (2021a, May 27). Sprint Planning and Transparency: Back to the foundations of the
Scrum framework (01). Scrum.Org. Retrieved July 16, 2022, from https://www.scrum.or
g/resources/blog/Sprint-planning-and-transparency-back-foundations-scrum-frame
work-01
Deneir, S. (2021b, June 3). The Daily Scrum and Transparency: Back to the foundations of
the Scrum framework (02). Scrum.Org. Retrieved July 16, 2022, from https://www.scru
m.org/resources/blog/daily-scrum-and-transparency-back-foundations-scrum-frame
work-02
117
Deneir, S. (2021c, June 10). The Sprint Review and Transparency: Back to the foundations of
the Scrum framework (03). Scrum.Org. Retrieved July 16, 2022, from https://www.scru
m.org/resources/blog/Sprint-review-and-transparency-back-foundations-scrum-fram
ework-03
Deneir, S. (2021d, June 11). The Sprint Retrospective and transparency: Back to the founda-
tions of the Scrum framework (04). Scrum.Org. Retrieved July 16, 2022, from https://w
ww.scrum.org/resources/blog/Sprint-retrospective-and-transparency-back-foundatio
ns-scrum-framework-04
Deneir, S. (2021e, June 18). The Sprint and transparency: Back to the foundations of the
Scrum framework (05). Scrum.Org. Retrieved July 16, 2022, from https://www.scrum.or
g/resources/blog/Sprint-and-transparency-back-foundations-scrum-framework-05
Deneir, S. (2021f, August 5). How Sprint Planning supports inspection: Back to the founda-
ww.scrum.org/resources/blog/how-Sprint-planning-supports-inspection-back-found
ations-scrum-framework-12
Deneir, S. (2021g, August 12). How the Daily Scrum supports Inspection: Back to the founda-
ww.scrum.org/resources/blog/how-daily-scrum-supports-inspection-back-foundatio
ns-scrum-framework-13
Deneir, S. (2021h, August 19). How the Sprint Review supports inspection: Back to the foun-
dations of the Scrum framework (14). Scrum.Org. Retrieved July 16, 2022, from https://
www.scrum.org/resources/blog/how-Sprint-review-supports-inspection-back-founda
tions-scrum-framework-14
Deneir, S. (2021i, August 26). How the Sprint Retrospective supports inspection: Back to the
foundations of the Scrum framework (15). Scrum.Org. Retrieved July 16, 2022, from htt
ps://www.scrum.org/resources/blog/how-Sprint-retrospective-supports-inspection-b
ack-foundations-scrum-framework-15
Deneir, S. (2021j, September 2). How the Sprint itself supports inspection: Back to the foun-
www.scrum.org/resources/blog/how-Sprint-itself-supports-inspection-back-foundati
ons-scrum-framework-16
Deneir, S. (2021k, October 28). How Sprint planning supports adaptation: Back to the foun-
www.scrum.org/resources/blog/how-Sprint-planning-supports-adaptation-back-foun
dations-scrum-framework-23
Deneir, S. (2021l, November 4). How the Daily Scrum supports adaptation: Back to the foun-
www.scrum.org/resources/blog/how-daily-scrum-supports-adaptation-back-foundati
ons-scrum-framework-24
118
Deneir, S. (2021m, November 11). How the Sprint Review supports adaptation: Back to the
ps://www.scrum.org/resources/blog/how-Sprint-review-supports-adaptation-back-fo
undations-scrum-framework-25
Deneir, S. (2021n, November 18). How the Sprint Retrospective supports adaptation: Back
to the foundations of the Scrum framework (26). Scrum.Org. Retrieved July 16, 2022,
from https://www.scrum.org/resources/blog/how-Sprint-retrospective-supports-ada
ptation-back-foundations-scrum-framework-26
Deneir, S. (2021o, November 25). How the Sprint itself supports adaptation: Back to the
ps://www.scrum.org/resources/blog/how-Sprint-itself-supports-adaptation-back-fou
ndations-scrum-framework-27
Digital.ai. (2021). 15th Annual State Of Agile Report. Retrieved August 19, 2022, from https:/
/digital.ai/resource-center/analyst-reports/state-of-agile-report
Doshi, P. (2018, April 17). Agile metrics: Velocity. Scrum.Org. Retrieved July 15, 2022, from h
ttps://www.scrum.org/resources/blog/agile-metrics-velocity
Dupret, K., & Pultz, S. (2022). People as our most important asset: A critical exploration of
agility and employee commitment. Project Management Journal, 53(3), 219–235. https
://doi.org/10.1177/87569728221077013
Everett, J. (2021, October 19). Practical Fibonacci: A beginner’s guide to relative sizing.
Scrum.Org. Retrieved July 15, 2022, from https://www.scrum.org/resources/blog/prac
tical-fibonacci-beginners-guide-relative-sizing
Extreme programming. (2022, June 9). In Wikipedia. https://en.wikipedia.org/wiki/Extreme

_programming
Fibonacci number. (2022, July 26). In Wikipedia. Retrieved August 9, 2022, from https://en.
wikipedia.org/wiki/Fibonacci_number
Fuzzy number. (2022, June 11). In Wikipedia. Retrieved August 9, 2022, from https://en.wiki
pedia.org/wiki/Fuzzy_number
Ghosh, S., Forrest, D., DiNetta, T., Wolfe, B., & Lambert, D. C. (2015). Enhance PMBOK® by
Comparing it with P2M, ICB, PRINCE2®, APM and Scrum Project Management Stand-
ards. PM World Journal, IV(IX), 1–75. http://www.pmworldtoday.net
Glass, R. L. (2001). Agile versus traditional: Make love, not war! Cutter IT Journal, 14(12),
12–18. https://www.cutter.com/article/agile-versus-traditional-make-love-not-war-40
8276
119
Gorzeń-Mitka, I., & Okręglicka, M. (2014). Improving decision making in complexity envi-
ronment. Procedia Economics and Finance, 16, 402–409. https://doi.org/10.1016/s2212
-5671(14)00819-3
Gralha, C., Pereira, R., Goulao, M., & Araujo, J. (2021). On the impact of using different tem-
plates on creating and understanding user stories. 2021 IEEE 29th International
Requirements Engineering Conference (RE), 209–220. https://doi.org/10.1109/re51729.
2021.00026
Guinness, H. (2022, May 12). The 5 best online whiteboards in 2022. Zapier. Retrieved
August 18, 2022, from https://zapier.com/blog/best-online-whiteboard/
Hectorhjure, H. (2021, December 12). Scrum toolkit: Retrospective - Hectorhjure. Medium.

Retrieved August 23, 2022, from https://medium.com/@hectorhjure/scrum-toolkit-ret
rospective-1a8d7334d97a
Highsmith, J. (2002). Agile software development ecosystems. Addison-Wesley Professio-

nal.
Hohl, P., Klünder, J., van Bennekum, A., Lockard, R., Gifford, J., Münch, J., Stupperich, M., &
Schneider, K. (2018). Back to the future: Origins and directions of the “Agile Manifesto”
– views of the originators. Journal of Software Engineering Research and Development,
6(1). https://doi.org/10.1186/s40411-018-0059-z
Holtzhausen, N., & de Klerk, J. J. (2018). Servant leadership and the Scrum team’s effec-
tiveness. Leadership & Organization Development Journal, 39(7), 873–882. https://doi.o
rg/10.1108/lodj-05-2018-0193
Hron, M., & Obwegeser, N. (2022). Why and how is Scrum being adapted in practice: A sys-
tematic review. Journal of Systems and Software, 183, Article 111110. https://doi.org/1
0.1016/j.jss.2021.111110
Iqbal, M. (2021, August 4). Ideas for Scrum’s Sprint Retrospective Event. Scrum.Org.
Retrieved July 17, 2022, from https://www.scrum.org/resources/blog/ideas-scrums-S
print-retrospective-event
Iqbal, M. (2022, February 23). Product Backlog refinement: How far is too far? Scrum.Org.
Retrieved July 14, 2022, from https://www.scrum.org/resources/blog/product-backlo
g-refinement-how-far-too-far
Isom, E. (2019, August 1). Why Scrum fails: The 2 main reasons. PM Guaranteed™. Retrieved
August 19, 2022, from https://www.pmguaranteed.com/why-scrum-fails-the-2-main-r
easons/
Jeff Patton & Associates. (n.d.). User story mapping: Help your organization focus on suc-
cessful outcomes. Retrieved August 14, 2022, from https://www.jpattonassociates.com
/story-mapping/
120
Jeffries, R. (2001, August 30). Essential XP: Card, conversation, confirmation. Retrieved
August 14, 2022, from https://ronjeffries.com/xprog/articles/expcardconversationconf
irmation/
Jeffries, R. (2019, March 26). Three-C’s revisited. Retrieved August 14, 2022, from https://ro
njeffries.com/articles/019-01ff/3cs-revisited/
Johnson, E. (2021, May 14). SAFe or Scrum@Scale – Which framework is best for you? Int-
land. Retrieved August 21, 2022, from https://content.intland.com/blog/agile/safe/saf
e-or-scrum-at-scale-which-framework-is-best-for-you
Kantola, K., Vanhanen, J., & Tolvanen, J. (2022). Mind the Product Owner: An action
research project into Agile release planning. Information and Software Technology,
147, Article 106900. https://doi.org/10.1016/j.infsof.2022.106900
Knaster, R. (2022, August 17). SAFe 5 for lean enterprises. Scaled Agile Framework.
Retrieved August 21, 2022, from https://www.scaledagileframework.com/
Krebs, J. (2022, March 22). Following through after a Sprint Retrospective. Scrum.Org.
Retrieved July 17, 2022, from https://www.scrum.org/resources/blog/following-throu
gh-after-Sprint-retrospective
Lean thinking. (2022, February 8). In Wikipedia. https://en.wikipedia.org/wiki/Lean_thinki

ng
The LeSS company B.V. (n.d.). Why LeSS? Large Scale Scrum (LeSS). Retrieved August 21,
2022, from https://less.works/less/framework/why-less
Lock, D. (2019). Project management (7th ed.). Routledge.
Lohan, G., Conboy, K., & Lang, M. (2011). Examining customer focus in IT project manage-
ment. Scandinavian Journal of Information Systems, 23(2), 29–58.
Maddox, D. (2021, January 27). Is Scrum the right approach for every problem? Scrum.Org.
Retrieved August 19, 2022, from https://www.scrum.org/resources/blog/scrum-right-a
pproach-every-problem
Mahapatra, N. (2022, June 7). Backlog prioritization. Agile Digest. Retrieved July 15, 2022,
from https://agiledigest.com/backlog-prioritization/
Manuele, J., Shewhart, W. A., & Deming, W. E. (1940). Statistical method from the view-
point of quality control. Journal of the American Statistical Association, 35(210), 426–
427. https://doi.org/10.2307/2278733
Mayer, T. (2009, October 6). Ken and the Scrum Alliance — a very personal perspective. Agile
Anarchy. Retrieved July 5, 2022, from https://agileanarchy.wordpress.com/2009/10/06
/ken-and-the-scrum-alliance/
121
McCauley, R. (2001). Agile development methods poised to upset status quo. ACM SIGCSE
Bulletin, 33(4), 14–15. https://doi.org/10.1145/572139.572150
McMillan, B. (2021, June 4). Circles of improvement. Scrum.Org. Retrieved July 17, 2022,
from https://www.scrum.org/resources/blog/circles-improvement
Mitchell, I. (2017, August 24). Walking through a definition of ready. Scrum.Org. Retrieved
July 14, 2022, from https://www.scrum.org/resources/blog/walking-through-definitio
n-ready
Mkrtchyan, E. (2022, March 30). User stories vs. product requirements. Agile Insider.
Retrieved July 10, 2022, from https://medium.com/agileinsider/user-stories-vs-produc
t-requirements-c37bff0d39b6
Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile
team: A case study of a Scrum project. Information and Software Technology, 52(5),
480–491. https://doi.org/10.1016/j.infsof.2009.11.004
Mountain Goat Software. (n.d.). Scrum Task Board. Retrieved August 15, 2022, from https://
www.mountaingoatsoftware.com/agile/scrum/scrum-tools/task-boards
Nedre, N. (2020, September 29). Scrum Boards vs Kanban: 11 Major Differences. MiroBlog.
Retrieved August 15, 2022, from https://miro.com/blog/scrum-kanban-boards-differe
nces/
Nettleton, C. (2021, December 2). Why the product goal is not the product vision in Scrum.
Applied Frameworks. Retrieved July 10, 2022, from https://appliedframeworks.com/w
hy-the-product-goal-is-not-the-product-vision-in-scrum/
Overeem, B. (2017a, January 21). Scrum myths: Scrum is “meeting heavy.” Scrum.Org.
Retrieved July 15, 2022, from https://www.scrum.org/resources/blog/scrum-myths-sc
rum-meeting-heavy
Overeem, B. (2017b, October 30). Myth 2: The Sprint Backlog can’t change during the Sprint.
Scrum.Org. Retrieved August 14, 2022, from https://www.scrum.org/resources/blog/
myth-2-Sprint-backlog-cant-change-during-Sprint
Overeem, B. (2017c, November 15). Myth 4: In Scrum, the Product Backlog has to consist out
of user stories. Scrum.Org. Retrieved July 14, 2022, from https://www.scrum.org/resou
rces/blog/myth-4-scrum-product-backlog-has-consist-out-user-storie
Ozkan, N., & Kucuk, C. (2016). A systematic approach to project related concepts of Scrum.
Review of International Comparative Management, 17(4), 320–334. https://www.resear
chgate.net/profile/Necmettin-Ozkan/publication/321758187_A_Systematic_Approach
_to_Project_Related_Concepts_of_Scrum/links/5a61f1cca6fdccb61c504e63/A-System
atic-Approach-to-Project-Related-Concepts-of-Scrum.pdf?origin=publication_detail
122
Partogi, J. (2021, August 29). [VLOG] How to express the Product Backlog items as hypothe-
sis. Scrum.Org. Retrieved July 10, 2022, from https://www.scrum.org/resources/blog/
vlog-how-express-product-backlog-items-hypothesis
Patel, O. H. (2021, September 27). Introducing Scrum to your team. Clearly Agile. Retrieved
August 19, 2022, from https://www.clearlyagile.com/agile-blog/introducing-scrum-to-
your-team
Patton, J., & Economy, P. (2014). User story mapping: Discover the whole story, build the
right product. O’Reilly Media.
Pavlichenko, I. (2017, June 5). Sprint Review: Much more than just a demo. Scrum.Org.
Retrieved July 17, 2022, from https://www.scrum.org/resources/blog/Sprint-review-m
uch-more-just-demo
Pereira, D. (2020, September 14). The Product Owner is part of the Scrum Team, not above
them. Medium. Retrieved August 19, 2022, from https://medium.com/serious-scrum/t
he-product-owner-is-part-of-the-scrum-team-not-above-them-982b7ca8fca3
Pinoystudium, V. A. P. B. (2017, December 8). SAFe, LeSS, Nexus or Scrum at Scale? Zentral-
banhoff. Retrieved August 21, 2022, from https://zentralbanhoff.wordpress.com/2017/
08/24/safe-less-nexus-or-scrum-at-scale/
Planning Poker®. (2022, March 31). PlanningPoker.com: Estimates made easy, Sprints made
simple. PlanningPoker.Com. Retrieved August 18, 2022, from https://www.planningpo
ker.com/
Randel, A. E., & Jaussi, K. S. (2003). Functional background identity, diversity, and individ-
ual performance in cross-functional teams. Academy of Management Journal, 46(6),
763–774. https://journals.aom.org/doi/abs/10.5465/30040667
Reetro. (2021). Online retrospective tool. Reetro. Retrieved August 18, 2022, from https://re
etro.io/
Reindl, S. (2014, December 4). Agile is constant change. Scrum.Org. Retrieved July 15,
2022, from https://www.scrum.org/resources/blog/agile-constant-change
Rigby, D., Sutherland, J., & Takeuchi, H. (2021, August 27). The secret history of Agile inno-
vation. Harvard Business Review. Retrieved May 29, 2022, from https://hbr.org/2016/04
/the-secret-history-of-agile-innovation
Rola, P., & Kuchta, D. (2019). Application of fuzzy sets to the expert estimation of Scrum-
based projects. Symmetry, 11(8), Article 1032. https://doi.org/10.3390/sym11081032
Rubin, K. (2012). Essential Scrum: A practical guide to the most popular Agile process. Addi-
son-Wesley Professional.
123
Schuurman, R. (2017, May 22). Scrum Events — Sprint Review. Medium. Retrieved July 17,
2022, from https://medium.com/the-value-maximizers/scrum-events-Sprint-review-a
40f79afe764
Schwaber, K. (1997). SCRUM development process. Business Object Design and Implemen-
tation (pp. 117–134). https://doi.org/10.1007/978-1-4471-0947-1_11
Schwaber, K. (2004). Agile project management with Scrum. Microsoft Press.
Schwaber, K., & Beedle, M. (2001). Agile software development with Scrum. Pearson.
Schwaber, K., & Sutherland, J. (2020, November). Scrum Guide. Scrumguides.Org.

Retrieved May 29, 2022, from https://scrumguides.org/scrum-guide.html
Scrum Alliance. (n.d.). What Is Scrum: A guide to the most popular Agile framework.
Retrieved July 5, 2022, from https://www.scrumalliance.org/about-scrum
Scrum.org. (2021). The Nexus™ Guide. Retrieved August 19, 2022, from https://www.scrum.
org/resources/nexus-guide
Scrum.org. (n.d.-a). Ordered not prioritized. Retrieved July 15, 2022, from https://www.scru
m.org/resources/ordered-not-prioritized
Scrum.org. (n.d.-b). The Scrum Framework Poster. Retrieved July 15, 2022, from https://ww
w.scrum.org/resources/scrum-framework-poster
Scrum.org. (n.d.-c). What is a Daily Scrum? Retrieved July 17, 2022, from https://www.scru
m.org/resources/what-is-a-daily-scrum
Scrum.org. (n.d.-d). What is a Product Backlog? Retrieved July 10, 2022, from https://
www.scrum.org/resources/what-is-a-product-backlog
Scrum.org. (n.d.-e). What is Scrum? Retrieved July 5, 2022, from https://www.scrum.org/re

sources/what-is-scrum
SeaLights. (2020, December 17). The Sprint Goal: Why it is critical and how to get it right.
Retrieved July 15, 2022, from https://www.sealights.io/Sprint-velocity/the-Sprint-goal
-why-it-is-critical-and-how-to-get-it-right/
Sithambaram, J., Hairul Nizam Bin Md Nasir, M., & Ahmad, R. (2021). A compilation of fac-
tors associated to the governance and management of Agile projects: A systematic lit-
erature review. Malaysian Journal of Computer Science, 34(3), 266–307. https://doi.org
/10.22452/mjcs.vol34no3.4
Snowden, D. (2000). Cynefin, a sense of time and place: An ecological approach to sense
making and learning in formal and informal communities. In C. Despres & D. Chauvel
(Eds.), Knowledge horizons: The present and the promise of knowledge management.
Butterworth Heinemann.
124
Snowden, D., & Boone, M. E. (2007). A leader’s framework for decision making. Harvard
Business Review, 85, 68–76. https://hbr.org/2007/11/a-leaders-framework-for-decision
-making
Spanner, C. (n.d.). Scrum of scrums. Atlassian. Retrieved August 19, 2022, from https://ww
w.atlassian.com/agile/scrum/scrum-of-scrums
Spiegler, S. V., Graziotin, D., Heinecke, C., & Wagner, S. (2020). A quantitative exploration of
the 9-factor theory: Distribution of leadership roles between Scrum master and Agile
Team. Lecture Notes in Business Information Processing, 162–177. https://doi.org/10.10
07/978-3-030-49392-9_11
Spiegler, S. V., Heinecke, C., & Wagner, S. (2019). Leadership gap in Agile Teams: How
teams and Scrum Masters mature. Lecture Notes in Business Information Processing,
37–52. https://doi.org/10.1007/978-3-030-19034-7_3
The Standish Group. (1994). The CHAOS Report. Retrieved July 3, 2022, from https://www.s
tandishgroup.com/sample_research_files/chaos_report_1994.pdf
Sutherland, J. (2001). Agile can scale: Inventing and reinventing SCRUM in five companies.
Cutter IT Journal, 14(12), 5–11. http://jeffsutherland.com/papers/scrum/Sutherland20
01AgileCanScaleCutter.pdf
Sutherland, J. (2006). The Scrum@Scale Guide. Scrum@Scale Framework. Retrieved

August 19, 2022, from https://www.scrumatscale.com/scrum-at-scale-guide/
Sverrisdottir, H. S., Ingason, H. T., & Jonasson, H. I. (2014). The role of the Product Owner
in Scrum-comparison between theory and practices. Procedia: Social and Behavioral
Sciences, 119, 257–267. https://doi.org/10.1016/j.sbspro.2014.03.030
Takeuchi, H., & Nonaka, I. (2014, August 1). The new new product development game. Har-
vard Business Review. Retrieved May 29, 2022, from https://hbr.org/1986/01/the-new-
new-product-development-game
Team Inovector. (2022, April 29). Iterative And incremental development. Inovector.Com.
Retrieved July 3, 2022, from https://inovector.com/blog/iterative-and-incremental-de
velopment
Toyota. (2022, May 30). In Wikipedia. https://en.wikipedia.org/wiki/Toyota
Trello. (n.d.). Manage your teams projects from anywhere. https://trello.com/
Uhl-Bien, M., Marion, R., & McKelvey, B. (2007). Complexity leadership theory: Shifting
leadership from the industrial age to the knowledge era. The Leadership Quarterly,
18(4), 298–318. https://doi.org/10.1016/j.leaqua.2007.04.002
125
Unger‐Windeler, C., Klünder, J. A., Reuscher, T., & Schneider, K. (2020). Are Product Owners
communicators? A multi‐method research approach to provide a more comprehen-
sive picture of Product Owners in practice. Journal of Software: Evolution and Process,
33(1), 1–23. https://doi.org/10.1002/smr.2311
van der Meulen, M. (2021, October 19). The Future is unknown. Scrum.Org. Retrieved July
15, 2022, from https://www.scrum.org/resources/blog/future-unknown
Viscardi, S. (2013). The Professional ScrumMaster’s handbook: Break the chains of tradi-
tional organization and management. Packt Publishing.
Wake, B. (2003, August 17). INVEST in good Stories, and SMART Tasks. XP123 LLC. Retrieved
July 14, 2022, from https://xp123.com/articles/invest-in-good-stories-and-smart-tasks
/
West, D. (n.d.). Agile Scrum roles. Atlassian. Retrieved August 15, 2022, from https://www.at
lassian.com/agile/scrum/roles#:%7E:text=The%20scrum%20master%20is%20the,to
%20get%20to%20get%20better
Whiteley, A., Pollack, J., & Matous, P. (2021). The origins of Agile and iterative methods.
Journal of Modern Project Management, 8(3), 20–29. https://doi.org/10.19255/JMPM02
502
Wolpers, S. (2022, July 8). Sprint anti-patterns: 27 Examples. Age-of-Product.Com.

Retrieved July 17, 2022, from https://age-of-product.com/Sprint-anti-patterns/
Wysocki, R. K. (2019). Effective project management: Traditional, agile, extreme, hybrid (8th
ed.). Wiley.
zehengl. (2016, January 26). Agile Scrum Note 08: Estimation. Retrieved July 15, 2022, from
https://zehengl.github.io/agile-scrum-notes-08/
Zverugo, L. (2018, June 11). How Sprint Backlog differs from Product Backlog. PMWorldNet-
work. Retrieved July 10, 2022, from https://pmworldnetwork.com/product-managem
ent/the-difference-between-Sprint-backlog-and-product-backlog/
126
LIST OF TABLES AND
FIGURES
Figure 1: Linear Versus Incremental and Iterative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 2: Twelve Agile Principles Behind the Agile Manifesto . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 3: Project-Driven Versus Process-Driven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 4: The Scrum Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 5: The Cynefin Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 1: Approaches to Each Cynefin Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 6: Ordered Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 7: From Product Backlog to Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 8: Relative Sizing With a Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 9: Planning Poker in a Nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 10: Velocity Chart of Three Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 11: The Scrum Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Table 2: Scrum Events and Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 12: Daily Scrum in a Nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Figure 13: Sprint Review in a Nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figure 14: Sprint Retrospective in a Nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 15: Speedboat Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 16: Persona Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 17: User Story Map Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Table 3: Typical Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
127
Figure 18: The Task Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figure 19: Fixed-Scope-Release Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 20: Fixed-Scope-Release Burnup Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 21: Sprint Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 22: Sprint Burnup Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figure 23: Scrum of Scrums Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Figure 24: The “Nexus” Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
128
IU Internationale Hochschule GmbH
IU International University of Applied Sciences
Juri-Gagarin-Ring 152
D-99084 Erfurt
Mailing Address
Albert-Proeller-Straße 15-19
D-86675 Buchdorf
media@iu.org
www.iu.org
Help & Contacts (FAQ)

On myCampus you can always find answers
to questions concerning your studies.

001-2022-1129 DLMPREEPMS01 Course Book

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

001-2022-1129 DLMPREEPMS01 Course Book

Uploaded by

Copyright:

Available Formats

PROCESS MANAGEMENT

© 2022 IU Internationale Hochschule GmbH

1.1 The Birth of Scrum – How and Why it All Began . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 The Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1 Principles of a Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1 The Scrum Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1 Requirements and User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.1 Implementation of Scrum in a Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Schwaber, K. (2004). Agile project management with Scrum. Microsoft Press.

Scrum.org. (2021). The NexusTM guide.

On completion of this unit, you will be able to ...

Together, they suggested, these characteristics affect an organization’s ability to innovate.

Source: Bar Schwartz (2022).

1.2 The Agile Manifesto and a Change in

1. “Individuals and interactions over processes and tools

Understanding the Agile Manifesto Perspective

Standard IT project management methods include comprehensive documentation for

The change in perspective

Ideally, agility is achieved by developing software in short, rapid cycles, collaboratively

1.3 The Approach of Iterative and

Source: Bar Schwartz (2022).

Figure 4: The Scrum Process

Source: Bar Schwartz (2022).

1. The Development Team’s responsibility is to implement the work increment. Thus, it

1.4 Defining Fields for Scrum and Fields

What Problems Does Agility Solve Best?

This shift also influences leadership and decision-making in organizations. Gorzeń-Mitka

Source: Bar Schwartz (2022), based on Snowden & Boone (2007).

• it consists of multiple parts that interact dynamically with each other.

Cynefin (Welsh for “habitat” or “familiar”) is a sense-making framework to support people

As a sense-making framework, Cynefin suggests that there is no correct answer. According

Problem-solving Development Leadership approach

Simple Best practices Sense-Categorize- Command-and-Con-

Complicated Good practices Sense-Analyze- Democratic

Complex Emerging practices Probe-Sense- Visionary

Chaotic Novel practices Act-Sense-Respond Crisis management

Disorder Unable to judge Unable to judge Unable to judge

Source: Bar Schwartz (2022), based on Snowden & Boone (2007).

Furthermore, Sithambaram et al.’s (2021) review of governance and management factors

Scrum is a process-based, incremental, and iterative development

When considering Scrum for a project, determine its complexity first.

On completion of this unit, you will be able to ...

– explain which roles are in the Scrum framework.

Puzzled by the feedback, PharmaScrum executives reached out to a consultancy special-

2.1 The Development Team

The Scrum Team

Ultimately, commitment and accountability are vital for such an implementation

The Development Team as a Cross-Functional Team

The Development Team as a Self-Organizing Team

According to Moe et al. (2010), it is unrealistic to cluster a group of individuals together

Another aspect of self-organization is the ability of management to let go of their need to

When motivated individuals emerge as a team of cross-functional experts working

2.2 The Product Owner

The Product Owner as a Communicator

Formal business meetings

The Product Owner as a Customer Relationship Manager

According to Unger‐Windeler et al. (2020), relationship management is a crucial success

• supporting them to develop self-organization capabilities.

The Scrum Master also serves the Product Owner by

Lastly, the Scrum Master also serves the entire organization by

• continuously leading, training, and coaching its Scrum adoption.

The Scrum Master as a Change Agent

• method champion. They continuously encourage people to utilize Scrum methods by