Mastering

Professional Scrum
Mastering Professional
Scrum
A Practitioner’s Guide to Overcoming
Challenges and Maximizing the Benefits
of Agility

Stephanie Ockerman
Simon Reindl

Boston • Columbus • New York • San Francisco • Amsterdam • Cape Town

Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City
São Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as
trademarks. Where those designations appear in this book, and the publisher was aware of a trademark
claim, the designations have been printed with initial capital letters or in all capitals.
The authors and publisher have taken care in the preparation of this book, but make no expressed or
implied warranty of any kind and assume no responsibility for errors or omissions. No liability is
assumed for incidental or consequential damages in connection with or arising out of the use of the
information or programs contained herein.
For information about buying this title in bulk quantities, or for special sales opportunities (which may
include electronic versions; custom cover designs; and content particular to your business, training goals,
marketing focus, or branding interests), please contact our corporate sales department at corpsales@
pearsoned.com or (800) 382-3419.
For government sales inquiries, please contact governmentsales@pearsoned.com.
For questions about sales outside the U.S., please contact intlcs@pearson.com.
Visit us on the Web: informit.com/aw
Library of Congress Control Number: 2019945044
Copyright © 2020 Stephanie Ockerman and Simon Reindl
Cover design by Sabrina Love
Cover illustration by Maglyvi/Shutterstock
Cover art Maze licensed from mazegenerator.net
All rights reserved. This publication is protected by copyright, and permission must be obtained from
the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any
form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information
regarding permissions, request forms and the appropriate contacts within the Pearson Education Global
Rights & Permissions Department, please visit www.pearsoned.com/permissions/.
ISBN-13: 978-0-13-484152-6
ISBN-10: 0-13-484152-2
ScoutAutomatedPrintCode
 To the people who show up every day and do the hard work to create more
inclusive, kind, and resilient organizations, communities, and societies. And
to all of the women and allies who have empowered, inspired, and enabled me
on my own leadership journey.
—Stephanie

To my wonderful family, without whose patience this would not have been
possible. To my amazing, supportive, and loving wife, Sarah, and my two
awesome children, Ella and George. Thank you for the joy and laughter and
fresh perspective you bring to my world.
—Simon
This page intentionally left blank
 Contents

Foreword by Ken Schwaber xiii

Foreword by Dave West xvii
Introduction xxi
Acknowledgments xxvii
About the Authors xxix

Chapter 1 Continuously Improving Your Scrum Practice 1

Focus on Seven Key Areas to Improve Your Scrum Practice 2
An Agile Mindset 2
Empiricism Is at the Heart of Scrum 3
Mastering Scrum Means Improving Teamwork 4
Every Scrum Team Must Focus on Improving the Value That
Its Product Delivers 5
Every Strong Team Has a Distinct Team Identity 5
To Improve, Teams Must Hone Their Team Processes 6
The Organization Can Greatly Influence the Team’s Performance 7
Growing Scrum Requires a Team to Improve Other Capabilities 7
Teaching Skills 8
Facilitation Skills 9
Coaching Skills 10
Technical Excellence 10
Servant Leadership 11

vii
Contents

A Process for Continuous Improvement 12

What Hurts the Most? 13
Root Cause Analysis 15
Experiment with Different Approaches 18
Success or Failure? 20
Summary 21
Call to Action 22

Chapter 2 Creating a Strong Team Foundation 23

Forming a Team Identity 23
What Makes a Good Team Member? 24
Who Should Be on a Scrum Team? 27
Development Teams Need to Know About More Than
Just Development 28
How Do Scrum Teams Form Working Agreements? 29
What Does Self-Organization Look Like? 31
Shared Goals 32
Clear Accountability 33
Boundaries 34
How Do Scrum Teams Collaborate? 36
How Do Teams Progress? 42
Characteristics of Productive and Adaptable Teams 46
Summary 47
Call to Action 48

Chapter 3 Delivering “Done” Product Increments 49

What Is a Definition of “Done”? 50
Benefits of a Definition of “Done” 51
How to Create a Definition of “Done” 52
Using Sprint Goals to Get to “Done” 55
Creating Good Sprint Goals 55
Using the Sprint Goal for an Effective Daily Scrum 57
Getting PBIs to “Done” Earlier in the Sprint 58
Limiting Work Items in Progress 62
Measuring and Analyzing Flow 63
Building in Quality from the Beginning 64

viii
 Contents

Automation and “Done” 66

DevOps 68
Code Reviews 68
Quality Metrics 68
Tackling Technical Debt 70
Making Technical Debt Transparent 71
Making Technical Debt “Repayment” Visible 73
Summary 74
Call to Action 74

Chapter 4 Improving Value Delivered 77

What Is Value? 77
Delivering Faster Is a Good Start, But Not Enough 78
Product Value and the Scrum Team 80
Using the Product Vision to Enliven Team Purpose, Focus, and Identity 81
Measuring Value 83
Focusing PBIs on User Outcomes 85
Improving Value Delivered During the Sprint 89
Inspecting and Adapting Based on Feedback 90
Learning as Value 90
Effective Sprint Reviews Include Value Realized 91
Gathering Stakeholder Feedback 91
Summary 92
Call to Action 93

Chapter 5 Improving Planning 95

Planning with a Product Mindset 96
Measuring Success 97
Planning Empirically 98
Creating Alignment 100
Product Backlog Refinement 101
Minimum Viable Product Backlog Refinement 102
Estimation 104
Breaking PBIs Down to Focus on Valuable Outcomes 106
Planning a Sprint 107
How Much Can You Get “Done” in a Sprint? 107
How Much Time Should You Spend on Improving This Sprint? 111

ix
Contents

How Far Ahead to Refine 111

Planning Releases 112
How Large Should a Release Be? 113
How Small Can a Release Be? 113
Summary 113
Call to Action 114

Chapter 6 Helping Scrum Teams Develop and Improve 115

Using the Sprint Retrospective to Uncover Areas for Improvement 115
Identifying and Removing Impediments 118
Tracking Impediments and Quantifying Impacts 121
Tackling Impediments 123
Growing Individual and Team Capabilities 124
Make Time for Continuous Learning and Growth 125
Leverage Knowledge and Experience in the Organization 126
Being an Accountable Scrum Master 127
Measuring the Success of a Scrum Master 129
Effective Scrum Masters Vary Their Approach Based on Context 131
Summary 135
Call to Action 135

Chapter 7 Leveraging the Organization to Improve 137

Organizations Need to Evolve to Succeed 137
Developing People and Teams 138
The Impacts of Performance Reviews and Compensation 139
Individual Career Paths 140
Sourcing Strategies and Team Impacts 141
Distributed Teams 143
Getting Comfortable with Transparency 144
A Culture of Accountability, Not a Culture of Blame 145
Letting Go of (the Illusion of) Control 146
The Real Power of the Iron Triangle 146
Funding Initiatives 148
Scope-Based Estimation 149
Iterative and Incremental Budgeting 150

x
 Contents

“Being Agile” Is Not the Goal 152

Nail It Before You Scale It 153
Summary 154
Call to Action 154

Chapter 8 Conclusion and What’s Next 157

Business Agility Requires Emergent Solutions 157
Call to Action 160

Appendix A A Self-Assessment for Understanding Where You Are 161

Business Agility 161
Effective Empiricism with Scrum 162
Effective Teamwork with Scrum 167
Analysis of Assessment Answers 168

Appendix B Common Misconceptions About Scrum 169

Scrum Is Not a Methodology or a Governance Process 169
Scrum Is Not a “Silver Bullet” or a Way to Get Developers
to Work Faster 170
The Product Owner’s Main Focus Is Not Documentation
of Requirements 171
The Product Backlog Is Not an Agile Version of a Traditional
Requirements Document 171
The Product Backlog Is Not a List of All Requests 172
The Daily Scrum Is Not a Status Meeting 172
A Sprint Can Be Successful Even When All Planned Sprint
Backlog Items Are Not Completed 173
The Scrum Master Is Not Responsible for Tracking the
Development Team’s Work 173
The Sprint Review Is Not an Acceptance Meeting 173
It Does Not Take a Lot of Preparation to Start Sprinting 174

Index 175

xi
This page intentionally left blank
 Foreword by
K en S chwaber

I created Scrum to improve the way in which I and others develop software.
Scrum has been refined over the last 27 years, mostly through the creation,
publishing, and gentle refinement of the Scrum Guide. Jeff Sutherland (the
coauthor of Scrum) and I posted Scrum, as precisely defined in the Scrum
Guide, online so people can suggest improvements. Over the years, we have
refined Scrum based on these comments, making Scrum easier to use and
understand.

