Beyond Requirements

The Agile Software

Development Series
Alistair Cockburn and Jim Highsmith, Series Editors

Visit informit.com/agileseries for a complete list of available

publications.

gile software development centers on four values, which are

A identified in the Agile Alliance’s Manifesto*:
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
The development of Agile software requires innovation and responsiveness,
based on generating and sharing knowledge within a development team
and with the customer. Agile software developers draw on the strengths of
customers, users, and developers to find just enough process to balance
quality and agility.
The books in The Agile Software Development Series focus on sharing the
experiences of such Agile developers. Individual books address individual
techniques (such as Use Cases), group techniques (such as collaborative
decision making), and proven solutions to different problems from a variety of
organizational cultures. The result is a core of Agile best practices that will
enrich your experiences and improve your work.
* © 2001, Authors of the Agile Manifesto
Beyond Requirements
Analysis with an Agile Mindset

Kent J. McDonald
Illustrations by Jeff Rains

New York • Boston • Indianapolis • San Francisco

Toronto • Montreal • London • Munich • Paris • Madrid
Capetown • Sydney • Tokyo • Singapore • Mexico City
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 author 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 [email protected] or (800)
382-3419.
For government sales inquiries, please contact [email protected].

For questions about sales outside the U.S., please contact [email protected].
Visit us on the Web: informit.com/aw
Library of Congress Cataloging-in-Publication Data
McDonald, Kent J.
Beyond requirements : analysis with an agile mindset / Kent J. McDonald ; illustrations by Jeff Rains.
pages cm
Includes bibliographical references and index.
ISBN 978-0-321-83455-3 (pbk. : alk. paper)—ISBN 0-321-83455-0
1. Decision making. 2. Requirements engineering. 3. Business requirements analysis. I. Title.
T57.95.M384 2016
658.4’0354—dc23
2015022866

Copyright © 2016 Pearson Education, Inc.

Illustrations by Jeff Rains
All rights reserved. Printed in the United States of America. 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. To
obtain permission to use material from this work, please submit a written request to Pearson Education, Inc.,
Permissions Department, 200 Old Tappan Road, Old Tappan, New Jersey 07675, or you may fax your request to
(201) 236-3290.
ISBN-13: 978-0-321-83455-3
ISBN-10: 0-321-83455-0
Text printed in the United States on recycled paper at RR Donnelley in Crawfordsville, Indiana.
First printing, September 2015
To all of those who asked, “Is the book done
yet?” Yes, yes it is.
This page intentionally left blank
Contents

Preface.................................................................................................................................xv
Acknowledgments........................................................................................................xxv
About the Author........................................................................................................xxvii

Part I: Ideas.............................................................................1
Chapter 1: Guiding Principles......................................................................................3
Introduction........................................................................................................................3
Deliver Value......................................................................................................................4
Collaborate..........................................................................................................................5
Iterate....................................................................................................................................7
Simplify.................................................................................................................................8
Consider Context..............................................................................................................9
Decide Wisely..................................................................................................................10
Reflect and Adapt..........................................................................................................11
Conclusion........................................................................................................................12
If You Remember Nothing Else........................................................................12
Chapter 2: Helpful Concepts......................................................................................15
Introduction.....................................................................................................................15
Needs and Solutions.....................................................................................................15
Outcome and Output....................................................................................................19
Discovery and Delivery..............................................................................................20
If You Remember Nothing Else........................................................................23
Chapter 3: Influence of Lean Startup.....................................................................25
Introduction.....................................................................................................................25
Customer Development..............................................................................................25
Build-Measure-Learn...................................................................................................29
Metrics................................................................................................................................31
Good Metrics..............................................................................................................32

vii
vi CONTENT

Things to Consider with Metrics......................................................................34

Creating Your Metrics...........................................................................................36
If You Remember Nothing Else........................................................................38
Chapter 4: Decision Making.......................................................................................39
Introduction.....................................................................................................................39
A Structure for Decision Making............................................................................39
Determine the Decision Maker.........................................................................39
Select a Decision Mechanism.............................................................................41
Determine What Information Is Needed......................................................42
Make a Timely Decision.......................................................................................43
Build Support with Peers/Stakeholders.......................................................45
Communicate the Decision.................................................................................45
Enact the Decision...................................................................................................46
Real Options.....................................................................................................................46
Cognitive Biases.............................................................................................................48
Elicitation....................................................................................................................49
Analysis........................................................................................................................51
Decision Making.......................................................................................................52
If You Remember Nothing Else........................................................................53
Chapter 5: Deliver Value.............................................................................................55
Introduction.....................................................................................................................55
Feature Injection...........................................................................................................55
Identify the Value....................................................................................................56
Inject the Features..................................................................................................59
Spot the Examples...................................................................................................61
Minimum Viable Product...........................................................................................63
Minimum Marketable Features..............................................................................65
If You Remember Nothing Else........................................................................67
Chapter 6: Analysis with an Agile Mindset...........................................................69
Introduction.....................................................................................................................69
What Is the Need?.........................................................................................................71
What Are Some Possible Solutions?.....................................................................71
What Should We Do Next?.................................................................................72
What Are the Details of This Part (i.e., Telling the Story)?.......................73
If You Remember Nothing Else........................................................................73
 CONTENT ix

Part II: Case Studies...........................................................75

Chapter 7: Case Study: Conference Submission System...................................77
Introduction.....................................................................................................................77
The Need...........................................................................................................................77
The Possible Solution(s)............................................................................................78
The Deliveries of Value...............................................................................................79
Define-Build-Test.....................................................................................................81
The Incident of the Themes................................................................................84
Agile2014....................................................................................................................90
Lessons Learned............................................................................................................92
Chapter 8: Case Study: Commission System........................................................95
Introduction.....................................................................................................................95
The Need...........................................................................................................................96
The Possible Solution(s)............................................................................................96
The Deliveries of Value...............................................................................................97
Lessons Learned............................................................................................................98
Chapter 9: Case Study: Data Warehouse.............................................................101
Introduction..................................................................................................................101
The Need.........................................................................................................................101
The Possible Solution(s)..........................................................................................102
The Deliveries of Value............................................................................................103
Lessons Learned.........................................................................................................110
Chapter 10: Case Study: Student Information System...................................111
Introduction..................................................................................................................111
The Need.........................................................................................................................111
The Possible Solution(s)..........................................................................................114
Lessons Learned.........................................................................................................118

Part III: Techniques.........................................................121

Chapter 11: Understanding Stakeholders..........................................................123
Introduction..................................................................................................................123
Stakeholder Analysis...........................................................................................123
User Analysis..........................................................................................................124
Stakeholder Map.........................................................................................................124
What It Is..................................................................................................................124
x CONTENT

An Example.......................................................................................................125
When to Use It.......................................................................................................126
Why Use It................................................................................................................126
How to Use It..........................................................................................................126
Caveats and Considerations.............................................................................129
Additional Resources..........................................................................................129
Commitment Scale.....................................................................................................129
What It Is..................................................................................................................129
An Example.......................................................................................................129
When to Use It.......................................................................................................130
Why Use It................................................................................................................130
How to Use It..........................................................................................................131
Caveats and Considerations.............................................................................132
Additional Resource............................................................................................132
User Modeling..............................................................................................................133
What It Is..................................................................................................................133
An Example.......................................................................................................133
When to Use It.......................................................................................................135
Why Use It................................................................................................................135
How to Use It..........................................................................................................136
Caveats and Considerations.............................................................................137
Additional Resources..........................................................................................137
Persona............................................................................................................................138
What It Is..................................................................................................................138
An Example.......................................................................................................138
When to Use It.......................................................................................................139
Why Use It................................................................................................................139
How to Use It..........................................................................................................139
Caveats and Considerations.............................................................................140
Additional Resources..........................................................................................140
Chapter 12: Understanding Context.....................................................................141
Introduction..................................................................................................................141
Purpose-Based Alignment Model........................................................................142
What It Is..................................................................................................................142
The Quadrants Explained.................................................................................143
An Example.......................................................................................................144
When to Use It.......................................................................................................145
Why Use It................................................................................................................145
 CONTENT xi

How to Use It..........................................................................................................145

Caveats and Considerations.............................................................................146
Additional Resource............................................................................................147
Six Questions................................................................................................................147
What It Is..................................................................................................................147
An Example.......................................................................................................148
When to Use It.......................................................................................................148
Why Use It................................................................................................................148
How to Use It..........................................................................................................149
Caveats and Considerations.............................................................................149
Additional Resource............................................................................................150
Context Leadership Model......................................................................................150
What It Is..................................................................................................................150
An Example.......................................................................................................154
When to Use It.......................................................................................................154
Why Use It................................................................................................................155
How to Use It..........................................................................................................155
Caveats and Considerations.............................................................................156
Additional Resource............................................................................................157
Chapter 13: Understanding the Need..................................................................159
Introduction..................................................................................................................159
Decision Filters............................................................................................................160
What It Is..................................................................................................................160
An Example.......................................................................................................160
When to Use It.......................................................................................................161
Why Use It................................................................................................................161
How to Use It..........................................................................................................161
Caveats and Considerations.............................................................................163
Additional Resources..........................................................................................163
Project Opportunity Assessment.........................................................................163
What It Is..................................................................................................................163
An Example.......................................................................................................164
When to Use It.......................................................................................................165
Why Use It................................................................................................................166
How to Use It..........................................................................................................166
Caveats and Considerations.............................................................................166
Additional Resource............................................................................................167
xi CONTENT