When I first used the phrase “Scrum Master,” many people became confused.
Nobody was mastering Scrum; we were all learning how to use it and how to
augment it with practices and tools so as to improve outcomes and to help
team members use Scrum with proper values, practices, artifacts (“Done”
Increments), and roles—all working together to achieve Scrum’s goals.

The Scrum Master’s job is to help the organization and the Scrum Team use
Scrum properly to improve their ability to deliver value. The Scrum Master
has to help the team members and people who are affected by Scrum (human
resources, finance, etc.) understand how they can operate optimally. Anyone

xiii
Foreword by Ken Schwaber

on the Scrum Team can improve their Scrum mastery; they can become better
at using Scrum and empiricism to achieve better results, to deliver more value,
in complex domains. Anyone can become more professional.

A professional is someone who works for money and follows the rules
established for the profession. Professionals act and work according to
standards, where they exist (e.g., adhering to the rules set forth in the Scrum
Guide). They also embrace and embody a set of ethical principles established
by their profession (e.g., the Scrum values of Focus, Commitment, Openness,
Respect, and Courage).

Sometimes the Scrum professional may be torn between two alternatives. In

these circumstances, the Agile Manifesto provides higher-level guidance:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Scrum professionals do not redefine Scrum itself or “tailor” it to their

organizations; Scrum is Scrum. To create Increments of valuable Product and
reach the desired outcomes, they do add supporting and ancillary practices,
including DevOps, Kanban, and testing, reconciliation, and communication
practices. Practices that distinguish Scrum from other approaches to complex
work include the following:

1. The team organizes work in short cycles.

2. Management doesn’t interrupt the team during a work cycle.
3. The team reports to the client, not to the manager.
4. The team estimates how much time and effort that work will take.
5. The team decides how much work it can do in an iteration.
6. The team decides how to do the iteration’s work.
7. The team measures its own performance.
8. The team defines work goals before each cycle starts.

xiv
 Foreword by Ken Schwaber

9. The team defines work and desired outcomes through a progressively

refined description of outcomes (called the Product Backlog).
10. The team works to systematically and continuously improve and to remove
impediments.

Our job as Scrum professionals is to continually improve our ability to use

Scrum to deliver products and services that help customers achieve valuable
outcomes. This book will help you to improve your ability to apply Scrum. Its
authors share their experiences and advice, gathered from helping many
clients and students learn and apply Scrum in their organizations. I hope that
it helps you in your own professional journey.

Scrum on!

—Ken Schwaber, co-creator of Scrum and founder of Scrum.org

xv
This page intentionally left blank
 Foreword by
Dave West

What is Professional Scrum?

There is no question that the world of work is becoming more complex. It’s
not that simple work is going away, but rather that much of this work will be
replaced by automation, algorithms, and robotics. Complex work is best
defined as work that is unknown—not just in terms of how we do it, but also
in regard to the outcomes and impacts of that work. Even when we have a
clear outcome in mind, it is only after we have delivered something that we
appreciate that the impact of the change may be different from the one we
intended.

Scrum was developed to help us chart our way through a complex world. The
framework is simple yet powerful, providing a way to bring order and struc-
ture to complexity through discovery and learning. But to be effective with
Scrum requires something more than just following the mechanics of the
framework: It requires a professional attitude.

Ken Schwaber, the co-creator of Scrum, describes a professional as someone

who works for money and follows established rules for the profession. He

xvii
Foreword by Dave West

also adds that to be a professional means embracing a set of ethical stan-

dards. These standards both unify members of a profession and define that
profession to the outside world, as does the Hippocratic Oath for the medical
profession.

Building upon that model of professionalism, four additional elements are key
to achieving professionalism using the Scrum Framework:

• Discipline. To be effective with Scrum requires discipline. You have to

deliver to gain learning; you have to do the mechanics of Scrum; you have
to challenge your preconceived ideas about your skills, role, and
understanding of the problem; and you have to work in a transparent and
structured way. Discipline is hard and may at times seem unfair as your
work exposes problem after problem and your efforts seem in vain.
• Behaviors. The Scrum Values were introduced in the Scrum Guide in 2016
in response to the need for a supporting culture that would enable Scrum to
be successful. The Scrum Values describe five simple ideas that when
practiced encourage an agile culture: Courage, Focus, Commitment,
Respect, and Openness describe behaviors that both Scrum Teams and the
organizations they work within should exhibit.
• Value. Scrum Teams work on problems that, when solved, deliver value to
customers and stakeholders. Teams work for a customer who rewards them
for that work. But the relationship is complex, because the problems are
complex: Customers might not know what they want, or the economics of
the solution might be unclear, or the quality and safety of the solution may
be unknown. The job of a Professional Scrum Team is, to the best of their
ability, to do the right thing for all these parties by delivering a solution
that best meets their customers’ needs within the constraints that have been
placed on them. That requires transparency, respect for each other and for
customers, and a healthy dose of curiosity to uncover the truth.
• Helping others. Scrum is a team sport, but one where each team is small. In
consequence, the team is often the underdog trying to solve problems that
it barely has the skills and experience to solve. To be effective, Professional
Scrum Teams must work with other members of their community to learn

xviii
 Foreword by Dave West

new skills and share experiences. Helping to scale the agility of the
community is not completely altruistic, because the helpers often learn
valuable things that they can bring back to help their own teams.
Professional Scrum encourages people to form professional networks in
which ideas and experiences that help teams can be exchanged.

Merely describing Professional Scrum does very little to help you realize those
ideas in your organization or on your product. That is where Stephanie and
Simon’s book comes in: It is a support book for Professional Scrum. It takes
the Core Scrum Framework and puts it in the context of professionalism,
describing why many of these ideas make sense and how they have evolved
from different disciplines and concepts. Whether you read it from cover to
cover or dip into a particular section for specific guidance, it provides practi-
cal advice for how you can master Scrum and become more professional. And
that journey is long and never ends.

Good luck, and enjoy the ride.

—Dave West, CEO and Product Owner Scrum.org

xix
This page intentionally left blank
 I ntroduction

We live in a world in which the only certainty is uncertainty. As the world

becomes more interconnected and interdependent, it also becomes more
complex. And it’s changing rapidly: New customers and competitors can
appear, evolve, and disappear before we have a chance to respond. Technology
is constantly changing, new political realities can create new regulatory and
legal requirements to meet, and malicious hackers seem to learn faster than
our ability to thwart them.

In response to this uncertainty, we accept the fact that we cannot predict the
future. The best we can do is to act intentionally, taking small steps forward,
embracing uncertainty, embracing empiricism, and using feedback loops to
learn. This is the heart of agility and the foundation of Scrum: planning in
small increments, delivering a working Product Increment, inspecting the
result, and adapting, repeatedly and with complete transparency. But for
agility to work, it must be pursued with professionalism.

Evidence of a lack of professionalism is everywhere: from the order that

arrives with the wrong items, to the phone app that won’t work, to the
reports of security breaches that expose our private information to unauthor-
ized parties. It manifests itself in projects that spiral out of control, costing

xxi
Introduction

millions of dollars while delivering nothing of value. It also manifests itself in

personal terms: valuable working years wasted without developing new skills
or opening up new opportunities. It undermines trust and damages working
relationships. Anyone who has worked in product development has
experienced at least some of its symptoms:

• Lack of transparency with respect to progress, quality, and outcomes

• Promising false certainty and avoiding open and honest conversations
about complexity and risk
• Cutting quality to save money or time
• Avoiding accountability
• Delivering products that do not achieve acceptable quality so as to hit a
delivery date
• Ignoring new information and carrying on with the plan

S c ru m Provi de s a Way Forwa r d, I f Pu r su e d w ith

Professionalism

Scrum is an empirical approach to delivering products in a complex and

uncertain world. While Scrum is widely adopted, a lot of it is not very
professional. As Scrum co-founder Ken Schwaber observes, “Scrum is simple
to understand, yet difficult to master.”1 Among the various teams and
organizations that are actually doing Scrum, many are simply going through
the motions. We call this “mechanical Scrum.” Such teams use Scrum
terminology without understanding the intent behind it or exhibiting the
discipline that Scrum requires.

This book aims to dispel the myths, correct misunderstandings, and help
organizations to use Scrum to deliver high-quality products and experiences
for their customers. In short, it aims to help organizations apply Scrum while
achieving professionalism.

1. www.scrumguides.com

xxii
 Introduction

Who S hould R e a d thi s B ook

This book is intended for people who have a working knowledge of Scrum,
who may be doing many things right but want to improve. You may be a
Scrum Master, but you could also be a Development Team member or a
Product Owner. The important thing is that you want to, and need to,
improve. If you want to learn about Scrum, we suggest you start with the
Scrum Guide, a class about Scrum, or one of the many excellent introductory
books on the subject.2

H ow Thi s B ook I s O rganize d