Problem Statement....................................................................................................167
What It Is..................................................................................................................167
An Example.......................................................................................................167
When to Use It.......................................................................................................168
Why Use It................................................................................................................168
How to Use It..........................................................................................................168
Caveats and Considerations.............................................................................169
Additional Resource............................................................................................169
Chapter 14: Understanding the Solution(s)......................................................171
Introduction..................................................................................................................171
Impact Mapping...........................................................................................................173
What It Is..................................................................................................................173
An Example.......................................................................................................173
When to Use It.......................................................................................................174
Why Use It................................................................................................................176
How to Use It..........................................................................................................176
Caveats and Considerations.............................................................................177
Additional Resources..........................................................................................177
Story Mapping..............................................................................................................177
What It Is..................................................................................................................177
An Example.......................................................................................................178
When to Use It.......................................................................................................178
Why Use It................................................................................................................178
How to Use It..........................................................................................................180
Caveats and Considerations.............................................................................182
Additional Resources..........................................................................................182
Collaborative Modeling............................................................................................182
What It Is..................................................................................................................182
An Example.......................................................................................................183
When to Use It.......................................................................................................184
Why Use It................................................................................................................186
How to Use It..........................................................................................................186
Caveats and Considerations.............................................................................188
Additional Resources..........................................................................................188
Acceptance Criteria....................................................................................................188
What It Is..................................................................................................................188
An Example.......................................................................................................189
When to Use It.......................................................................................................190
 CONTENT xii

Why Use It................................................................................................................190

How to Use It..........................................................................................................190
Caveats and Considerations.............................................................................191
Additional Resources..........................................................................................192
Examples.........................................................................................................................192
What It Is..................................................................................................................192
An Example.......................................................................................................193
When to Use It.......................................................................................................194
Why Use It................................................................................................................195
How to Use It..........................................................................................................195
Caveats and Considerations.............................................................................196
Additional Resources..........................................................................................196
Chapter 15: Organizing and Persisting Solution Information.....................199
Introduction..................................................................................................................199
Discovery Board..........................................................................................................200
What It Is..................................................................................................................200
An Example.......................................................................................................200
When to Use It.......................................................................................................201
Why Use It................................................................................................................201
How to Use It..........................................................................................................202
Caveats and Considerations.............................................................................203
Additional Resources..........................................................................................204
Definition of Ready.............................................................................................204
What It Is..................................................................................................................204
An Example.......................................................................................................204
When to Use It.......................................................................................................205
Why Use It................................................................................................................205
How to Use It..........................................................................................................205
Caveats and Considerations.............................................................................206
Additional Resources..........................................................................................206
Delivery Board.............................................................................................................206
What It Is..................................................................................................................206
An Example.......................................................................................................207
When to Use It.......................................................................................................208
Why Use It................................................................................................................208
How to Use It..........................................................................................................209
Caveats and Considerations.............................................................................210
Additional Resources..........................................................................................210
xi CONTENT

Definition of Done...............................................................................................211
What It Is..................................................................................................................211
An Example.......................................................................................................211
When to Use It.......................................................................................................211
Why Use It................................................................................................................211
How to Use It..........................................................................................................212
Caveats and Considerations.............................................................................212
Additional Resources..........................................................................................213
System Documentation............................................................................................213
What It Is..................................................................................................................213
An Example.......................................................................................................214
When to Use It.......................................................................................................214
Why Use It................................................................................................................214
How to Use It..........................................................................................................215
Caveats and Considerations.............................................................................215
Additional Resources..........................................................................................217

Part IV: Resources............................................................219

Glossary...........................................................................................................................221

References......................................................................................................................245
Index.................................................................................................................................249
Preface

What This Book Is About

I wrote Beyond Requirements to paint a picture of analysis in IT projects and
how it can be applied with an agile mindset to make those projects more
effective. For the purposes of this book I think of analysis as the activities
involved with

• Understanding stakeholders
• Understanding context
• Understanding the need
• Understanding the solution(s)
• Organizing and persisting solution information

Performing these activities with an agile mindset, which I explain in Chapter

1, best positions teams to satisfy stakeholder needs. As a result, I assume that
people are approaching work with an agile mindset (which is up to each
individual to adopt) and that they are using agile techniques. Most of the
techniques I describe can also be used in other environments, of course, but
they’re most effective when combined with agile approaches.

Who Is This Book For?

If you find yourself performing analysis on a project in order to make sure the
project is delivering the right thing, this book is for you. You may identify your-
self as a business analyst (or derivation of that title), product owner, product
manager, project manager, tester, or developer.
I chose to target those performing analysis activities or possessing analysis
skills rather than analysts as a role, or even analysts as a profession. While it is
true that the people who are most endowed with the analysis skill set are those
who generally fill an analyst role, I didn’t want the advice in this book to get
hung up on discussions such as, “The analyst does this, the developer does that,
the tester does this other thing.” I’d much rather focus on describing why and
when techniques are most appropriate and leave it up to you and your team to

xv
xvi PREFACE

determine who is the best person to do various activities. In many cases,

multiple people on your team will end up doing analysis in order to take
advantage of strong technical and business knowledge.
The business analyst role exists primarily because in the past several organi-
zations used a prescriptive, phase-based approach to software development. In
this approach, there was a time period in the project when the main work was
eliciting and documenting requirements. Since it made sense to structure the
software development organization according to how project work was done,
all the people doing work in the analysis phase were lumped together and called
business analysts. But gathering and documenting requirements didn’t generate
much respect for the people doing it. Members of the analysis community
longingly eyed the success project managers had enjoyed by proclaiming project
manage- ment a profession, and they chose to do the same.
A lot of good things have come from the “professionalization” of business
analysis, including more consideration of, training on, and attention to analysis
skills. However, the benefits are somewhat diluted by the effort required to
justify a separate profession for people who elicit, document, and manage
requirements, and the overspecialization that may result. That effort would
be better spent figuring out how analysis can be used to make projects more
successful.
That doesn’t change the fact that you have a business analyst title and you
have spent a considerable amount of your career honing your business analysis
skills. Where does that leave you? Looking at analysis as an activity more than
a role, title, or profession means that you can use your in-depth knowledge of
analysis techniques to help your teams solve the right problems in the right way
and help out with other activities on the project whenever possible.

To What Context Does This Book Apply?

This book focuses on the analysis that occurs on IT projects. An IT project
is any project that results in solutions, often involving software, that support
internal business processes, automate manual processes, or streamline current
processes. Examples include building a system to support the session
submission process for a conference, implementing a system to calculate and
deliver com- missions, reporting and data warehousing solutions, or
implementing a solution to track student information at a nonprofit school.
I chose this focus for a few reasons. First, activities labeled as business anal-
ysis and the role of business analyst seem to be more prevalent in IT projects
than in activities focused on product development. Second, most of the existing
literature in the analysis space seems to assume a product development context,
 PREFACE xvii

and the context of the IT departments of an organization strikes me as under-

served. Third, and probably most important, it’s where most of my experience
lies, so focusing on that topic gives me the opportunity to write from actual
experience.
As I describe how analysis with an agile mindset works on IT projects, I
won’t delve too much into how to do tried-and-true analysis techniques. There
are already enough resources that do a fantastic job of explaining those tech-
niques, and it dilutes the focus of this book. Instead, I’ll focus on why those
techniques are helpful and when they are best used. I do introduce a few tech-
niques from other skill sets not commonly known in analysis circles, and in
those cases I provide a more detailed description of how to perform that
technique. In all cases, I provide my favorite references for more information
about those techniques.
The word project has acquired a certain stigma in the agile community.
Those who apply that stigma feel as though the use of the word project implies
some of the downsides of the way that projects are managed in a waterfall
setting.
The term project often suggests the following:

• The temporary nature of projects is applied to the teams that work on

them. People are brought to the work instead of the work being brought
to the team.
• It takes a while to get an effort going due to the extensive chartering and
planning that come with trying to predict the future 6 to 12 months out.
• Even though projects are intended to be temporary (or maybe because of
that), they are rarely stopped once they get started. Sponsors and teams
get enamored with projects and become more reluctant to end a project
the longer it goes on.
• The project funding approach may encourage grouping multiple small
changes together in order to justify expenditure, increasing the time
before the changes are delivered to waiting stakeholders.

While these problems certainly exist, merely using the word project does not
ensure that they will happen. I reasoned that most people are familiar with the
idea of the project, and it would be more useful to explain that these patterns
are antipatterns and it’s possible for projects to work differently than to use a
new term for an existing concept and deal with all of the confusion that could
cause. As Deanna, one of my editors, suggested, I should just “own it” when it
comes to using the word project.
xvii PREFA

What Problem Is This Book Trying to Solve?

Analysis is often portrayed as eliciting and documenting requirements, fre-
quently in terms that sound a lot like asking people what they want and writing
it down. Deep philosophical discussions about analysis often center on the best
way to capture requirements: “Should I use a use case, or should I use a user
story?” Requirements are important, but they are a means to an end, not the
end in and of themselves. As I described previously, analysis is about under-
standing your stakeholders and their needs, identifying the best solution for
satisfying those needs in your particular context, and then building a shared
understanding of that solution. Requirements play a part in that work,
especially around describing the need, but they are certainly not the end
product.
One fundamental problem this book is trying to solve is how to determine
whether your IT project is doing the right thing and how analysis can help you
do that. It’s about changing the purpose of analysis from requirements
gathering and capture to problem solving and building shared understanding.
Along with that comes a substantial change in how your team views
requirements and designs. They are no longer deliverables that get tossed over
the wall to the people per- forming the next step in the process. Now both
requirements and designs are tools that teams can use to build a shared
understanding of the solution they seek to deliver in order to reach a desired
outcome.
A second fundamental problem this book attempts to solve is to demonstrate
how to do analysis in an agile setting. As many teams first adopt agile
approaches, they struggle with finding the right balance between identifying a
viable solution and describing that solution in too much detail too early. This
book aims to show you how to perform analysis in an iterative fashion so that
you can take advantage of the learning that occurs during development, testing,
and deployment. While doing so, it also demonstrates that many analysis
techniques are applicable in an agile setting with changes to when and to what
extent you perform those tech- niques. I sought to solve this problem because
many teams that adopt agile think analysis is no longer necessary, and as a
result they end up creating solutions that don’t solve the identified problem, or
don’t solve any problem at all.