Our intent in writing this book was to provide you with a virtual Scrum
Coach to assist you on your journey, helping you face challenges with trans-
parency and courage, and introducing you to new approaches that will help
you to master Scrum, exhibit professionalism, and enable business agility. We
don’t have all the answers, but we will provide tools that you can use to find
your own answers to your unique challenges.

To simplify the journey toward Scrum mastery, we have designed an approach

for Professional Scrum that synthesizes what we have learned and provides a
compass to help you navigate during your own journey. This approach is
based on our experience as practitioners, Professional Scrum Trainers, and
our learnings from the wider Scrum.org community. Where you start on your
journey is up to you.

Each chapter focuses on a particular set of challenges:

• Chapter 1: Continuously Improving Your Scrum Practice provides a way of

taking stock of your current practices, supported by the self-assessment in
Appendix A, with an eye toward identifying areas for improvement.

2. To find a class, see https://www.scrum.org/courses. If you’re looking for a concise book about Scrum,
we recommend Scrum: A Pocket Guide by Gunther Verheyen (Van Haren Publishing, 2013).

xxiii
Introduction

• Chapter 2: Creating a Strong Team Foundation helps you understand how

your team works together, identify areas for improvement, and use
appropriate techniques to improve the team’s composition and way of
working.
• Chapter 3: Delivering “Done” Product Increments explains why “Done” is
the most critical concept in Scrum and why “undone” work is a sign that
something is terribly wrong and needs to be fixed.
• Chapter 4: Improving Value Delivered focuses on measuring the value
delivered by your “Done” Product Increment and provides practices to
improve the value you deliver over time.
• Chapter 5: Improving Planning helps you improve the way that you decide
what work you’re going to do and focus on delivering high-value Product
Increments while eliminating “undone” work.
• Chapter 6: Helping Scrum Teams Develop and Improve reveals the barriers
that a team might face in delivering “Done” Product Increments and
suggests strategies to overcome them.
• Chapter 7: Leveraging the Organization to Improve considers how
organizational impediments can limit a team’s ability to deliver and
addresses what you can do to overcome those obstacles.
• Chapter 8: Conclusion and What’s Next provides a look back at the
journey you’ve been on in this book and suggests some ways to continue
your journey.
• Appendix A: A Self-Assessment for Understanding Where You Are provides
a means for assessing your current Scrum practices.
• Appendix B: Common Misconceptions About Scrum describes and corrects
common misunderstandings about what Scrum is and what it isn’t.

Ca ll to Action

As you continue forward, we encourage you to start some powerful and

productive conversations, which will help you get the most out of this book.
First, you should reflect on where you are now and where you want to go.

xxiv
 Introduction

Remember to ask for different perspectives while identifying common goals.

Here are some questions to get you started:

1. What does business agility mean to our organization? How does that
relate to our mission? What benefits do we expect to see as an
organization? What will it look like when we achieve our vision for
agility? How will it feel different?
2. What does business agility mean to our team? What benefits do we expect
to see? Which data can we use to understand agility at the team level and
product level?
3. How does business agility relate to the product vision?
4. How soon can we get a return on investment (ROI)? What more do we
want?
5. How much flexibility and control does our business have in making
investment decisions? What more is needed?
6. How quickly can we take advantage of opportunities and respond to risks?
What more do we want?
7. How do we demonstrate professionalism as a team? How do the
organization’s values and behaviors relate to professionalism?
8. What are some examples of unprofessional behavior that we have seen (or
participated in) within our organization?

xxv
This page intentionally left blank
Acknowledgments

We had a lot of help and support in writing this book. First, we must thank
Dave West, Kurt Bittner, and Ken Schwaber for their trust, support,
encouragement, and perspective on what felt like an almost impossible
challenge—writing a book that illuminates the power of Scrum, providing
practical guidance, and moving people toward discovering their own Scrum
mastery journey. Kurt Bittner performed the magic necessary to help us
express our ideas more simply and effectively. Of course, we have to thank
Ken Schwaber and Jeff Sutherland for creating Scrum itself, which has given
us paths to fulfilling work that aligns with our values and purpose.

We have so much gratitude for the Professional Scrum Trainer community,

whose members have supported us in our growth as product delivery
practitioners, Professional Scrum Trainers, and entrepreneurs. Their
generosity in sharing knowledge and experience, their commitment to
learning and growth, and their willingness to show up fully make us grateful
to be part of this community every single day.

xxvii
Acknowledgments

Many individuals have inspired and challenged us in our personal Scrum

mastery journeys. Our deepest gratitude goes to Todd Greene, Richard
Hundhausen, Stacy Martin, Don McGreal, Steve Porter, Ryan Ripley, Steve
Trapps, and many, many more.

—Simon and Stephanie

xxviii
A bout the Authors

Stephanie Ockerman is the founder of Agile Socks LLC, an agile training and
coaching business whose mission is to help people build amazing things
together, so we can all thrive in an unpredictable and complex world. She
brings more than 15 years of experience supporting teams and organizations
in delivering valuable products and services, as a Scrum Master, as a trainer,
as a coach, and as an organizational change agent. She also enjoys writing,
speaking, photography, and traveling the world. You can read her blog and see
what she is up to at AgileSocks.com.

Simon Reindl is focused on enabling individuals, teams, and organizations to

optimize the delivery of value in a humane way. He has more than 25 years of
experience developing and supporting products in a range of roles and a vari-
ety of industries around the world. Simon has worked in all of the Scrum
roles and has supported organizations from start-ups to multinational corpo-
rations in harnessing empiricism. Simon was the first Professional Scrum

xxix
About the Authors

Trainer in the United Kingdom. He has trained thousands of people around

the world, in government departments, private companies, and universities.
When not running his company Advanced Product Delivery, he enjoys time
with his family and scuba diving.

Both Stephanie and Simon are certified Professional Scrum Trainers (PSTs)
and Stewards for the Professional Scrum Master (PSM) course taught around
the world.

xxx
 I mproving Value
D elivered 4
Producing a “Done” Product Increment isn’t the end of the journey—it’s
merely the start of the learning journey to deliver more value. A Scrum Team
now has the capability to measure the value they deliver and to use
empiricism to improve the value that customers experience.

Wh at I s Va lue ?
The term value is used many times in the Scrum Guide. The first time this
term is used is in the definition of Scrum: “delivering products of the highest
possible value.” It is an interesting experiment to ask people how they define
“value.” It is actually difficult to define what value means without using the
words “value” or “valuable.” Value is, ultimately, determined by customer
experiences.

These questions can help you determine whether you are delivering value:

• Are your customers happy? Do you help them achieve outcomes that they
find important?
• Is that happiness reflected in ways that can be profitably monetized?

77
Chapter 4 Improving Value Delivered

• Are you adding or shedding customers?

• How quickly can you deliver a new idea to a customer and measure the result?
• Are your employees happy?

Not-for-profit and social enterprises don’t have concerns about profitably

monetizing customer outcomes. Even so, they are still concerned with
customer outcomes—although they may use names like “citizens” or “clients”
instead of “customers.” Some for-profit enterprises are also mission-driven,
but missions can be described in terms of achieving a set of outcomes for a
group of people, as in the following examples:

• Increasing local employment

• Improving the well-being of a community
• Reducing negative ecological or environmental impacts

Noted management consultant, educator, and author Peter Drucker observed,

“If you can’t measure it, you can’t improve it.” The same is true of value:
Producing and delivering “Done” Product Increments is not enough; you have
to measure the value you are delivering to improve it.

D e live ring Fa ste r I s a G ood Sta rt,

B ut N ot E noug h
While many organizations turn to Scrum to “deliver faster,” once they start
delivering to customers and measuring the results, they discover that the real
benefit of Scrum is getting feedback sooner to drive faster improvement. In
fact, if faster delivery alone could solve the problems that organizations face
in meeting customer needs, a traditional approach with many very small
releases would suffice.

The problem is that, to paraphrase John Wanamaker, more than half of our
ideas deliver no value; we just don’t know which half.1 To improve your ability

1. John Wanamaker (1838–1922), a wealthy department store owner, famously observed that “Half the
money I spend on advertising is wasted; the trouble is, I don’t know which half.”

78
 Delivering Faster Is a Good Start, But Not Enough

to deliver value, you have to not only improve the speed at which you deliver
value, but also measure what you deliver to determine its value, and you must
use that feedback to improve the value you deliver in the next release.

Studies have shown that 65 percent of features are rarely or never used (see
Figure 4-1).2 In a similar vein, a 2017 article in the Harvard Business Review
stated that “the vast majority of [new ideas] fail in experiments, and even
experts often misjudge which ones will pay off. At Google and Bing, only
about 10% to 20% of experiments generate positive results. At Microsoft as a
whole, one-third prove effective, one-third have neutral results, and one-third
have negative results.”3

Standish Group, Features and Function Usage

Rarely Often
19% 20%

Never
45% Sometimes Hardly Ever
16% 50%
Infrequently
30%
Often
13%
Always
7%

2002 2014

Figure 4-1 Most features are rarely or never used.

Value is easy to understand when measured in terms of revenue, income, and

direct costs, but not all value is monetary in nature. Market share growth
rate, diversity of the customer base, customer satisfaction, employee
satisfaction, and employee turnover rate are also important measures of
value. Likewise, ease of use and ease of product adoption can be important
measures that inform product improvements.

2. The Professional Product Owner: Leveraging Scrum as a Competitive Advantage by Don McGreal and
Ralph Jocham (Addison-Wesley, 2018), part of the Professional Scrum Series from Scrum.org.
3. https://hbr.org/2017/09/the-surprising-power-of-online-experiments

79
Chapter 4 Improving Value Delivered

Product Value and the S c ru m Te am

In Scrum, the Product Owner is accountable for maximizing the outcomes
that the product will deliver to customers, thereby maximizing the value
realized by the organization.

This focus on value and outcomes represents a change for organizations in

which output has historically been the measure of success. Output measures
things that are produced or consumed, such as features delivered or story
points. Output is easy to measure, but it is of only secondary importance:
The number of features delivered is irrelevant if none of those features
improves the lives or capabilities of the customer. Features delivered matters
only in consideration of profitability or time-to-market, but if they produced
nothing of value then they are simply waste.

I n Pr a c t ic e: M e a s u r i ng Prog r e s s a n d S u c c e s s
When people talk about “status” or “progress,” listen for the mindset driving the
discussion. If it is just about percent complete, number of features built, or red/
yellow/green status, ask some powerful questions that bring focus to the value of
the product:

• Could we achieve all of these measures and still be unsuccessful?

• How are we validating assumptions about the user needs or the market demand?
• What are we learning about value? How is this guiding our product decisions?
• What has changed with our users or our competitive environment since we
began this initiative?

Too often, “percent complete” and similar discussions hide an assumption that
everything on the “wish list” is important and valuable. The aforementioned
studies prove that they are not. Instead of worrying about whether everything
will get done, focus discussions on how you can more quickly test assumptions
about value to reduce waste and increase the value that you deliver.

The Scrum Team determines its process within the Scrum Framework.
This process includes defining value, delivering value, and measuring value.

80
 Using the Product Vision to Enliven Team Purpose, Focus, and Identity

Although the Product Owner remains accountable, it is likely that a Product

Owner needs help. The Product Owner needs input from stakeholders,
including customers, users, and Development Team members. The Product
Owner also depends on the Development Team to actually deliver value, so
it’s important that those team members understand the outcomes that cus-
tomers seek to better inform decisions.4

The Product Backlog creates transparency into the relative importance of

the work that the Product Owner believes will maximize value delivered.
When it’s used most effectively, it forms the foundation for a dialogue
with the rest of the Scrum Team as well as stakeholders, about what is
valuable.

U sing the Product Vi sion to E nliven Te am

Purpose , Focus, and I dentit y
The Product Vision expresses the raison d’etre of the product—who it is
for, and what it hopes to do for them. It is important when defining and
funding the product, but it also has value in bringing purpose and focus to
the Scrum Team and helping them form their identity. Returning to this
vision periodically is a useful way to remind everyone on the team why the
team exists.5 Various related techniques help the team shape and reinforce
their identity:

• Product value. A clear understanding of value helps a team understand

the why behind their work and how to validate whether their work is con-
tributing value. Knowing the value in a tangible way (e.g., revenue,

4. For a much deeper dive into defining products and how to better understand what customers will find
valuable, we recommend Scrum.org’s Professional Scrum Product Owner class: https://www.scrum.org/
courses/professional-scrum-product-owner-training. If you can’t make it to a class, or even if you can,
we also recommend The Professional Scrum Product Owner by McGreal and Jocham, part of
Scrum.org’s Professional Scrum Series.
5. For more information on creating a strong product vision, see The Professional Product Owner:
Leveraging Scrum as a Competitive Advantage by McGreal and Jocham.

81
Chapter 4 Improving Value Delivered

market share, customer satisfaction) goes a long way toward instilling a

sense of purpose.
• Personas. Personas help a team understand users and customers better, so
as to develop empathy for them. This ultimately helps team members see
the purpose in their work and create better solutions. Some teams post
their persona descriptions around their work environment as a continual
reminder of the people they are working to help.6
• Product Roadmap. A Product Roadmap is a visual representation of the
high-level plan intended to help a team see the direction of the product over
time. The more a roadmap focuses on business objectives and business
value, the more it provides a solid purpose.

I n Pr a c t ic e: E n l i ve n i ng t h e Pro d u c t V i s io n
It is easy for the Product Vision to be defined early in a product’s life cycle, but
then become forgotten in the pursuit of individual releases. Products change over
time, and they can do so either mindfully or accidentally. Feature creep and other
forms of harmful scope expansion are often caused by the lack of focus that results
from a confused or unfocused Product Vision. Consider these ways to keep the
Product Vision keenly tuned:

1. Involve a broader community. Your stakeholders and your Development Team

likely have valuable perspectives and ideas. And by including others, you help
them feel heard, which is likely to increase their commitment to and under-
standing of the Product Vision. Using the Product Vision to engage in periodic
discussions of who the product should serve and what it should do for them
is a good way to evolve it in mindful, and not accidental ways.
2. Evolve it based on new information. The initial Product Vision is a starting point,
based on assumptions and guesses, many of which will be correct but some
of which will prove wrong. You will need to inspect, adapt, and evolve the
Product Vision based on new information.

6. For more information on personas, see http://gamestorming.com/empathy-mapping/ and

https://www.romanpichler.com/blog/10-tips-agile-personas/.

82
 Measuring Value

3. Keep it focused. Successful products have a clear focus; the teams building
them know who they are serving and how. Poor products try to do a little
something for everyone, but not very much for anyone.
4. Constantly reinforce it. In the words of Professional Scrum Trainer Don
McGreal, “Be annoying about it.” Product Owners should look for
opportunities to reinforce the Product Vision, as well as validate align-
ment to the Product Vision. Product Owners can bring the physical
manifestation of the Product Vision to Sprint Reviews or other discussions
with stakeholders and the Development Team (e.g., the Product Box7 or a
poster of the elevator pitch). 8

M e a suring Va lue
Scrum Teams can measure the value they deliver in a variety of ways, and dif-
ferent kinds of value will need to be measured in different ways, ranging from
very general about the product as a whole to highly specific about certain
PBIs. In reality, you will probably need all of the following kinds of measures
at different times:

General measures of customer happiness:

• Net Promoter Score

• Revenue or profitability per customer
• Repeat customer business
• Reduction in total cost of ownership
• Improved conversion rates
• Growth in number of customers or users
• Customer referrals

7. For more on the Product Box technique, see https://www.innovationgames.com/product-box/.

8. For examples of elevator pitches, see https://strategypeak.com/elevator-pitch-examples/.

83
Chapter 4 Improving Value Delivered

Achievement of business goals:

• Market share
• Aggregate revenue or profit
• Cost to obtain a new customer
• Reduction in cycle time, reductions in inventory on hand, cost savings, or
increases in market share

Specific measures of customer results:

• Time saved for the customer to achieve a goal

• Frequency of feature usage
• Duration of feature usage
• Number of customers or users using a feature
• Transaction completion/abandon rates

I n Pr a c t ic e: U s i ng S eve r a l M e a s u r e s t o D i a g n o s e
Pro d u c t Pro b l e m s
The preceding lists are not exhaustive, but rather illustrate that different kinds of
measures can be used to quantify value in different ways. In most cases, one mea-
sure will trigger questions that require other measures to explain. For example,
a general decline in the Net Promoter Score or customer referrals suggests that
customers have become less happy with the product. When you start measuring
what users are actually doing with the product, you might find that some new
feature that you introduced has made the product harder to use, leading to the
general dissatisfaction that you measured earlier.
Scrum Teams can improve their measures of value in a variety of ways:

• Involve others. Just as with a Product Vision, your stakeholders and your
Development Team likely have valuable perspectives and ideas. Also, by including
others, you help them feel heard, which is likely to increase their commitment
to and understanding of product value.
• Make measures visible. Measures should be transparent to all stakeholders and
the Development Team. Consider creating a dashboard of value metrics for the
product.

84
 Measuring Value

• Talk about measures and results in Sprint Reviews. As features and functions are
being demonstrated to attendees, speak to the value expected and how it will
be known if it is achieved.
• Relate measures and results back to business goals. This comes back to creating
alignment and helps provide the rationale for how you are defining value. And if
business goals change, then that can be a good indicator that you need to inspect
and possibly adapt your value definitions and measures.