How the Book Is Organized

This book is organized into three main parts to make it a bit easier to consume.
The first part, “Ideas,” covers the agile mindset and some key principles that
underlie the agile mindset and effective analysis. The second part, “Case
Studies,” features four case studies that show how to practically apply the ideas
in a variety of situations. The third part, “Techniques,” takes a deeper view of
 PREFACE xix

some tech- niques that are very helpful for using analysis in an agile setting.
xx PREFA

Part I: Ideas
The first section takes a look at some key ideas that I consider essential for
effectively performing analysis in an agile setting. These include the concepts
that describe an agile mindset, and some helpful concepts from outside tradi-
tional analysis thinking that supplement typical analysis techniques. Finally, I
build on those ideas to place analysis techniques in context.

Chapter 1: Guiding Principles

As I help teams adopt agile and tighten up their analysis approach, I find that
adopting the appropriate mindset is more important than mastering a specific
set of techniques. With the proper mindset and a great deal of self-discipline
a team can be successful with minimal process. Without the proper mindset,
teams find that they must continuously add process to aid the collaboration
that comes naturally to those who have the right mindset.
What is the proper mindset? There are a variety of perspectives on that. The
original definition of the agile mindset is encapsulated by the “Manifesto for
Agile Software Development” and the corresponding principles. Others have
expanded on those original ideas to describe the agile mindset, and I have done
the same, placing emphasis on aspects that encourage building the right thing. I
describe my perspective on the agile mindset through seven guiding principles:

• Deliver value
• Collaborate
• Iterate
• Simplify
• Consider context
• Decide wisely
• Reflect and adapt

Chapter 2: Helpful Concepts

I use this chapter to introduce some ideas that form the conceptual basis for the
following chapters. The ideas discussed include

• Needs and solutions

• Outcome and output
• Discovery and delivery
 PREFACE xxi

Chapter 3: Influence of Lean Startup

This chapter explores some concepts of Lean Startup and describes how these
concepts can be applied effectively to the context of IT projects. Those concepts
include

• Customer development
• Build-Measure-Learn
• Metrics

Chapter 4: Decision Making

This chapter discusses decision making in more detail, specifically a structure
for decision making, the idea of Real Options, and the cognitive biases I find
can get in the way of effective decision making.

Chapter 5: Deliver Value

In this chapter I discuss some key concepts surrounding value delivery, includ-
ing Feature Injection, minimum viable product, and minimum marketable
feature.

Chapter 6: Analysis with an Agile Mindset

While I’m not necessarily advocating a new “analysis process,” I wanted to
provide a general description of how analysis flows alongside the lifecycle of a
project. This chapter positions the techniques from Chapters 11 through 15 in
their usual location in the project lifecycle.
I don’t spend a great deal of time talking about this flow specifically because
it is not the same on every project, but going through the whole flow once helps
put the techniques into the proper perspective and helps to explain why certain
techniques make more sense in some contexts than in others.

Part II: Case Studies

In this part of the book, I share four stories intended to describe analysis in a
real-world setting. These stories illustrate the ways a variety of IT projects used
the ideas described in Chapters 1 through 6 and the techniques described in
later chapters. While I cannot cover every possible situation, I hope this mix
of case studies provides fairly broad coverage of the various environments in
which you may find yourself. In addition, they should furnish ideas for using
the same techniques in different situations and adjusting your approach based
on your current context.
xxii PREFA

Chapter 7: Case Study: Conference Submission System

This is the story of developing and maintaining the submission system for the
Agile2013 and Agile2014 conferences. This was a fairly straightforward project,
but it provides the opportunity to position several analysis techniques in their
proper context.

Chapter 8: Case Study: Commission System

This case describes what happened when a health insurance company undertook
a project to replace multiple commission systems. The case explores some good
tech- niques for projects involving off-the-shelf software and the tendency to gold
plate.

Chapter 9: Case Study: Data Warehouse

This case tells the story of a project to incorporate a new source of data into an
existing data warehouse. This story explores analysis in a business intelligence
project, another environment that can benefit from an agile mindset.

Chapter 10: Case Study: Student Information System

This case explores analysis in a nonprofit setting and focuses on the decisions
that need to be made when a project is initially being considered.

Part III: Techniques

In this section I describe a series of techniques that can be helpful in many dif-
ferent settings using my technique brief format. That format covers the
following aspects of a technique:

• What it is
• An example
• When to use it
• Why use it
• How to use it
• Caveats and considerations
• Additional resources

Chapter 11: Understanding Stakeholders

This chapter describes some techniques that are helpful for understanding the
people you work with. The first two techniques are useful for understanding
 PREFACE xxiii

the people whose needs you are trying to satisfy—better known as stakeholder
analysis. The other two techniques in this chapter will help you better under-
stand the people who are actually going to use the solution you deliver; let’s call
this user analysis. The techniques I cover include

• Stakeholder map
• Commitment scale
• User modeling
• Persona

Chapter 12: Understanding Context

Understanding context means familiarizing yourself with the nature of the busi-
ness and sharing that information with the rest of the team. You want to put
the project in the perspective of the overall organization and determine what
the project is intended to do. If the project does not support something explicitly
related to the organization’s strategy or ongoing operations, don’t do it.
This chapter introduces several techniques for understanding the
organization as a whole and using that information to guide decisions about
your projects. The techniques described in this chapter are often called strategy
analysis (formerly enterprise analysis) in the analyst community.

• The Purpose-Based Alignment Model

• Six questions
• The Context Leadership Model

Chapter 13: Understanding the Need

A key and often overlooked aspect of IT projects is figuring out the real
need that must be satisfied, determining if it is worth satisfying, and sharing
that understanding with the entire team. If those activities were done more
frequently, the story told about IT projects would undoubtedly be much
brighter.
In this chapter, I introduce a set of techniques that I have found very helpful
for performing those activities:

• Decision filters
• Project opportunity assessment
• Problem statement
xxi PREFA

Chapter 14: Understanding the Solution(s)

Once we understand the need we’re trying to satisfy and we’ve determined that
it’s worth satisfying, we should investigate possible solutions. The plural form
is intentional. Project teams often limit themselves by focusing on one possible
solution too soon instead of leaving their options open. In many cases there are
multiple options.
In this chapter I identify a variety of techniques for exploring multiple solu-
tions and describing the solutions that seem best, all in a way that is meaningful
for everyone working on the project:

• Impact mapping
• Story mapping
• Collaborative modeling
• Acceptance criteria
• Examples

Chapter 15: Organizing and Persisting Solution Information

This chapter describes techniques that help teams visualize progress and the
aspect of the solution they are working on, as well as a way to persist key infor-
mation about the solution for future reference. The techniques described in this
chapter include

• Discovery board
• Definition of ready
• Delivery board
• Definition of done
• System documentation

Part IV: Resources

In this final part of the book, I provide a couple of resource sections that sum-
marize key definitions and reference sources collected from the rest of the book.

Glossary
It’s always a good practice to establish a common language for your projects.
Since I am trying to be very specific about how I refer to certain concepts, and
 PREFACE xxv

in the interest of eating my own dog food, I decided to establish a glossary for
Beyond Requirements. This should help me be consistent in my use of certain
words, or at least give you a chance to catch me if I am inconsistent. Words in
the glossary appear in bold the first time they are mentioned in the text.

References
Throughout the book I reference several great sources of additional informa-
tion about the topics I discuss. This section compiles all the references into a
single list. Take some time to check out the references listed here; there’s some
great stuff.
In addition to the resources included in the book, beyondrequirements.com
features additional thoughts on analysis with an agile mindset, new technique
briefs, and updates to the material in the book.
xxv PREFA

Acknowledgments

This is not the first book I have written, but it is the first I took on by myself, or
at least that’s what I thought the case was when I started. It turns out that while
I’ll be listed as the only author, this book would not have been possible without
the help of several people.
There are two people who played the biggest part in how the book looks
and reads. Jeff Rains created all the hand-drawn graphics in the book. It was
important that the graphics reinforce the idea of having a conversation at a
whiteboard. Jeff’s great work allowed me to get that message across while
allowing you to be able to read the graphics. Deanna Burghart provided the first
line of defense that prevented me from doing horrendous things to the English
language. I have worked with Deanna for several years as she edited my pieces
for ProjectConnections.com. I knew when I started working on this book a . .
. um . . . couple of years ago that I wanted her editorial help. She, as always,
did a great job helping me sound like me.
I have been fortunate in my professional life to work and interact with
brilliant people who look at things in a slightly different way and who do not
hesitate to share their perspective with me. Several of those people played a
part in this book, but it’s important that I thank three especially. It is truly an
honor and a privilege to be able to fall back on these three to discuss ideas and
ways to describe them. Gojko Adzic’s extensive review notes were an immense
help during the editing stage and helped me see things from a different and
better perspective. Todd Little reviewed most of the book during the final
editing stages and, as always, provided practical and insightful advice to help
me crystallize my revisions. Chris Matts, long a primary source of cutting-edge,
yet eminently practical thought in the space of analysis, generously discussed
several ideas for this book and was a key source of many of the more important
ones. My understanding of the nuances of analysis and IT project work is due
largely to being fortunate enough to know these three practitioners.
I was fortunate to receive feedback from a wide range of professionals.
Special thanks go to Robert Bogetti, Sarah Edrie, James Kovacs, Chris Sterling,
and Heather Hassebroek for reading and commenting on the entire draft. Their
comments were very helpful in shaping and refining my initial thoughts into
something that I hope is a bit more coherent. Thanks also to Diane Zajac-
Woodie, Deb McCormick, Brandon Carlson, Mary Gorman, Julie Urban,