Focusing PBI s on U s e r O utcom e s

Understanding user needs and desires is key to understanding what is valuable
and why. Scrum Teams can apply a number of techniques to understand users
better. In particular, two techniques often combined to help Scrum Teams
better understand and focus on users are personas/outcomes and User Stories.

Personas and Outcomes

A persona is a fictional character created to represent a user or customer type
that might use a product in a similar way. Personas are often created through
market research data and customer interviews. They bring the person to life
(so to speak) by painting a picture with information related to demographics,
lifestyle, goals, and reasons for using the product. Using personas helps the
Scrum Team achieve focus by helping them get very specific about who they
are targeting with a particular PBI.

An outcome is some condition or goal that a person matching the persona

would like to achieve. Understanding these goals helps a Scrum Team achieve
focus by clearly articulating what the user or customer would like to achieve.

Using personas and outcomes has the following principal benefits:

• Help the people building the products empathize more with the users and
their needs
• Help identify user pain points and creative solutions
• Help create focus while still being able to see the whole

85
Chapter 4 Improving Value Delivered

Personas and outcomes are antidotes to features that don’t have clear objec-
tives or a clear target audience. Personas also help avoid vague discussions
about “the user,” because no product has a single homogenous kind of user;
instead, people use the same product in very different ways to achieve very
different outcomes.

I n Pr a c t ic e: U s i ng I m p a c t M a p s t o G a i n B e t te r
Pro d u c t I n s ig h t s
Impact mapping can be a useful technique for connecting PBIs back to the goals
they are intended to meet.9 You can use a modified impact map to connect the
business goal you are trying to achieve to the personas that you will serve, the out-
comes you hope to help them achieve, the impacts to your organization if you meet
that outcome, and the PBIs that you will deliver in the product to achieve those
outcomes (see Figure 4-2).

Persona Outcome Impact PBIs

Existing Customers Have a great ride experience Recommend friends
Provide reward for referrals

Book trips in advance

Have an easier riding Choose GKR for
Taxi Customers experience convenience Communicate with driver in real time

Price-based advertising

Add a tip

Female
Customers Arrive safely at destination Choose GKR for safety
Notify contacts of ride details
Provide security alerts

Increase # new
Goal customers by 20% Have an enjoyable
ride-hailing and Use GKR from
Integrate with Facebook Messenger
payment experience favorite apps
Integrate with Google Maps
Tech-savvy Riders Integrate with TripAdvisor

Make air travel more

predictable and Use GKR for airport
transfers Integrate with Triplt
enjoyable
Frequent Travelers Integrate with airline booking sites

Experience fewer delays Use GKR instead of

Pay with transit pass
and less waiting public transit
Ride-share with friends
Price-Conscious Riders Split fare with friends

Figure 4-2 An extended impact map helps connect PBIs back to goals.

9. For a description of a useful extension of impact mapping, see https://www.scrum.org/resources/blog/

extending-impact-mapping-gain-better-product-insights.

86
 Measuring Value

In the example in Figure 4-2, the organization—a company that is entering the
ride-sharing service market—would like to increase the number of new customers
by 20 percent. To do so, it needs to appeal to many different kinds of potential
riders, each represented by a different persona. Each persona has different
outcomes that it would like to achieve. The company believes that by satisfying
specific outcomes, it will achieve certain impacts, or results for the company, and
it believes that delivering certain PBIs will help the company do that.

Impact maps can be used in a variety of ways. In the context of Product

Backlog refinement, they help the Scrum Team think about how each PBI will
provide some outcome. Impact maps also help the Product Owner envision
who the product serves, what those different kinds of users or stakeholders
would like to achieve by using the product, and how the organization will
benefit from helping customers achieve specific outcomes.

I n Pr a c t ic e: E x p r e s s ing PBI s a s H y p o t h e s e s o r
E x p e r im e n t s
Hypothesis-Driven Development (HDD) is a way of expressing PBIs in a way that
makes the persona, outcome, measurement, and expected result explicit.10 The
discipline of HDD helps Scrum Teams to frame hypotheses and experiments and
to be mindful about how they will know whether a hypothesis (or assumption) is
true. This encourages everyone to think about not only what they are trying to
accomplish, but also how they will measure it.11 Figure 4-3 provides an example of
one way to express a hypothesis.
Expressing Hypotheses
Feature Persona
Outcome
We believe [doing this] for [these
people] will achieve [this outcome] We
will know that this is true when we see
[this measurement] changed
Measure

Figure 4-3 Explicitly expressing hypotheses can help teams uncover unstated assumptions.

10. Scrum.org’s Professional Scrum with User Experience Course (https://www.scrum.org/courses/professional-

scrum-user-experience-training) teaches how to integrate modern UX practices with Scrum, based on the
book Lean UX by Jeff Gothelf and Josh Seiden (O’Reilly Media, 2016).
11. For more on Scrum and HDD, see https://www.scrum.org/resources/blog/
scrum-and-hypothesis-driven-development.

87
Chapter 4 Improving Value Delivered

User Stories
User Stories are both widely used and widely misused. Their original intent
was to serve as a placeholder or token for a conversation about how someone
would use the product to achieve some outcome. When they stray from that
reminder to have a conversation and become a format for documenting PBIs,
they can become utter nonsense, particularly when used to express technical
requirements or constraints. To keep this from happening, focus on the 3 Cs
of User Stories:12

• The Card, which is simply a reminder to have Conversations. It should have

a simple, minimal format that fits on an index card (or a sticky note) and
may consist of nothing more than “Talk to Mary about how accounts are
settled at the end of a billing period.”
• The Conversation, which is the actual discussion about the topic mentioned
on the card.
• The Confirmation, which are the actual tests that prove it works.13

I n Pr a c t ic e: Co m m o n Pro d u c t B a c k l og I t e m
Pi t f a l l s
Regardless of the format that your PBIs take (personas and outcomes, User
Stories, or something else), beware of these common traps:

1. Assuming that PBIs must follow a set format. The commonly used format for
User Stories is not the original format, nor is it required. It may be helpful for
your Scrum Team to use a format, but they don’t have to fight to fit a PBI into
that format. Write what makes sense. After all, the Card is just a reminder to
have a Conversation.
2. Not being clear on the user or customer the PBI benefits. If you are writing over
and over again, “As a user” at the beginning of a User Story, you are not help-
ing create focus and understanding of the user for whom you are designing a
feature or function. As noted in #1, you don’t have to always use this format,
but you should have a shared understanding of the users and customers for
your product.

12. https://www.agilealliance.org/glossary/user-stories/
13. If you want to apply User Stories as an effective Product Backlog refinement technique, we recommend
Mike Cohn’s book User Stories Applied (Addison-Wesley Professional, 2004).

88
 Measuring Value

3. Not clarifying the value. Often PBIs will state a desired feature, function, or
capability, but precisely why that item is desired is not clear. When there
isn’t a shared understanding of why you are building something, it is possible
that alternative solutions to the problem will not be discussed. This misses an
opportunity to maximize value.
4. Treating the PBI as a contract. The Product Backlog is not just the “agile ver-
sion” of a traditional software requirements document. PBIs are open to
change. Consider the User Story technique: It is meant to represent a cus-
tomer’s needs, not just document them. User Stories are to be elaborated,
even during the work of building it.
5. Including implementation details. PBIs should be focused on the “what” rather
than the “how.” If you make implementation decisions too early, you may limit
your options. You may also create waste by detailing things that are likely to
change when implementation actually occurs.

I m proving Va lu e D e livered D u ring the S print

As the Development Team works on PBIs during a Sprint, their understanding
of the value that the PBIs will deliver continues to improve as they learn more,
through conversations, through stakeholder feedback, and even from real cus-
tomers or users if the team is releasing a product during the Sprint. (Yes, this
is possible!)14 A PBI is never “locked down” or “finalized” until it is actually
“Done.” This includes the details of both what is being built and how it is
being built. If members of a Development Team are collaborating with one
another, as well as with the Product Owner, they can constantly ask questions
related to value and let this drive their decision-making process. For example:

• A Scrum Team chooses to split a PBI to focus on the most valuable

acceptance criteria for the user functionality required now, which allows the
lower-value piece to be reprioritized at a later time based on a
consideration of other desired functions.
• When seeing a new capability implemented in the product, the Product Owner
provides guidance on how to make it more prominent to the target users.

14. For a deeper perspective on releasing during a Sprint, see https://www.scrum.org/resources/blog/

myth-3-scrum-releases-are-done-only-end-sprint.

89
Chapter 4 Improving Value Delivered

• The Development Team sees alternative ways to increase user conversion,

which is the stated value of the PBI they are building. They bring these
options to the Product Owner, and they negotiate a change to the scope to
better meet the business need while still delivering a “Done” Increment in
the Sprint.

I n s pecting a nd A dap ting Ba sed on Feedback

Once you’ve released the product or demonstrated the product to stakeholders,
you will have empirical data that you can use to confirm (or reject) your
hypotheses. One data point in time usually doesn’t tell you much, but trends
over time will show you whether you are getting better or worse in a particular
dimension. And, remember, you may need different measures to really
understand what is going on.

For example, you might have very happy customers who love your product,
but no measures of their happiness will tell you why people don’t buy your
product. If you want to expand your market share, you will need to measure
more than the current value delivered by the product—that is, you will also
need to understand which factors prevent you from realizing the full market
potential of your product.15

As you are analyzing the value trends, consider what changes you released and
when and how they may have impacted value. Consider what factors are
beyond your control (e.g., a big decline in the stock market could impact
users’ decisions even though you’ve implemented new features you expected
to increase sales).

L e a r ning a s Va lu e
Sometimes the value lies in the learning. This process may or may not be
data-driven, but it can be helpful to be explicit about learning as the value.

15. Scrum.org has developed a framework for understanding how to measure value and improve your
ability to deliver value called Evidence-Based Management. The two dimensions of value are Current
Value, referring to the value realized by current customers of your product, and Unrealized Value,
meaning the potential value that you could deliver to all potential customers, but do not deliver today.
For more information, see https://www.scrum.org/resources/evidence-based-management.

90
 Inspecting and Adapting Based on Feedback

For example, a Scrum Team may want to learn which of two technology
services will be easy both to implement and to enhance, while also meeting
the business needs. In another example, a Scrum Team might want to learn
which user experience is most likely to lead to a purchase.

E ffective S print R e vie ws I nclude Va lu e R e alized

Recall that the outcome of a Sprint Review is adaptation of the Product
Backlog. In addition to stakeholder feedback on the Product Increment and
overall market trends, actual value data and trends give you even more
empirical data to guide Product Backlog decisions.

Make your actual value measures transparent. Get input on what stakeholders
see in the trends and how they think it should inform adaptation.

Gathering Stakeholder Feedback

How you approach gathering input from stakeholders will depend on many
factors, including, but not limited to, the complexity of your product, the
number of stakeholders you have, the diversity of stakeholder types and their
needs, and where your stakeholders are located. You often need to pay special
attention to stakeholders to gather the most valuable information from them.
While they are usually quite expert in some area of interest, you might need
to steer their attention toward the things about which you need feedback.
Keep in mind that Sprint Reviews are not the only time Product Owners can
get input from and collaborate with stakeholders. You will get more from
stakeholder collaboration sessions in general, and Sprint Reviews in particu-
lar, if you can focus stakeholders’ participation in the following ways:

• Be explicit about what you are reviewing and what feedback you are
looking for. Having a simple but explicit agenda for feedback sessions helps
everyone focus.
• Make feedback sessions active, and encourage participation. People thrive
on activity. Conversely, sitting passively, listening to someone drone on
about features, functions, and capabilities, is often boring for participants.
Organizing sessions in ways that force people to move will keep them more

91
Chapter 4 Improving Value Delivered

engaged, which in turn often saves time. Also, people are more likely to feel
heard if they physically participated in an activity.
• Enable stakeholders to collaborate with each other. Stakeholders can learn
from each other. Not everyone shares the same perspective, and sometimes
this results in conflicts that could be resolved if stakeholders understand
each other’s perspectives.
• Make collaboration visible. It is easier to discuss a wide range of ideas
when we can see them in a physical space and easily add, update, and move
information. In addition, this approach creates transparency into what we
are trying to accomplish and what we learned together by the end. It is also
helpful to have that vision and definition of value visible to keep things
focused.
• Break into smaller groups during a session. Smaller groups of people
interested in particular topics are usually more effective than large group
discussions. Allow time for them to have smaller group discussions and
bring their results back to the group.
• Introduce techniques that encourage relative value comparisons. It is easy
to get bogged down in details, especially when discussing which PBIs are
more valuable than others. By comparing value relatively (i.e., Item X is
more valuable than Item Y but less valuable than Item Z), we can get
enough information quickly.16

S um m a ry
Scrum is not designed to help you build and release more “stuff.” Instead,
Scrum helps you maximize the value you create for your customers, and
therefore for your organization, by frequently delivering a product, measuring
the results, and then learning and adapting so as to wring more value out
of the product.

In this chapter, we explored how empiricism, an agile mindset, and teamwork

guide you in fiercely tackling difficult product value questions. You must have

16. For specific facilitation techniques to gather input about relative value to help with Product Backlog
ordering, see The Professional Product Owner by McGreal and Jocham, p. 213.

92
 Call to Action

transparency into value, and you must engage in frequent enough inspections
of the actual value realized that you can keep moving in the best direction. Just
like the complexity and unpredictability inherent in building a releasable prod-
uct, figuring out what to build entails some complexity and unpredictability.
Scrum provides the minimal level of empiricism, and the Scrum Team needs to
determine their process within the Scrum Framework. This process includes
how you enable value emergence, measure actual value, and adapt to new
information and the changing environment.

The Product Owner is the single person accountable for optimizing value. An
empirical Product Owner will engage and empower others to support them in
achieving this goal. A strong Product Owner will foster a product mindset
across the organization and paint the bigger picture, creating alignment
within the Development Team and among stakeholders on the direction of the
product and how value is defined. The Product Owner works collaboratively
with the Development Team and stakeholders to enable value emergence
iteratively and incrementally, guided by the learning from measuring actual
value.

Ca ll to Action
Consider these questions with your team:

• How well is the Product Vision understood by the Development Team and
stakeholders?
• Where do you need more transparency into desired outcomes and value
assumptions?
• What value measures would help you make more informed decisions about
what is in the Product Backlog and its order? How frequently would you
need to inspect those data?
• How does the Development Team collaborate with the Product Owner or
relevant stakeholders during the Sprint?
• How much feedback and new insights come out of the Sprint Review or
other collaborative sessions with stakeholders?

93
Chapter 4 Improving Value Delivered

• Do stakeholders focus on value delivery as the key measure of success?

What conversations can you have to help shift the focus in the right
direction?
• What challenges are hurting the most right now? Identify one or two
experiments to help improve understanding and measurement of value.
For each experiment, be sure to identify the desired impacts and how you
will measure them.

94
 I nde x

A alignments (planning), creating,

accountability, 33–34, 41 100–101
collaborative teams, 41 analyzing, 63
organizations, improving, 145 answers, analyzing, 168
Scrum Masters, 127–129 approaches
Scrum Teams, 33–34 context-based approaches (Scrum
adaptable teams, characteristics of, Masters), varying, 131–132
46–47 different approaches,
adaptable teams, characteristics of, experimenting with, 18–20
46–47 ATDD (Acceptance Test-Driven
adaptation, empiricism, 3 Development), 65–66
Agile Manifesto, 67–68 automation, “Done” increments,
agile mindsets, 2 66–68
estimation and, 105–106 autonomy, team members, 26
planning and, 98–99
B
agile transformations, improving
backlogs, Scrum Boards, 59–60
organizations, 152–153
BDD (Behavior-Driven
agility (business)
Development), 65
emergent solutions and, 157–160
blocked PBI, 63
self-assessments, 161–162
boundaries, Scrum Teams, 34–35
agreements (working), 29–30

175
Index

budgeting (iterative/incremental), Community of Practice. See CoP

150–152 confirmations (User Stories), 88
build stability metrics, “Done” conflict
increments, 69 collaborative teams, 38–39
burndowns spectrum of, 39
example of, 61 consensus
Sprint Retrospectives, 61 collaborative teams, 40–41
business agility, 161–162 Sprint Goals, 56
emergent solutions and, 157–160 context-based approaches (Scrum
self-assessments, 161–162 Masters), varying, 131–132
business goals, measuring continuous improvement (self-
achievement of, 83–84 assessments), need for, 12–13
business impact, Sprint Goals, 56–57 control (illusion of), letting go,
146
C CoP (Community of Practice),
career paths, 140–141 126–127
capabilities (individual/team), courage (teamwork), self-
growing, 124 assessments, 167
career paths (individual), 140–141 conversations (User Stories), 88
change model (Satir), 44–45 cross-functional teams, 4
coaching skills customers, measuring
Scrum Masters, 132–134 happiness, 83
Scrum Teams, 10 results, 84
code coverage metrics, “Done” cycle times, measuring/analyzing
increments, 69 flow, 63
code reviews, “Done” increments, 68 transparency, 63
collaborative teams, 4, 36
accountability, 41 D
commitment, 40–41 Daily Scrums, 165
conflict, 38–39 effectiveness of, 57–58
consensus, 40–41 self-assessments, 165
Fist of Five, 40–41 Sprint Goals, 57–58
Roman voting, 40–41 as status meetings, 172–173
trust, 36–38 defect metrics, “Done” increments,
commitment 69
collaborative teams, 40–41 Definition of Done. See DoD
teamwork, self-assessments, 167 Development Team, 28–29, 164
complexity metrics, “Done” DevOps, “Done” increments, 68
increments, 69 diagnosing product problems, 84–85