xxv
xxvi ACKNOWLEDGMENTS

Pollyanna Pixton, Matt Heusser, Tina Joseph, and Ellen Gottesdiener, who all
gave feedback on aspects of the draft.
Finally, thanks to Chris Guzikowski, acquisitions editor at Addison-Wesley,
who had the patience to stick with me through the drawn-out writing process,
and Jeffrey Davidson, who didn’t let an opportunity go by without nagging me
about finishing the book. Jeffrey, I’m not sure if Chris put you up to that or not,
but I suspect he’s glad you did, regardless.
About the Author

Kent J. McDonald uncovers better ways of delivering value by doing it and

helping others do it. His years of experience include work in business analysis,
strategic planning, project management, and product development in a variety
of industries, including financial services, health insurance, performance mar-
keting, human services, nonprofit, and automotive. He is active in the business
analysis and agile software development communities helping people share
stories about what does and does not work.
Kent has a Bachelor of Science degree in industrial engineering from Iowa
State University and an MBA from Kent State University.
Kent is also a coauthor of Stand Back and Deliver: Accelerating Business
Agility.

xxvii
This page intentionally left blank
Chapter 8

Case Study: Commission

System

Introduction
McMillan Insurance is a midsize health insurance company located in a midsize
city in the middle of the United States. McMillan has grown through acquisition,
and until recently one of its practices was to let each company keep its own
iden- tity when dealing with anyone outside the walls of headquarters. This
included the relationships with independent agents and the resulting
commission struc- tures. This meant that Arthur, the manager of the
commissions area, had to deal with a slew of different very unique commission
rules down to the individual agent level, and the resulting hodgepodge of
commission “systems” required to administer those different commission plans.
McMillan has finished its acquisi- tion binge and now realizes that some
commonality needs to be introduced in many areas, including commissions.
Arthur was charged with making the commissions area more efficient, so his
first instinct was to find a new commission system that would allow him to
administer all the various commission plans in one place, while still maintaining
all the unique commission structures. He sat down with a couple of more expe-
rienced members of his staff, and they started scouring the Internet for possible
products. A quick search revealed several options. (Of course, this should have
been obvious just from the seven different software applications McMillan had
inherited from the acquired companies, only one of which was built in-house.)
It was at this point that they reached out to IT for some help figuring out
what to do. Arthur was a little hesitant to do that at first because he was
concerned that IT would want to build something in-house. He was pleasantly
surprised when Heather, a business analyst from IT on the team, suggested that
instead of immediately going out and looking for specific products they should
step back

95
9 CHAPTER 8 CASE STUDY: COMMISSION

and think about what need they were trying to satisfy. Heather and Arthur sat
down to discuss the current situation and what Arthur hoped to accomplish.

The Need
As a result of their conversation, Arthur and Heather identified the following
objectives:

• Reduce the time it takes to produce commission payments from one week
to two days.
• Reduce the time required to set up a new commission plan from six weeks
to one week (needed every time a new product is created).
• Reduce the time required to set up a new agent from one day to one hour.

They then discussed the characteristics of a desirable solution. As they were

talking, Heather used the Purpose-Based Alignment Model (Chapter 12)
to identify commissions as a parity activity, and Arthur realized that trying to
have unique commission rules for every agent was, in effect, overinvesting in
commissions. Data from the existing commission payments indicated that the
unique rules did not have a direct impact on what the agents sold, so they were
probably not worth the effort that Arthur’s area spent in creating and adminis-
tering them. Arthur made a note to talk to the sales managers about reducing
the complexity of the commission rules.
At this point a team was formed that included Arthur and some of the more
experienced members of his staff as well as Heather and a few others from IT.
Arthur and Heather described the objectives they had put together and then
worked with the team to create decision filters for the project, to make sure
everyone was on the same page.
Here are the decision filters they came up with:

• Will this reduce the cycle time for commission payments?

• Will this help us set up a commission plan faster?
• Will this help us set up a new agent faster?

The Possible Solution(s)

Once the team had a good understanding of what they were trying to accom-
plish, they decided they needed to identify options for realizing those objectives,
starting with reducing the time required for commission payments. They used
 THE DELIVERIES OF VALUE 97

Table 8.1 Desired Characteristics of New Commission Software

Characteristic
Required/
Optional
Accept inputs from multiple policy systems to determine commissions. Required
Create unique commission rules for each individual agent. Required
Support multiple hierarchies: some sales channels are organized Required
based on product, others are based on geography, some are based on
both product and geography.
Allow for adjustments to occur in the calculated commission rules. Required
Allow for manual determination of commission payments. Required
Create unique commission rules based on free-form attributes and Optional
specific values of those attributes.
Support multiple commission rules unique to the individual, unique to Optional
the policy.

impact mapping (Chapter 14) to help them identify options. Several options
came up, including simplifying the commission rules and consolidating the mul-
tiple commission systems into one. The team also identified multiple options for
dealing with the existing systems:

• Build something in-house.

• Revise the existing conglomerate.
• Purchase something.
• Outsource all commissions activity.
• Do nothing.

The team decided that the best route was to start with simplifying the rules
for commissions in one of the acquired companies to see if there was any impact
on sales. At the same time, they started the search for software to replace all of
the existing commission systems. Table 8.1 lists the characteristics that served
as criteria for the search.
The team included the optional characteristics as a way of seeing if any com-
monly used applications used complex rule logic, in case they found data to
support the need for unique commission rules.

The Deliveries of Value

The team split the work into a series of rounds. (They chose that term instead
of releases, because not every round involved deploying software.) They weren’t
9 CHAPTER 8 CASE STUDY: COMMISSION
9 CHAPTER 8 CASE STUDY: COMMISSION

Table 8.2 Rounds of Work

Round Contents
1 • Simplify the commission rules for Southern Comfort Insurance (SCI).
• Identify a commission system to purchase.
2 • Implement a commission system in-house.
• Use the commission system for McMillan agents (who already had
straightforward commission rules).
• Simplify the commission rules for Western Amalgamated Insurance
(WAI).
3 • Use the new commission system for SCI.
• Phase out the existing commission system for SCI.
• Simplify the commission rules for Eastern Agrarian Insurance (EAI).
4–N • Roll out the commission system to the remaining units.
• Simplify the commission rules for the remaining units.
• Phase out the existing commission systems.

sure how many rounds they would have at the beginning, but they knew they
would be organized along the lines shown in Table 8.2.
The team figured that after the first couple of rounds they would simplify
rules and move the units to the new commission system at the same time. They
staggered the first few so that they could isolate the changes and get a sense of
what impact those changes had on sales.

Lessons Learned
The effort is still going on at the time of this writing, but the team has already
learned several lessons:
Not all problems require a technical solution. The team found that simplifying
the commission rules helped reduce the amount of time required to process
commissions a great deal and confirmed their suspicions that unique rules did
not have a large impact on sales agent behavior. Even so, the team decided it
would be good to consolidate all the processing on a single system.
You may not realize how good you have it on your side of the fence . As the
team started their search for a new commission system, they decided to include
the five purchased systems they were already using to administer parts of their
commissions. They found that as a result of simplifying commission rules, one
of the systems they already had fit the bill nicely for what they were trying to
do. They had to upgrade that commission system several versions, but once
they
 LESSONS LEARNED 99

did, they found that their work mainly consisted of creating new interfaces for
any data they didn’t have in that system already.
Commercial off-the-shelf (COTS) systems often contain good industry practices.
When the team picked the commission system, they found they could use that
unit’s commission process for all the other units as well. That process was one
suggested by the developers of the existing commission system. Switching to
that process for all the units provided even more improvement in overall com-
missions processing and eased the transition effort since the team didn’t have to
come up with new processes for each unit.
Don’t forget change management. Just because the team didn’t have to come
up with new processes didn’t make the change completely turnkey. The com-
missions team did not have much trouble with the change, since over half of the
team was involved on the project to switch commission systems, but they had
a bit of change management to do with the agents. When they found out that
commission structures were changing, most of the agents complained. Loudly.
The team found that the best way to help the agents adapt to the change was to
give them examples of their own commissions under both the old and the new
structures. Most of the agents found that their commissions would stay con-
sistent, or even increase. The only agents whose commissions decreased were
those few who had studied the old plans enough to use loopholes to maximize
their revenue. These agents were among the highest compensated but were
only middle of the pack in terms of actual sales.
Don’t overlook interdependencies with other efforts. The team originally
thought they would have to do a lot of work to interface with a new set of
systems for each unit they brought onto the new commission system. Shortly
into the project, the team caught wind that the accounting and new business
systems were also undergoing projects to make things more uniform. The
commissions team got together with the other two teams and synced their
rollout plans so they affected the same units in the same order, though not
necessarily at the same time. That meant that the commissions team did not
have to build new interfaces for every additional unit; they just had to revise the
ones they had already built.
This page intentionally left blank
Index

A
The Agile Culture: Leading through
Acceptance criteria
Trust and Ownership, 150
“On Acceptance Criteria for User
Agile mindset. See Analysis, with an
Stories,” 192
Agile mindset
“Acceptance Criteria vs. Scenarios,”
“Agile Models Distilled: Potential
192
Artifacts for Agile Modeling,” 188
additional resources, 192
Agile Project Leadership Network
appropriate use of, 190
(APLN), 12
caveats and considerations, 191–192
Agreed upon, characteristic of objectives,
definition, 188–189, 221
18
example, 189–190
Ambler, Scott, 140,
Growing Agile: A Coach’s Guide to
217 Analysis
Agile Requirements, 192
cognitive bias. See Cognitive bias,
guidelines for expressing business
analysis
rules. See RuleSpeak
of discovery and delivery, 20–23
mind map of, 189
of needs and solutions, 15–19
potential criteria, 190
of outcomes and outputs, 19–20
process description, 190–191
scope of, xv
purpose of, 188, 190
Analysis, with an Agile mindset
RuleSpeak, 191, 192
decision filters, identifying needs, 71
in system documentation, 216 delivery boards, 73
“On Acceptance Criteria for User diagram of, 70
Stories,” 192
information radiators, 73
“Acceptance Criteria vs. Scenarios,” 192
needs, identifying, 71
Acceptance test driven development. See
possible solutions, identifying, 71–72
Examples (Agile technique)
release backlog, 72–73
Actionable metrics
release planning, 72–73
appropriate use of, 36
story mapping, 72
definition, 221
user stories, 72–73
purpose of, 34
visualization boards, 73
Adaptation, characteristic of initiatives,
Analyst. See Business analyst
11–12
Anchoring effect
“Adventures in Scaling Agile,” 177
cognitive bias, 51
Adzic, Gojko
definition, 221
examples (Agile technique), 62–63,
APLN (Agile Project Leadership
196 focusing on the desired outcome,
Network), 12
4 impact mapping, 174, 175–176, 177
Appropriate practices
Specification by Example, 62
vs. best practices, 9–10
Agile Alliance, 213
definition, 221

249
25 IND

Arbitrary decision mechanism

The Agile Culture: Leading through
definition, 222
Trust and Ownership, 150
description, 41
“Agile Models Distilled: Potential
Ariely, Dan, 11, 48
Artifacts for Agile Modeling,” 188
Automated testing, 93
Behavior-Driven Development: Using
Availability heuristic
Examples in Conversation to
definition, 222
Illustrate Behavior—A Work in
description, 51
Progress, 197
“Best Practices for Agile/Lean
B Documentation,” 217
BABOK v3, definition, 222 Bridging the Communication Gap:
BACCM (Business Analysis Core Specification by Example and Agile
Concept Model) Acceptance Testing, 196
core concepts, 16–17 Commitment, 46
definition, 222 Commitment: Novel about Managing
Backbone, definition, 222 Project Risk, 204
Backlog items, in system documentation, Competitive Engineering, 18
216 “Comprehensive Documentation Has
Backlogs Its Place,” 217
failure to identity complete solutions, “Customer Guide,” 197
186 “Decision Filters,” 163
as wish lists, 186 “Definition of Done,” 213
Bandwagon effect. See also Groupthink “Definition of Ready,” 206
definition, 222 Discover to Deliver, 21
description, 49 The Entrepreneur’s Guide to
Barely sufficient approach Customer Development, 26
definition, 222 The Four Steps to the Epiphany, 26
description, 8–9 “Getting the Most out of Impact
Baseline, attribute of objectives, 18 Mapping,” 174
BDD (behavior-driven development). See Growing Agile: A Coach’s Guide to
Examples (Agile technique) Agile Requirements, 192
Behavior-Driven Development: Using How to Measure Anything, 32
Examples in Conversation to “How Visualization Boards Can
Illustrate Behavior—A Work in Benefit Your Team,” 204, 210
Progress, 197 “Impact Mapping,” 177
Berndtsson, Johan, 174 Impact Mapping: Making a Big
Best practices, definition, 9. See also Impact with Software Products,
Appropriate practices 177
“Best Practices for Agile/Lean “Inclusive Modeling: User Centered
Documentation,” 217 Approaches for Agile Software
Bezos, Jeff, 241 Development,” 188
Blank, Steve, 26, 230 Inspired: How to Create Products
Books and publications Customers Love, 163, 167
“On Acceptance Criteria for User “An Interview with the Authors
Stories,” 192 of ‘Stand Back and Deliver:
“Acceptance Criteria vs. Scenarios,” Accelerating Business Agility,’” 163
192 Lean Analytics, 32
“Adventures in Scaling Agile,” 177 Manage Your Project Portfolio, 69
 INDEX 251

“Personas, Profiles, Actors, & Roles:

Business case
Modeling Users to Target Success-
definition, 223
ful Product Design,” 137, 140
presenting required information, 43
Predictably Irrational, 48
Business domain model, definition, 223
Rath & Strong’s Six Sigma
Business goals. See Goals
Pocket Guide, 132
Business objectives. See Objectives
The Software Requirements Memory
Business rule catalog, in system
Jogger: A Pocket Guide to
documentation, 213
Help Software and Business
Business rules, guidelines for expressing.
Teams Develop and Manage
See RuleSpeak
Requirements, 169
Business value
Specification by Example: How
case studies, 57–58
Successful Teams Deliver the Right
definition, 56–57, 223
Software, 196
Feature Injection, 56–57
“Stakeholder Analysis,” 129
in Feature Injection, 56
Stand Back and Deliver:
Business value model
Accelerating Business Agility, 10,
definition, 223
147, 150,
Feature Injection, 57–58
157, 163
Thinking, Fast and Slow, 48
C
User Stories Applied: For Agile
Cagan, Marty, 163, 167
Software Development, 137
Campbell-Pretty, Em, 177
User Story Mapping: Discover the
Carlson, Brandon
Whole Story, Build the Right
adding themes, 84–86
Product, 182
budgeting Agile 2014, 90–92
“Using a Definition of Ready,” 206
define-build-test, 81–84
Box, George E. P., 61
identifying solutions, 78–81
Break the Model approach
Case studies
definition, 222
financial services company, 57
Feature Injection, 62
Mercury space program, 47
Bridging the Communication Gap:
minimum viable products, 64–65
Specification by Example and Agile
new payroll system, 60
Acceptance Testing, 196
nurse line service, 44
Budgeting
organizing conferences, 58
conference submission system case
Case studies, commission system
study, 90–91, 94
change management, 99
vs. estimating, 94
commercial off-the-shelf (COTS)
Build-Measure-Learn loop
systems, 99
definition, 223
deliveries of value, 97–98
description, 30–31
identifying solutions, 96–97
in the lean startup process, 29–31
interdependencies, 99
leap-of-faith assumptions, 31
lessons learned, 98–99
Business analysis, definition, 223
needs assessment, 96
Business Analysis Core Concept Model
non-technical solutions, 98
(BACCM)
rounds of work, 97–98
core concepts, 16–17
Case studies, conference submission
definition, 222
system
Business analysts
acceptance criteria, 189–190
cognitive bias, 49–50
adding themes, 84–90
definition, 223
25 IND

Case studies, conference submission

Cauwenberghe, Pascal Van, 58–59
system (continued)
Change
automated testing, 93
in the BACCM, 16
budgeting, 90–91
definition, 224
budgeting vs. estimating, 94
Change management, case study, 99
cards for, 169
Cleland-Huang, Jane, 66
conveying requirements, 82
Clustering illusion
define-build-test, 81–84
cognitive bias, 51
deliveries of value, 79–92
definition, 224
differentiating activities, 78
Cockburn, Alistair, 12, 222
distributed teams, 93–94
Cognitive bias
documentation, 91–92
affecting analysts, 49–50
examples (Agile technique), 193–194
affecting stakeholders, 49. See
feature files (example), 83–84
also Bandwagon effect; Curse
identifying solutions, 78
of knowledge; Herd instinct;
key user roles and activities, 79
Response bias
lessons learned, 92–94
definition, 224
letting approach dictate tools, 93
overview, 48–50
needs assessment, 77–78
Predictably Irrational, 48
project opportunity assessment, 165
Thinking, Fast and Slow, 48
public commenting, 87–88
Cognitive bias, analysis
reporting, 88
anchoring effect, 51
story map, 79, 88–89
availability heuristic, 51
story mapping, example, 179
clustering illusion, 51
stubbed identity service, 82
déformation professionnelle, 51
system documentation, example, 214
focusing effect, 51
team trust and transparency, effect on
frequency illusion, 51
documentation, 92
observation selection bias, 51
when even Scrum is overkill, 92
recency bias, 51
Case studies, data warehouse
Semmelweis reflex, 51
decision filters, 104
sharpshooter fallacy, 51
deliveries of value, 103–109
survivorship bias, 51
identifying solutions, 102–103
Cognitive bias, decision making
lessons learned, 110
false consensus effect, 52
needs assessment, 101–102
fist of five, 53
performance metrics, 109
group attribution error, 52
Case studies, student information system
irrational escalation, 52
cost-benefit analysis, 119
loss aversion, 53
examples, 142, 144
mitigating, 53
functional requirements, 117–118
sunk cost bias, 52–53
identifying solutions, 114–118
throwing good money after bad, 52
lessons learned, 118–119
Cognitive bias, elicitation
needs assessment, 111–114
affecting analysts, 49–50
Purpose-Based Alignment Model, 142,
bandwagon effect, 49
144
biases affecting stakeholders, 49
RFPs, 114–118, 119
confirmation bias, 50
six questions, 147–148
the curse of knowledge, 49
solutions looking for problems, 119
framing effect, 50
Causal metrics, 35–36, 36
herd instinct, 49
 INDEX 253