176
 Index

different approaches, experimenting evolution of organizations, need for,

with, 18–20 137–138
distributed teams, 143–144 evolving plans/funding of products,
documenting requirements 151–152
Product Backlogs, 171–172
F
Product Owners, 171
facilitation skills, Scrum Teams,
DoD (Definition of Done), 50–54
9–10
benefits of, 51–52
failure as success, 20–21
creating, 52–54
fast delivery versus feedback,
defined, 50–51
determining value, 78–79
Now, Next, Future technique,
feedback
53–54
loops, 3
PBI, 58
stakeholder feedback and value,
technical debt, 71
91–92
dogmatic Scrum, 14
versus fast delivery when
“Done” increments, 34, 49–50 determining value, 78–79
flow
E blocked PBI, 63
emergent solutions and business cycle times, 63
agility, 157–160 Kanban, 64
emotional intelligence, team measuring/analyzing, 63
members, 25, 26 PBI, 63
empiricism, 3, 162–166 Sprint Burndowns, 63
adaptation, 3 throughput charts, 63
estimation, 105–106 WIP, 63
inspection, 3 focus
planning and, 98–99 Sprint Goals, 56–57
Scrum Framework, 3–4 teamwork, self-assessments,
self-assessments, 162–166 167
transparency, 3–4 “force field” analysis, 116–117
velocity, improving, 124 forecasting
estimations probabalistic forecasting, 110
planning, 104–106 Sprints, 109–110
agile mindsets, 105–106 forming teams, 42
empiricism, 105–106 frameworks
group estimation, 105–106 “Done” increments, 34
teamwork, 105–106 empiricism, 3–4
scope-based, improving guard rails, 6
organizations, 149–150 Team Processes, 6

177
Index

funding tracking, 121–122

evolving plans/funding of velocity, improving, 124
products, 151–152 “waste snakes,” 119–121
initiatives, 148 improvement (continuous),
self-assessments, 12–13
G incremental changes versus quick
goals benefits, Scrum Teams, 13
business goals, measuring incremental/iterative budgeting,
achievement of, 83–84 150–152
Scrum Teams, 32–33 increments, self-assessments, 164
shared goals, 32–33 individual capabilities, growing, 124
Sprint Goals, 33, 55–58 individual/team development, 138
governance processes, 169–170 accountability, 145
group development, Tuckman’s budgeting (iterative/incremental),
model of, 42 150–152
group estimation, 105–106 career paths, 140–141
growth (continuous), Scrum Team control (illusion of), letting go,
development, 125 146
guard rails, Scrum Framework, 6 evolving plans/funding of
products, 151–152
H
Iron Triangle, 146–148
happiness (customer), measuring, 83
organizations, improving, 138
HDD (Hypotheses-Driven
performance reviews, 139
Development), 87
score-based estimations,
hypotheses, PBI as, 87
149–150
I sourcing strategies, 141–143
identity of Scrum Teams, 5, 23–24 team impacts, 141–143
illusion of control, letting go, 146 initiatives, funding, 148
impacts inspection, empiricism, 3
quantifying, 121–122 intelligence (emotional), team
teams, improving organizations, members, 25, 26
141–143 interruptions, tracking, 122
impediments intervention, appropriateness of
chart example, 121 (Scrum Masters), 134
identifying, 118–119 intrinsic motivation, team members,
25–26
impacts, quantifying, 121–122
Iron Triangle, 97–98, 146–148
prioritizing, 123
iterative/incremental budgeting,
removing, 118–119, 123
150–152
stakeholder engagement and, 123

178
 Index

J–K–L motivation (intrinsic), team

Kanban, measuring/analyzing flow/ members, 25–26
transparency, 64 MVP (Minimum Viable Product), 99
knowledge/experience, Scrum Team
development, 126 N
large releases, 113 norming, Scrum Teams, 42
leadership north (pointing), Scrum Masters,
Scrum Teams, 35 132
servant leadership, 11–12 Now, Next, Future technique (DoD),
learning 53–54
as value, 90–91 O
continuous learning and Scrum one-day Sprints, 58–59
Team development, 125
one-size-fits-all Scrum, 14
length of Sprints, 109
openness (teamwork), self-
M assessments, 167
managing Sprint Goals, 56 outcomes (user), PBI and, 85–87
mastery, team members, 26 outsourcing product support, 142
measuring P
business goals, achievement of, pair programming, 125
83–84
PBI (Product Backlog Items), 58–59
customer happiness, 83
blocked PBI, 63
customer results, 84
Development Teams, 58–59
product problems, diagnosing
DoD, 58
with measures, 84–85
“Done” increments, 58–59
progress, 80
experiments and, 87
quality, “Done” increments,
flow, measuring/analyzing, 63
68–70
HDD, 87
Sprint Goals, 56
hypotheses and, 87
success, 80, 97–98, 129–131, 173
pitfalls of, 88–89
value, 83–85
product value, 80–81
mechanical (zombie) Scrum, 14
small PBI, 58
meetings (status), Daily Scrums as,
172–173 Sprint Goals, 56, 58–59
methodology, Scrum as, 169–170 technical debt, 71–72
mindsets (agile), 2 transparency, measuring/
analyzing, 63
estimation and, 105–106
user outcomes and, 85–87
planning and, 98–99
User Stories, 88–89
misconceptions about Scrum, 169

179
Index

PBI (Product Backlog Items) (continued) documenting requirements,

valuable outcomes, focusing on, 171–172
106–107 evolving plans/funding of
performance products, 151–152
reviews, 139 refinement, 101–104
Scrum Teams, 7, 43 self-assessments, 164–165
personality, team members, 25–26 Product Increments, Scrum Teams, 5
personas, defined, 81–82 Product Owners, 58–59
planning documenting requirements, 171
agile mindsets and, 98–99 self-assessments, 162–163
aim of, 95 product problems, diagnosing, 84–85
alignments, creating, 100–101 Product Roadmaps, defined, 82
empiricism and, 98–99 product support, outsourcing, 142
estimation and, 104–106 product value, 80
evolving plans/funding of defined, 81–82
products, 151–152 PBI, 80–81
PBI, valuable outcomes, 106–107 progress, measuring, 80
Product Backlog refinement, success, measuring, 80
101–104 Product Vision
product mindset, 96–97 defined, 81
“Ready,” defined, 102–103 enlivening, 81–83
releases, 112–113 productive teams, characteristics of,
Scrum Teams and, 96 46–47
self-assessments, 163 progress
Sprints, 107–112 measuring, 80
success, measuring, 97–98 Scrum Boards, 59–60
pointing north, Scrum Masters, 132 Scrum Teams, 42–45
practice, community of (CoP), Sprint Burndowns, 61
126–127 visualizing, 59–61
preparing for Sprints, 174 WIP, limiting, 62–63
prioritizing impediments, 123 purpose
probabalistic forecasting, 110 statements, 31
problem-solving, experimenting with team members, 26
different approaches, 18–20
Processes (Team), 6 Q
Product Backlog Items. See PBI quality
Product Backlogs building in, 64–66
as request lists, 172 build stability metrics, 69
code coverage metrics, 69

180
 Index

complexity metrics, 69 as “silver bullet” for development

defect metrics, 69 speed, 170–171
“Done” increments, 64–66, 68–70 best practices, 14
metrics, 68–70 common dysfunctions, 14–15
trends, 69–70 defined, 1
dogmatic scrums, 14
R good enough scrums, 15
“Ready,” governance processes, 169–170
defined, 102–103 mechanical (zombie) scrums, 14
Sprints, refining as, 111–112 misconceptions about, 169
releases one-size-fits-all scrums, 14
large releases, 113 root cause analysis, 15–17
planning, 112–113 snowflake Scrum, 15
sizing, 113 undone Scrum, 14
small releases, 113 water-Scrum-fall, 14–15
repaying technical debt, 73 zombie (mechanical) Scrum, 14
request lists, Product Backlogs as, Scrum Boards, 59–60
172 Scrum Framework
requirements documents “Done” increments, 34
Product Backlogs, 171–172 empiricism, 3–4
Product Owners and, 171 guard rails, 6
respect (teamwork), self-assessments, Team Processes, 6
167–168 Scrum Masters
results (customer), measuring, 84 accountability, 127–129
retrospectives approaches, 131–132
setbacks, dealing with, 43 coaching skills, 132–134
Sprint Burndowns, 61 context-based approaches,
reviews (performance), 139 varying, 131–132
roadmaps, defined, 82 Development Teams and, 173
root cause analysis, 15–17 impediments, managing, 123
intervention, appropriateness of,
S
134
Satir change model, 44–45
pointing north, 132
scaling organizations, 149–150,
self-assessments, 166
153–154
servant leadership, 11–12
score-based estimations, improving
organizations, 149–150 success, measuring, 129–131
Scrum teaching skills, 132
as methodology, 169–170 upholding Scrum, 132