mirror imaging, 50
definition, 129, 224
mitigating, 49, 50
example, 129–130
observer-expectancy effect, 50
process description, 131–132
response bias, 49
purpose of, 124, 130
Cohn, Mike, 137
Rath & Strong's Six Sigma
Collaboration
Pocket Guide, 132
characteristic of initiatives, 5–7
Commitments vs. options, 46–47. See
vs. consensus, 6
also Real Options
definition, 224
Communicating a decision, 45–46
examples, 6
Company building, definition, 26, 224
teams vs. workgroups, 6
Company creation, definition, 26, 225
Collaborative modeling
Competitive Engineering, 18
additional resources, 188
Complexity attributes, Context
“Agile Models Distilled: Potential Leadership Model, 151
Artifacts for Agile Modeling,” 188 Complexity risks, mitigating, 156
appropriate use of, 184–186 “Comprehensive Documentation Has Its
caveats and considerations, 188
Place,” 217
context diagrams, 183
Conference organizing, case study, 58
data dictionaries, 183
Conference submission system. See Case
definition, 182–183, 224 studies, conference submission
example, 183–184 system
functional decomposition, 183 Confirmation bias. See also Observer-
glossaries, 183 expectancy effect
“Inclusive Modeling: User Centered definition, 225
Approaches for Agile Software description, 50
Development,” 188 Consensus, decision mechanism
logical data models, 183 vs. collaboration, 6
organization charts, 183
definition, 225
process description, 186–187
description, 41
process flow, 183
Constraint, attribute of objectives, 18
purpose of, 186 Context
report mockups, 183 in the BACCM, 16
state transition diagrams, 183, 184 characteristic of initiatives, 9–10
techniques, 183 definition, 225
value stream maps, 183 Context diagrams
wireframes, 183 collaborative modeling, 183
Commercial off-the-shelf (COTS) definition, 225
systems, case study, 99 Context Leadership Model. See also
Commission system. See Case studies, Purpose-Based Alignment Model;
commission system Six questions
Commit to, transform, or kill,
advantages of a two-by-two matrix, 9
definition, 224
appropriate use of, 154
Commitment, 46
caveats and considerations, 156–157
Commitment: Novel about Managing complexity attributes, 151
Project Risk, 204 complexity risks, mitigating, 156
Commitment scale. See also Stakeholder definition, 150, 225
engagement example, 151–154
appropriate use of, 130
process description, 154–157
caveats and considerations, 132 purpose of, 155
25 IND

Context Leadership Model (continued)

Decision filters
Stand Back and Deliver:
additional resources, 163
Accelerating Business Agility,
appropriate use of, 161
157
case study, 104
uncertainty attributes, 152
caveats and considerations, 163
uncertainty risks, mitigating, 156
“Decision Filters,” 163
Cooper, Alan, 138, 140
definition, 160, 227
Cooper, Brant, 26
example, 160
Core concept, definition, 225–226
identifying needs, 71
Correlated metrics, 35–36, 36
“An Interview with the Authors
COTS (commercial off-the-shelf) systems,
of ‘Stand Back and Deliver:
case study, 99
Accelerating Business Agility,’” 163
Croll, Alistair, 32, 34, 37
process description, 161–162
The curse of knowledge
purpose of, 161
cognitive bias, 49
role in delivering value, 4
definition, 226
Stand Back and Deliver:
Customer, definition, 226
Accelerating Business Agility,
Customer development
163
definition, 26, 226
“Decision Filters,” 163
in IT projects, 26
Decision leader
in the lean startup process, 25–29
vs. decider, 40
Customer discovery
definition, 227
definition, 26, 226
Decision maker, determining, 39–41
in IT projects, 28
Decision making. See also Cognitive bias
process description, 27
building support, 45
“Customer Guide,” 197
communicating the decision, 45–46
Customer validation, definition, 26, 226
determining a deadline, 47
Customer-problem-solution hypothesis,
determining required information, 42
definition, 226
determining the decision maker, 39–
41 enacting the decision, 46
D options vs. commitments, 46–47
Dalton, Nigel, 43
process structure, 39
Data dictionaries
Real Options, 46–48
collaborative modeling, 183
timely decisions, 43–44
definition, 227
Decision mechanisms
Data warehouse. See Case studies, data
arbitrary, 41
warehouse
consensus, 41
Deadlines, determining, 47
decider decides with discussion, 41
Decider
decider decides without discussion, 42
vs. decision leader, 40
delegation, 41–42
definition, 227
majority vote, 42
determining, 39–41
negotiation, 42
Decider decides with discussion
spontaneous agreement, 42. See also
definition, 227
Groupthink
description, 41
Deep Thought Academy. See Case
Decider decides without discussion
studies, student information system
definition, 227
Define-build-test, case study, 81–84
description, 42
Definition of done
Deciding wisely, characteristic of
additional resources, 213
initiatives, 10–11
appropriate use of, 211
 INDEX 255

definition, 211, 227

appropriate use of, 208
“Definition of Done,” 213
caveats and considerations, 210
example, 211
Commitment: Novel about Managing
process description, 212
Project Risk, 204
purpose of, 211–212
creating, 209
“Definition of Done,” 213
definition, 206–207, 228
Definition of ready
example, 207–208
additional resources, 206
process description, 209
appropriate use of, 205
purpose of, 208
caveats and considerations, 206
using, 209
definition, 204, 227
Deming, W. Edwards, 30
“Definition of Ready,” 206
Deming Cycle. See PDSA (Plan-Do-Study-
example, 204
Act) cycle
process description, 205
Deming Wheel. See PDSA (Plan-Do-
purpose of, 205
Study- Act) cycle
“Using a Definition of Ready,” 206
Denne, Mark, 65–67
“Definition of Ready,” 206
Denning, Steve, 57
Déformation professionnelle
Design
cognitive bias, 51
definition, 228
definition, 227
vs. requirements, 22–23
Delegation decision mechanism, 41–42
Design thinking
Delivering value
definition, 228
case studies, 79–92, 97–98, 103–109
in the development process, 22–23
characteristic of initiatives, 4–5
Differentiating activities
minimum viable product (MVP),
case study, 78
63–64
definition, 228
Delivering value, Feature Injection. See
identifying, 147
also MMF (minimum marketable
in the Purpose-Based Alignment
feature); MVP (minimum viable
Model, 143, 146
product)
Discover to Deliver, 21
Break the Model approach, 62
Discovery
business value, 56–57
analyzing, 20–23
business value model, 57–58
definition, 21, 228
examples, as specifications, 61–63
Discovery boards. See also Delivery
identifying value, 56–59
boards
Increase Revenue, Avoid Costs,
additional resources, 204
Improve Service (IRACIS), 56–57
appropriate use of, 201
injecting the features, 59–61
caveats and considerations, 203–204
Key Example pattern, 62
Commitment: Novel about Managing
overview, 55–56
Project Risk, 204
role of value points, 59
creating, 202
stakeholder expectations, 60–61
story mapping, 60 definition, 200, 228
Delivery example, 200–201
analyzing, 20–23 “How Visualization Boards Can
definition, 21, 228 Benefit Your Team,” 204,
Delivery boards. See also Discovery 210
boards additional resources, 210 process description, 202–203
analysis with an Agile mindset, 73 purpose of, 201–202
using, 202–203
Distributed teams, 93–94
25 IND

Documentation. See System

collaborative modeling, 183–184
documentation
commitment scale, 129–130
Domain, definition, 228
Context Leadership Model, 151–154
Domingues, Ingrid, 174
decision filters, 160
Done, definition of. See Definition of
definition of done, 211
done
definition of ready, 204
delivery boards, 207–208
E
discovery boards, 200–201
Elicitation
of the example Agile technique,
cognitive bias. See Cognitive bias,
193–194
elicitation
feature files, conference
definition, 228
submission system case study,
Elssamadisy, Amr, 163
83–84
Email, conveying requirements with, 82
impact mapping, 173–174
Enacting a decision, 46
impact mapping, student information
Enterprise, definition, 229
system case study, 173–174
The Entrepreneur’s Guide to Customer
metrics, 33
Development, 26
modeling user roles and descriptions,
Examples (Agile technique)
135
additional resources, 196–197
personas, 138
appropriate use of, 194–195
problem statement, 167–168
Behavior-Driven Development: Using
project opportunity assessment, 164–165
Examples in Conversation to
Purpose-Based Alignment Model
Illustrate Behavior—A Work in
quadrants, 142, 144
Progress, 197
six questions, 148
Bridging the Communication Gap:
stakeholder maps, 125
Specification by Example and Agile
story mapping, 178, 179
Acceptance Testing, 196
student information system case
caveats and considerations, 196
study, 142, 144
“Customer Guide,” 197
system documentation, 214
in a decision table, 193
user modeling, 133–135
definition, 192–193, 229
Exploratory metrics, 34–35, 36
example, 193–194
formats, 192
Framework for Integrated Test (Fit)
F
Facilitate, definition, 229
format, 192, 194–195
False consensus effect
Gherkin format, 192, 195, 197
in decision making, 52
Key Example pattern, 62
definition, 229
process description, 195–196
Feature, definition, 66, 229
purpose of, 195
Feature files (example), 83–84
Specification by Example, 62
Feature Injection
Specification by Example: How
Break the Model approach, 62
Successful Teams Deliver the Right
business value, 56–57
Software, 196
business value model, 57–58
as specifications, 61–63
case study, 60
system documentation, 216
definition, 229
in system documentation, 216
examples, as specifications, 61–63
Examples (used in this book)
identifying value, 56–59
acceptance criteria, 189–190
Increase Revenue, Avoid Costs,
collaboration, 6
Improve Service (IRACIS), 56–57
 INDEX 257

injecting the features, 59–61

Glenn, John, 47
Key Example pattern, 62
Glossaries, in collaborative modeling, 183
overview, 55–56
Glossaries, in system documentation
role of value points, 59
definition, 213, 231
stakeholder expectations, 60–61
for intermediate communication, 9
story mapping, 60
Glossary, of terms in this book, 221–243
Fichtner, Abby, 25–26
Goals
Financial services company, case study,
definition, 17, 231
57 Fist of five
role in delivering value, 4
in decision making, 53
Good practices. See Appropriate practices
definition, 229–230
Gorman, Mary, 21
Fit. See Framework for Integrated Test
Gottesdiener, Ellen, 21, 169
Fitzpatrick, Rob, 28
Group attribution error
Focusing effect
in decision making, 52
definition, 230
definition, 231
description, 51
Groupthink. See also Spontaneous
The Four Steps to the Epiphany, 26
agreement
Framework for Integrated Test,
bandwagon effect, 49
definition, 230
definition, 231
Framework for Integrated Test (Fit)
herd instinct, 49
format
Growing Agile: A Coach’s Guide to Agile
appropriate use of, 194–195
Requirements, 192
of examples (Agile technique), 192
Guidelines for expressing business rules.
Framing effect
See RuleSpeak
cognitive bias, 50
definition, 230
H
Frequency illusion
Herd instinct. See also Groupthink
cognitive bias, 51
definition, 231
definition, 230
in elicitation, 49
Functional decomposition
High influence/high interest stakeholders,
collaborative modeling, 183
128
definition, 230
High influence/low interest stakeholders,
Functional requirements, case study,
128
117–118, 119
Holst, Darrin
Functionalist, definition, 230
adding themes, 84–86
G budgeting Agile 2014, 90–92
define-build-test, 81–84
Gamestorming, 129
identifying solutions, 78–81
Geary, Chris, 46, 204, 210
How to Measure Anything, 32
“Get out of the building” technique
“How Visualization Boards Can
definition, 230
Benefit Your Team,” 204, 210
description, 28
Hubbard, Douglas, 32
“Getting the Most out of Impact
Mapping,” 174
I
Gherkin format
Impact mapping
definition, 231
additional resources, 177
examples (Agile technique), 192, 195
“Adventures in Scaling Agile,” 177
online description of, 197
align context, 175–176
Gilb, Tom, 18
appropriate use of, 173–176
25 IND

Impact mapping (continued)

Iteration
caveats and considerations, 177
characteristic of initiatives, 7–8
definition, 173, 231
definition, 232
discover context, 175
example, 173–174 K
experiment context, 175
Kahneman, Daniel, 11, 48
“Getting the Most out of Impact
Keogh, Liz, 188, 192, 197
Mapping,” 174
Key Example pattern, 62
“Impact Mapping,” 177
Kraft, Chris, 47
Impact Mapping: Making a Big
Impact with Software Products, L
177
Lacey, Mitch, 213
iterate context, 175
Lagging metrics, 35, 36
key questions, 173
Laing, Samantha, 192
process description, 176–177
Leadership style, determining. See
purpose of, 176
Context Leadership Model
useful contexts, 174–175
Leading indicator, definition, 233
“Impact Mapping,” 177
Leading metrics, 35, 36
Impact Mapping: Making a Big Impact
Lean Analytics, 32
with Software Products, 177
Lean startup
“Inclusive Modeling: User Centered
Build-Measure-Learn loop, 29–31
Approaches for Agile Software
customer development, 25–29
Development,” 188
metrics, 31–38
Increase Revenue, Avoid Costs, Improve
Lean TECHniques, 78
Service (IRACIS), 56–57
Leap-of-faith assumptions, 31
Information radiators, definition, 232.
Lessons learned, case studies
See also Delivery boards; Discovery
commission system case study, 98–
boards
99 conference submission system
Initiatives
case
definition, 232
study, 92–94
desirable characteristics of, 3
data warehouse case study, 110
Injecting features. See Feature Injection
student information system case
Inspired: How to Create Products
study,
Customers Love, 163, 167
118–119
Interdependencies, case study,
Linders, Ben, 206
99
Little, Todd
“An Interview with the Authors of ‘Stand
Context Leadership Model, 157
Back and Deliver: Accelerating
decision filters, 163
Business Agility,’” 163
Purpose-Based Alignment Model, 147
Inventory turn, definition, 232
six questions, 150
INVEST (independent, negotiable,
software prioritization, 91
valuable, estimable, small,
Logical data models
testable), 81
collaborative modeling, 183
IRACIS (Increase Revenue, Avoid
definition, 233
Costs, Improve Service), 56–57
Loss aversion
Irrational escalation
in decision making, 53
in decision making, 52
definition, 233
definition, 232
Low influence/high interest
IT (Information Technology), definition,
stakeholders, 128
232
Low influence/low interest
IT project, definition, 233
stakeholders, 128
 INDEX 259

M MMF (minimum marketable feature)

Maassen, Olav, 46, 204, 210 definition, 233
Majority vote decision mechanism description, 65–67
definition, 233
feature, definition, 66
description, 42
marketable, definition, 66
Mamoli, Sandy, 192
minimum, definition, 66
Manage Your Project Portfolio, 69
vs. minimum viable product, 66–67
Marketable, definition, 66
Modeling
Matts, Chris
BACCM (Business Analysis Core
Break the Model approach, 62 Concept Model), 16–17, 222
business value, 56
Models. See also Collaborative modeling;
business value model, 58 Context Leadership Model;
Commitment, 46 Purpose-Based Alignment Model;
discovery boards, 204, 210 User modeling
Feature Injection, 55–56 BACCM (Business Analysis Core
Real Options, 46, 237 Concept Model), 16–17
visualization board, 242 business domain model, 223
Maximizing work not done, 8–9 business value model, 57–58, 223
McDonald, Kent in system documentation, 216
decision filters, 163 wrong vs. useful, 61
discovery boards, 204, 210 The Mom Test
Purpose-Based Alignment Model, 147 definition, 234
system documentation, 217 description, 29
McMillan Insurance. See Case studies, MVP (minimum viable product)
commission system; Case studies, case study, 64–65
data warehouse definition, 234
Measurable, characteristic of objectives, description, 63
18 vs. minimum marketable features,
Mercury space program, case study, 47 66–67
Metadata, in system documentation, 214 purpose of, 64
Method, attribute of objectives, 18
Methodology, definition, 233 N
Metrics Name, attribute of objectives, 18
correlated vs. causal, 35–36, 36 Needs
creating, 36–37 in the BACCM, 16
desirable characteristics, 32–33 definition, 234
example, 33 origins of, 19
exploratory vs. reporting, 34–35, 36 separating from solutions, 19
leading vs. lagging, 35, 36 Needs assessment
in the lean startup process, 31–38 with an Agile mindset, 71
One Metric That Matters (OMTM), 37 case studies, 77–78, 96, 101–102,
qualitative vs. quantitative, 33, 36 111–114
for specific situations, 36–37 case study, 77–78
vanity vs. actionable, 33, 36 overview, 15–19
MindTools, 129 Needs assessment techniques. See also
Minimum, definition, 66 specific techniques
Mirror imaging decision filters, 160–163
definition, 234 problem statement, 167–169
in elicitation, 50 project opportunity assessment, 163–167
26 IND

Negotiation decision mechanism

Partner activities, 143
definition, 234
Patton, Jeff
description, 42
personas, 139, 140
Nickolaisen, Niel
story mapping, 178, 180–181, 182
Context Leadership Model, 157
user modeling, 137
decision filters, 160, 163
Payroll system, case study, 60
Purpose-Based Alignment Model, 142,
PDSA (Plan-Do-Study-Act) cycle
147
definition, 236
six questions, 150, 239
description, 30
Non-technical solutions, case study, 98
Performance metrics, case study, 109
Nurse line service, case study, 44
Permissions, in system documentation, 214
Personas
O
additional resources, 140
Objectives
appropriate use of, 139
attributes for, 18
caveats and considerations, 140
characteristics of, 18
definition, 138, 235
definition, 17, 234
example, 138
role in delivering value, 4
The Inmates Are Running the Asylum:
Observation selection bias
Why High-Tech Products Drive
in analysis, 51
Us Crazy and How to Restore the
definition, 234
Sanity, 140
Observer-expectancy effect. See also
“Personas: An Agile Introduction,”
Confirmation bias
140
definition, 234
process description, 139–140
in elicitation, 50
purpose of, 124, 139
OMTM (One Metric That Matters)
useful characteristics, 139
definition, 235
“Personas, Profiles, Actors, & Roles:
description, 37
Modeling Users to Target
Options vs. commitments, 46–47. See
Successful Product Design,” 137,
also Real Options
140
Organization (legal entity), definition, 235
Pivot, definition, 236
Organization charts
Pixton, Pollyanna
collaborative modeling, 183
Context Leadership Model, 157
definition, 235 decision filters, 163
determining a decision maker, 40–41 Purpose-Based Alignment Model, 147
Outcomes six questions, 150
analyzing, 19–20 Plan-Do-Study-Act (PDSA) cycle
definition, 235 definition, 236
Outputs description, 30
analyzing, 19–20 Pols, Andy, 58
definition, 235 Post-mortems. See Lessons learned
Predictably Irrational, 48
P Problem statement
Parity activities appropriate use of, 168
case study, 96 caveats and considerations, 169
definition, 235 components of, 167
vs. purpose, 146 definition, 167, 236
Purpose-Based Alignment Model, 143, example, 167–168
146 process description, 168
 INDEX 261

purpose of, 168