181
Index

Scrum Teams knowledge/experience, leveraging,

accountability, 33–34, 145 126
adaptable teams, characteristics leadership, 35
of, 46–47 mastery, 26
adjourning, 43 motivation to change, 116–117
autonomy, 26 norming, 42
boundaries, 34–35 organizations, improving, 138
budgeting (iterative/incremental), pair programming, 125
150–152 performance, 7, 43
capabilities, 7–12 performance reviews, 139
capabilities (individual/team), personality, 25–26
growing, 124 planning, keys to, 96
career paths, 140–141 Product Increments, 5
coaching skills, 10 Product Vision, 81–83
collaborative teams, 4, 36–41 productive teams, characteristics
continuous improvement, need for, of, 46–47
12–13 progress, 42–45, 80
control (illusion of), letting go, purpose of, 5, 26
146 purpose statements, 31
CoP, 126–127 score-based estimations, 149–150
cross-functional teams, 4 Scrum Boards, 59–60
developing/improving, 138 Scrum Masters, 127–134
Development Team, 28–29, 30 selecting team members, 27–28
distributed teams, 143–144 self-assessments, 162–163
emotional intelligence, 25, 26 self-organizing teams, 4, 31–32, 35
empiricism, 3–4 servant leadership, 11–12
evolving plans/funding of setbacks, dealing with, 43
products, 151–152 shared goals, 32–33
facilitation skills, 9–10 skills/talents of team members,
feedback loops, 3 24–27
forming, 42 sourcing strategies, 141–143
foundations, building, 23–47 Sprint Goals, 33
identity, 5, 23–24 Sprint Retrospectives, 115–118
impediments, managing, 118–124 stable teams, 4–5, 44–45
improving, 115–134 stakeholder engagement and, 123
incremental changes versus quick storming, 42
benefits, 13 success, measuring, 80
intrinsic motivation, 25–26 teaching skills, 8–9
Iron Triangle, 146–148 team impacts, 141–143

182
 Index

Team Processes, 6 shared goals, Scrum Teams, 32–33

teamwork, 4–5 “silver bullet” for development
technical excellence, 10–11 speed, Scrum as, 170–171
time-boxes, 3, 34 sizing releases, 113
training, 126 skills/talents of team members,
transparency, 3–4, 144–145 24–27
Tuckman’s model of group skills, Scrum Team
development, 42 coaching skills, 10
value, measuring, 83–85 facilitation skills, 9–10
velocity, improving, 124 teaching skills, 8–9
“waste snakes,” 119–121 small releases, 113
working agreements, 29–30 solutions (emergent), business agility
self-assessments and, 157–160
answers, analyzing, 168 solving problems, experimenting
business agility, 161–162 with different approaches, 18–20
commitment (teamwork), 167 sourcing strategies, improving
continuous improvement, need for, organizations, 141–143
12–13 speed, improving, 124
courage (teamwork), 167 Sprint Backlogs, 59–60
Daily Scrums, 165 completing for Sprint success, 173
Development Teams, 164 Scrum Boards, 59–60
empiricism, 162–166 Sprint Burndowns, 61
focus (teamwork), 167 example of, 61
increments, 164 flow, 63
openness (teamwork), 167 Sprint Retrospectives, 61
Product Owners, 162–166 transparency, 63
respect (teamwork), 167–168 Sprint Goals, 33, 55–58
Scrum Teams, 162–163 business impact, achieving, 56–57
Sprint Planning, 163 compound Sprint Goals, 56
Sprint Retrospectives, 166 consensus, 56
Sprint Reviews, 165–166 creating, 55–57
Sprints, 163–164 Daily Scrums, 57–58
teamwork, 167–168 “Done” increments, 55–58
self-organizing teams, 4, 31–32, 35 focus of, 56–57
servant leadership managing, 56
Scrum Masters, 11–12 measuring, 56
Scrum Teams, 11–12 PBI, 56, 58–59
setbacks, dealing with, 43 Sprint Planning, self-assessments,
163

183
Index

Sprint Retrospectives, 166 Scrum Teams, 8–9

facilitating, 117–118 Team Processes, 6
Scrum Teams, developing/ teams
improving, 115–118 accountability, 33–34, 145
self-assessments, 166 adaptable teams, characteristics
setbacks, dealing with, 43 of, 46–47
Sprint Burndowns, 61 adjourning, 43
Sprint Reviews, 166 autonomy, 26
as Acceptance Review meetings, boundaries, 34–35
173–174 budgeting (iterative/incremental),
self-assessments, 165–166 150–152
setbacks, dealing with, 43 capabilities, 7–12, 124
value, 91 career paths, 140–141
Sprints, 107–108, 163–164, 174 coaching skills, 10
“Done” increments, 34, 174 collaborative teams, 4, 36–41
forecasting, 109–110 continuous improvement, need for,
improving, 111 12–13
length of, 109 control (illusion of), letting go,
one-day Sprints, 58–59 146
planning, 107–112 CoP, 126–127
preparing for, 174 cross-functional teams, 4
“Ready,” refining as, 111–112 developing/improving, 138
self-assessments, 163–164 Development Team, 28–30
success, measuring, 173 distributed teams, 143–144
value, improving, 89–90 emotional intelligence, 25–26
stability, build stability metrics, 69 empiricism, 3–4
stable teams, 4–5, 44–45 facilitation skills, 9–10
stakeholder feedback, value, 91–92 feedback loops, 3
stakeholders, impediments, forming, 42
managing, 123 foundations, building, 23–47
statements (purpose), 31 identity, 5, 23–24
status meetings, Daily Scrums as, intrinsic motivation, 25–26
172–173 motivation to change, 116–117
storming, Scrum Teams, 42 norming, 42
support (product), outsourcing, 142 productive teams, characteristics
of, 46–47
T progress, 42–45, 80
TDD (Test-Driven Development), 65 purpose of, 5, 26
teaching skills purpose statements, 31
Scrum Masters, 132 selecting team members, 27–28

184
 Index

self-assessments, 162–163 feedback loops, 3

self-organizing teams, 4, 31–32, 35 Scrum Teams, 3, 34
servant leadership, 11–12 tracking
setbacks, dealing with, 43 impediments, 121–122
shared goals, 32–33 interruptions, 122
skills/talents of team members, progress
24–27 Scrum Boards, 59–60
sourcing strategies, 141–143 Sprint Burndowns, 61
stable teams, 4–5, 44–45 training, Scrum Team development,
storming, 42 126
success, measuring, 80 transformations (agile), improving
teaching skills, 8–9 organizations, 152–153
team impacts, 141–143 transparency, 144–145
Team Processes, 6 trends
teamwork, 4–5 quality of “Done” increments,
Tuckman’s model of group measuring, 69–70
development, 42 value, 90
working agreements, 29–30 trust
teamwork, 167–168 building, 37–38
commitment, 167 collaborative teams, 36–38
courage, 167
U
focus, 167
undone Scrum, 14
openness, 167
user outcomes, PBI and, 85–87
respect, 167–168
User Stories, 88–89
self-assessments, 167–168
technical debt, 70–73 V
DoD, 71 value
“Done” increments, 70–73 defined, 77–78
examples of, 70 fast delivery versus feedback,
PBI, 71–72 78–79
repayment, visibility of, 73 improving during Sprints, 89–90
transparency, 71–72 learning as, 90–91
visualizing, 73 measuring, 83–85
technical excellence, Scrum Teams, personas, 81–82
10–11 Product Roadmaps, 82
testing, levels of, 67 product value, 80–82
throughput charts, 63 Product Vision, 81–83
time-boxes Sprint Reviews, 91

185
Index

value (continued) W
stakeholder feedback, 91–92 WIP (Work In Progress)
trends, 90 flow, measuring/analyzing, 63
User Stories, 88 limiting, 62–63
velocity, improving, 124 tracking, 63
visualizing transparency, measuring/
progress analyzing, 63
Scrum Boards, 59–60 working agreements, 29–30
Sprint Burndowns, 61
technical debt, 73
X –Y – Z
waste, 119–121
zombie (mechanical) Scrum, 14
voting (Roman), collaborative teams,
40–41

186