parity activities, 143, 146
The Software Requirements Memory
partner activities, 143
Jogger: A Pocket Guide to
“Who cares” activities, 144
Help Software and Business
Teams Develop and Manage Q
Requirements, 169
Qualitative metrics, 33, 36
Problem-solution fit, definition, 236
Quantitative metrics, 33, 36
Process flow
collaborative modeling, 183
R
definition, 236
Rath & Strong Management
in system documentation, 214
Consultants, 132
Product, definition, 236
Rath & Strong’s Six Sigma Pocket
Program, definition, 237
Guide, 132
Project documentation
Ready, definition of. See Definition of
definition, 237
ready Real Options
description, 216–217
definition, 237
Project opportunity assessment
description, 46–48
appropriate use of, 165
Realistic, characteristic of objectives, 18
caveats and considerations, 166–167
Recency bias
definition, 163, 237
in analysis, 51
example, 164–165
definition, 237
Inspired: How to Create Products
Reflection, characteristic of initiatives, 11–
Customers Love, 163, 167
12
process description, 166
Rehearsal. See Iteration
purpose of, 166
Release, definition, 237
questions for, 164
Release backlog
Projects
during analysis, 72–73
definition, 237
definition, 238
stigma associated with, xvii
Release planning
Public commenting, case study, 87–88
during analysis, 72–73
Pull systems, 56
definition, 238
Purpose vs. parity, 146
Report mockups
Purpose-Based Alignment Model. See
collaborative modeling, 183
also Context Leadership Model;
definition, 238
Six questions
Reporting, case study, 88
advantages of a two-by-two matrix, 9
Reporting metrics, 34–35, 36
appropriate use of, 145
Requirements
case studies, 96, 113, 119–120
case study, 117–118, 119
case study, 142, 144
conveying, 82
caveats and considerations, 146–147
definition, 238
definition, 237
vs. design, 22–23
description, 142–144
expressing, 89–90
process description, 145–146
Growing Agile: A Coach’s Guide to
purpose vs. parity, 146
Agile Requirements, 192
Stand Back and Deliver:
The Software Requirements Memory
Accelerating Business Agility,
Jogger: A Pocket Guide to
147
Help Software and Business
Purpose-Based Alignment Model, quadrants
Teams Develop and Manage
differentiating activities, 143, 146, 147
Requirements, 169
examples, 142, 144
26 IND

Resources. See Books and publications

Shewhart, Walter, 30, 236
Response bias
Simplification
definition, 238
barely sufficient approach, 8–9
effects on stakeholders, 49
characteristic of initiatives, 8–9
Retrospectives
maximizing work not done, 8–9
characteristic of initiatives, 11–12
perfect as the enemy of the good, 8–9
definition, 238
Six questions. See also Context
description, 11–12
Leadership Model; Purpose-Based
examples of. See Lessons learned, case
Alignment Model
studies
The Agile Culture: Leading through
RFP (requests for proposal), case study,
Trust and Ownership, 150
114–118, 119
appropriate use of, 148
Ries, Eric
case study, 148
The Lean Startup, 25, 29
caveats and considerations, 149–150
leap-of-faith assumptions, 31
definition, 147–148, 239
on metrics, 36 desired answers, 149
minimum viable product, 63–64 example, 148
Risk, definition, 238
process description, 149
Risk management, 204
purpose of, 148–149
Ross, Ron
SMART (specific, measurable, agreed
acceptance criteria, 191, 192
upon, realistic, time framed), 17–
RuleSpeak, 191, 192,
18
238 Rothman, Johanna
SME (subject matter expert)
commit to, transform, or kill, 224
definition, 241
Manage Your Project Portfolio, 69
in the development process, 12
on portfolio projects, 69
The Software Requirements Memory
Royce, Winston, 20–21
Jogger: A Pocket Guide to
RuleSpeak
Help Software and Business
acceptance criteria, 191, 192
Teams Develop and Manage
definition, 238
Requirements, 169
Solution identification, case studies,
S 78–81, 96–97, 114–118
Scope Solution identification, refining. See also
definition, 238 specific techniques
role in delivering value, 4 definition of done, 211–213
Scrum.org, 213 definition of ready, 204–206
Semmelweis, Ignaz, 239 delivery boards, 206–210
Semmelweis reflex discovery boards, 200–204
in analysis, 51 system documentation, 213–217
definition, 239 Solution identification techniques. See
Service, definition, 239 also specific techniques
Shared vision techniques. See also specific acceptance criteria, 188–192
techniques collaborative modeling, 182–188
decision filters, 160–163 examples (Agile technique), 192–197
problem statement, 167–169 impact mapping, 173–177
project opportunity assessment, 163–167 story mapping, 177–182
Sharpshooter fallacy Solutions
definition, 241 analyzing, 15–19
description, 51 in the BACCM, 16
 INDEX 263

definition, 239
definition, 239
identifying (case study), 78
“get out of the building,” 28
identifying, with an Agile mindset, 71–72
talking to, 28
origins of, 19
types of, 123. See also specific types
separating from need, 19
Stand Back and Deliver: Accelerating
Solutions looking for problems, 119
Business Agility, 10, 147, 150,
Specific, characteristic of objectives, 18
157, 163
Specification by example. See Examples
Startup, 240. See also Lean startup
(Agile technique)
State transition diagrams
Specification by Example: How
collaborative modeling, 183, 184
Successful Teams Deliver the Right
definition, 240
Software, 196
Story mapping
Sponsors
additional resources, 182
definition, 239
during analysis, 72
as source of needs, 19
appropriate use of, 178
Spontaneous agreement decision
as a backlog visualization tool, 181
mechanism
case study, 79, 88–89
definition, 239
caveats and considerations, 182
selecting a decision mechanism, 42
definition, 177, 240
Stakeholder analysis
as an elicitation tool, 180–181
definition, 240
example, 178, 179
types of stakeholders, 123–124. See
Feature Injection, 60
also specific types
process description, 180–181
“Stakeholder Analysis,” 129
purpose of, 178
Stakeholder engagement. See also
User Story Mapping: Discover the
Commitment scale
Whole Story, Build the Right
high influence/high interest,
Product, 182
128 high influence/low interest,
Storyboards, definition, 240
128 low influence/high interest,
Strategy, definition, 240
128 low influence/low interest,
Strategy analysis, definition, 240–241
128
Stubbed identity service, 82
Stakeholder expectations, Feature
Student information system. See Case
Injection, 60–61
studies, student information system
Stakeholder maps
Subject matter expert (SME)
with actions, 127–128
definition, 241
additional resources, 129
in the development process, 12
appropriate use of, 126
Sunk cost bias, 52–53
caveats and considerations, 129
Survivorship bias
definition, 240
in analysis, 51
description, 124–125
definition, 241
engagement levels, 127–128
System documentation
example, 125
acceptance criteria, 216
primary outcomes, 125
additional resources, 217
process description, 126–128
appropriate use of, 214
purpose of, 126
backlog items, 216
“Stakeholder Analysis,” 129
“Best Practices for Agile/Lean
uses for, 124 Documentation,” 217
Stakeholders
business rule catalog, 213
in the BACCM, 16
caveats and considerations, 215–217
building support for decision making, 45
26 IND

System documentation (continued)

“Comprehensive Documentation Has U
Its Place,” 217 Uncertainty attributes, 152
contents of, 213–214 Uncertainty risks, mitigating, 156
contribution to the desired outcome, 5 Units, attribute of objectives, 18
definition, 213–214, 241 User analysis
effects of teams, 91–92 definition, 242
example, 214 description, 124
examples (Agile technique), 216 User interfaces, in system documentation,
glossary, 213 214
metadata, 214 User modeling
models, 216 additional resources, 137
permissions, 214 appropriate use of, 135
process description, 215 brainstorming users, 133–134
process flows, 214 caveats and considerations, 137
project documentation, 216–217 definition, 133, 242
purpose of, 214–215 example, 133–135
user interfaces, 214 organizing and consolidating users,
134
T “Personas, Profiles, Actors, &
Target, attribute of objectives, 18 Roles: Modeling Users to
Teams Target Successful Product
definition, 241 Design,” 137
distributed, 93–94 process description, 135–137
organizational context. See Context purpose of, 124, 135–136
Leadership Model; Purpose-Based refining user roles, 135
Alignment Model; Six questions user roles and descriptions, example,
trust and transparency, effect on 135
documentation, 92 User Stories Applied: For Agile
vs. workgroups, 6 Software Development, 137
Texas sharpshooter fallacy User roles
definition, 241 case study, 79
description, 51 definition, 242
Themes user modeling, 133–135
case study, 84–90 User stories
definition, 241 during analysis, 72–73
Thinking, Fast and Slow, 48 definition, 242
Three amigos, definition, 241 User Stories Applied: For Agile Software
Throwing good money after bad, 52 Development, 137
Time framed, characteristic of objectives, User Story Mapping: Discover the Whole
18 Story, Build the Right Product,
Timely decisions, 43–44 182. See also Story mapping
Tools, dictated by your approach, 93 “Using a Definition of Ready,” 206
Triple constraints
definition, 241 V
role in delivering value, 4 Value
Tversky, Amos, 48 in the BACCM, 16
Two-pizza rule, 241 definition, 242
delivering. See Delivering value
identifying, case study, 57
 INDEX 265

Value points
definition, 242 W
in Feature Injection, 59 Waterfall planning technique,
identifying features, 59 20–21
Value stream maps “Who cares” activities
collaborative modeling, 183 definition, 242
definition, 242 Purpose-Based Alignment Model,
Van Cauwenberghe, Pascal, 58–59 144
Vanity metrics Williams, Walter, 47–48
appropriate use of, 36 Wireframes
definition, 242 collaborative modeling, 183
description, 34–35 definition, 243
Vision, shared. See Shared vision techniques Work groups
Visualization boards definition, 243
during analysis, 73 vs. teams, 6
definition, 242
Vlaskovits, Patrick, 26 Y
Yoskovitz, Benjamin, 32, 34, 37