CERTIFIED SCRUM PRODUCT WNER - Scrum Inc … · • Scrum formation • Autonomy • Transcendence...
Transcript of CERTIFIED SCRUM PRODUCT WNER - Scrum Inc … · • Scrum formation • Autonomy • Transcendence...
© 2
014
Sc
rum
In
c.
© 1993-2014 Jeff Sutherland
117,413 open Product Owner jobs in the United States - 2,641 in Massachusetts
CERTIFIED SCRUM PRODUCT OWNER THE ART OF DOING TWICE THE WORK IN HALF THE TIME
Global Investors, Constant Contact, Wellogic, Inova Solutions, Medco, Saxo Bank, Xebia, Insight.com,
SolutionsIQ, Crisp, Johns Hopkins Applied Physics Laboratory, Unitarian Universalist Association,
Motley Fool, Planon,itter, Paypal FinnTech, OpenView Venture Partners, Jyske Bank, BEC, Camp
Scrum, DotWay AB, Ultimate Software, Scrum Training Institute, AtTask, Intronis, Version One,
OpenView Labs, Central Desktop, Open-E, Zmags, eEye, Reality Digital, DST, Booz Allen Hamilton,
Scrum Alliance, Fortis, DIPS, Program UtVikling, Sulake, TietoEnator, Gilb.com, WebGuide Partner,
Emergn, NSB (Norwegian Railway), Danske Bank, Pegasystems, Wake Forest University, The
Economist, iContact, Avaya, Kanban Marketing, accelare, Tam Tam, Telefonica/O2, iSense/
Prowareness, AgileDigm, Highbridge Capital Management, Wells Fargo Bank, Deutsche Bank,
Hansenet/Alice, GlobalConnect, U.S. Department of Defense, Agile Lean Training, EvolveBeyond,
Good Agile, Océ, aragostTRIFORK, Harvard Business School, Schuberg Philis, ABN/AMRO Bank, Acme
Packet, Prognosis, Markem-Imaje International, Sonos, Mevion, Autodesk, First Line Software,
SCRUMevents, UPC Cablecom, NIKO, CWS-BOCO, BottomLine, Lean Enterprise Institute, Liberty
Global, Monster, Dartmouth University, Health Leads, Samsung R&D Center, Monster.com, Grameen
Foundation, Diplomat, Silicon Valley Leadership Network, Raytheon, Fidelity, John Deere, Mass IT, HP,
Lockheed, Saab Defense, European Union, EduScrum.com
© 2
00
6-2
01
5 S
cru
m In
c.
2© 2011 Scrum Inc.
As a class group we need
Introductions in order to work
together effectively
© 2
00
6-2
01
5 S
cru
m In
c.
Group Introductions
Who’s in the group?
• Line up across the room by level of Scrum experience
• In second dimension, line up across the room by job function
3
© 2
00
6-2
01
5 S
cru
m In
c.
Self-Organize Teams
• Based on line exercise, divide up into cross-functional teams.
• Then:
• Select a team name
• Select a Product Owner
• Select a Scrum Master
• Create a learning backlog – what do you hope to get out of the class individually and as a team
4
© 2
00
6-2
01
5 S
cru
m In
c.
Learning Backlog
5
To Do Doing Done
© 2
00
6-2
01
5 S
cru
m In
c.
“Release Plan” for Our Two Days
6
Day 1
– G
oo
d P
OD
ay 2
– G
reat
PO
Introduction
& Teams
7
Sprint 1
Scrum
Origins
5
The Scrum
Framework
6
Snowflake
Sales
8
Sprint 2
Principles
Behind
Scrum 7
The Product
Backlog
9
User Stories
10
Technical
Debt
7
Sprint 3
Product
Vision
12
Knowing the
Customer
9
Sizing &
Estimation
12
Business
Value
6
Scrum
Patterns
8
Sprint 4
Backlog
Refinement
9
Release
Planning
12
Questions &
Advanced
Topics 17
Course
Wrap‐up &
Retro 2
Scrum Roles
6
The Product
Owner Role
8
Daily Scrum
5
Product
Owner Role
in Meetings
11
A3
Exercise
10
ROI
10
Ready/Done
3
© 2
00
6-2
01
5 S
cru
m In
c.
Deploy Aggressive Scrum!
7
The faster you go, the more resistance you get!
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need to know the History & Context of Scrum in order to
appreciate its structure and logic
8
© 1993-2014 Jeff Sutherland
History and Context of Scrum
• Jeff Sutherland developed the methodology in 1993 at Easel Corporation and formalized it in 1995 with Ken Schwaber.
• Inspired by wanting to solve a really hard problem: SW projects kept getting later and later and more and more expensive – knew there had to be a better way.
• Formalizing the Scrum process was based on empirical process design.
9
© 1993-2014 Jeff Sutherland
Defined Process
• Traditional waterfall development is a “defined process.” A plan is defined at the beginning and precisely followed to the end.
• This assembly line approach requires minimizing deviations from plan to be successful.
• On average 65% of requirements change during software development causing waterfall projects to have an 14% worldwide success rate during the past decade. (Jim Johnson, Standish Group, 2011)
10Defined plan with one input and one output and (hopefully) no deviations
© 1993-2014 Jeff Sutherland
Empirical Process• Controlling a process that has many unexpected
changes requires introducing a feedback loop in order to inspect and adapt.
• Product is build iteratively and incrementally where each set of features is fully operational after a short cycle. Results are inspected and changes are made in repeated cycles as work progresses.
• Inspecting and adapting require full transparency of the work process to be successful.
• During the past decade, the worldwide success rate of software projects developed with empirical processes and been triple the success rate of defined projects.
11Empirical plan with a new input after each cycle
© 2006-2015 Scrum Inc.
12
© 2
00
6-2
01
5 S
cru
m In
c.
Ikujiro Nonaka: Grandfather of Scrum
13
The Japanese view Scrum as: • A way of doing • A way of being • A way of life
Sutherland, Kenji, Nonaka - Tokyo, Jan 2011
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Team Characteristics
• Scrum formation
• Autonomy
• Transcendence
• Mastery through Cross-fertilization
• Moving the Scrum downfield
• Built-in instability
• Self-organizing project teams
• Overlapping development phases
• “Multilearning”
• Subtle control
• Organizational transfer of learning
14
© 2
00
6-2
01
5 S
cru
m In
c.
The Future is Agile
Respond to
Change
Great
Teams
Delight the
CustomerWorking
ProductAgile Manifesto
15
© 2
00
6-2
01
5 S
cru
m In
c.
The Four Horseman of the Apocalypse
Impediments
Old Way of
Thinking
Not Ready
Not Done
Technical
Debt
Organizational
Debt
16
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need some
Hands-on Experience to motivate the discussion
17
© 2
00
6-2
01
5 S
cru
m In
c.
The Paper Snowflake Game
18
© 2
00
6-2
01
5 S
cru
m In
c.
How to Play the Game
19
Goal: Run a profitable business creating and selling paper snowflakes.
• The teams will construct snowflakes. They start with 5 Scrumbucks, a pair of scissors, and 3 sheets of paper.
• The team’s Product Owner transacts with customers (us) at the front of the room…
• We buy snowflakes for 1 - 5 “Scrumbucks” each, depending on how much we like them. We will build piles for each category
• We sell additional supplies: • 2 additional paper sheets - S$1 • An extra pair of scissors - S$3
• The Product Owner shares customer preference feedback with the team
• All building and transactions must take place within the 3min “build” cycle
• At the end of each Sprint, record: • The number of snowflakes built • The amount of revenue made • The net profit made
• We will work in 6min rounds…
© 2
00
6-2
01
5 S
cru
m In
c.
Record Your Results in Each Round
20
Round: Start 1 2 3 Total
A. Number of snowflakes
produced (Velocity)
B. Revenue from snowflake
sales
0
C. Revenue per snowflake
(B/A)
0
D. Total Cash 5
© 1993-2014 Jeff Sutherland
We Buy
Snowflakes
1‐5 coins
21
© 1993-2014 Jeff Sutherland
We Sell
2 papers for 1 coin
1 pair of scissors for 3 coins
22
© 2
00
6-2
01
5 S
cru
m In
c.
Creating a Paper Snowflake
23
© 2006-2015 Scrum Inc.
24
© 1993-2014 Jeff Sutherland
Debrief – Discuss within your teams
• How did you find out what to produce?
• Where did you spend most time? • Produce, learn, sell… ?
• What would you do differently if you would do this exercise again?
• What will you change in your way of working at your workplace based on reflection of this exercise?
25
© 1993-2014 Jeff Sutherland
26
© 2011 Scrum Inc.
As a PO, I must be able to articulate
the Elements of Core Scrum clearly so I can work effectively with
the team and stakeholders
© 1993-2014 Jeff Sutherland
Elements of Core Scrum
• Roles
• Meetings (ceremonies/rituals)
• Artifacts (social objects)
• Scrum Values (courage, commitment, focus, respect, openness)
27
© 1993-2014 Jeff Sutherland
Scrum has Three Roles1. Product Owner:
• Define and prioritize the features of the Product Backlog
• Decide on release date and content
• Responsible for the profitability of the product (ROI)
2. ScrumMaster • Facilitates the Scrum process and Team self-organization
• Removes obstacles
• Shields the team from interference
3. Team • Cross-functional (incl. testing)
• Self-organizing/-managing group of individuals, autonomy regarding how to achieve its commitments
• Typically 5-9 people
28
PO
T TT
SM
© 1993-2014 Jeff Sutherland
Scrum has Five Activities
• Sprint Planning
• Product Backlog must be READY
• Daily Scrum
• maximum 15-minutes, 3 questions
• Self-organize to improve performance
• Sprint Review
• Decide what is DONE. That determines velocity.
• Retrospective
• Identify the top process improvement and put in the backlog for the next sprint
• Backlog Refinement is essential before Sprint Planning
• Refine upcoming backlog to ensure it is READY
29
© 1993-2014 Jeff Sutherland
Scrum Makes Work Visible
• Product Backlog
• Sprint Backlog
• Scrum Board
• Burndown Chart
• Show work remaining
• Velocity
Scrum is designed to be self-reporting
30
© 1993-2014 Jeff Sutherland
The Sprint
What is it? • A cycle of work • A team-determined length of time in which the team
commits to producing a meaningful increment of work • Timeboxed and usually lasts 1-4 weeks
Why do it? • A fixed anchor • A tool that allows a team to calculate velocity • A period of time in which the team can derive lessons
for the future • A fixed planning horizon
31
© 2
00
6-2
01
5 S
cru
m In
c.
“Velocity” is the Key Metric in Scrum
32
8
5
3
5
5
5
3
5
5
8
ProductBacklog
8
5
3
5
5
SprintBacklog
8
5
3
5
5
SprintBacklog
Estimated
velocity
= 26 points
Actual velocity =
18 points
Done!
Done!
Done!
Almost done
Not started
Start of the Sprint End of the Sprint
The team pulls their
desired number of
stories into the
current sprint
Each user story includes an
estimated number of “points”
as a measure of effort
required to complete
User stories that are not completely
done at the end of the sprint do not
count toward velocity, and are carried
into the next sprint.
Teams can also pull stories from the
top of the product backlog if they
finish the full sprint backlog early
Adapted from materials by Henrik Kniberg
© 2
00
6-2
01
5 S
cru
m In
c.
Velocity is Plotted on the Sprint “Burndown Chart”
33
Burndown chart answers the question, “Are we on track to successfully
deliver this sprint’s output?”
100
200
300
400
Work remaining(story points)
Sprint
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
40#
30#
20#
10#
© 2
00
6-2
01
5 S
cru
m In
c.
© 2
01
2 S
cru
m In
c.
The Team-Level Scrum Process
Sprint
Release
Backlog
(points)
400
Refinement
34
© 1993-2014 Jeff Sutherland
35
© 2011 Scrum Inc.
As a PO, I need a clear understanding of
All the Roles in Scrum in order to work well together
© 1993-2014 Jeff Sutherland
Product Owner Owns The WHAT• Have a compelling product vision that is executable,
generates lots of cash, and arouses passion in the team, company, and customers
• Build a roadmap for rolling out the vision that everyone can see and sign up for
• Build a Product Backlog of “enabling specifications” that are “just enough, and just in time.”
• Spend half the time with customers, sales, and marketing in order to be the customer proxy on the team.
• Spend the other half working closely with the team clarifying specifications.
36
© 1993-2014 Jeff Sutherland
The Scrum Master Owns the HOW
• Scrum is a simple framework that requires consistent discipline
• Scrum Master owns the process
• Facilitates Daily Scrum
• Facilitates Sprint Planning
• Facilitates Retrospective
• Protects the team
• Removes impediments
37
© 1993-2014 Jeff Sutherland
Teams are:
• Cross-functional - most members can do more than one thing
• Self-organizing - they decide how they will work
• Self-managing - they decide how much work they can do in a Sprint
38
© 1993-2014 Jeff Sutherland
Management -> Leadership
• Need a business plan that works
• Provide resources the team needs
• Know the velocity of teams
• Remove impediments that slow teams down
• Provide challenging goals for the teams
• Hold Product Owners accountable for value delivered per point
• Hold Scrum Masters accountable for process improvement and team happiness
39
© 2006-2015 Scrum Inc.
40
© 1993-2014 Jeff Sutherland
Exercise: Project Manager/Leader
• As a team, write down all responsibilities of a traditional project manager/leader
• Put one responsibility on each sticky note
• 4 minutes
41
© 1993-2014 Jeff Sutherland
Exercise: Project Leader
• Arrange the sticky notes in these categories
• Product Owner
• ScrumMaster
• Team
• Waste
• Leadership
• 5 minutes
42
© 2
00
6-2
01
5 S
cru
m In
c.
43© 2011 Scrum Inc.
As a PO, I need a clear understanding of the
Product Owner Role in order to perform well
© 2
00
6-2
01
5 S
cru
m In
c.
A Good Product Owner Owns The WHAT…
Be Knowledgeable, Available, Decisive and Accountable • Knowledgeable about the customer and product
• Available to the team to clarify goals and desired output
• Empowered and able to make clear and rapid decisions to keep the team moving ahead
• Accountable for the commercial success of the product
Have and maintain a compelling product vision • Vision is clear and executable
• Vision generates lots of cash or other impact
• Shared vision sparks passion of team, company & customers
Build a “ready-ready” Product Backlog of “enabling specifications” that are “just enough, and just in time.”
• Spend half the time with customers, sales, and marketing.
• Spend the other half working closely with team clarifying specifications
44
© 2
00
6-2
01
5 S
cru
m In
c.
…But A Great Product Owner Does Much More
$Value
Time
• Delivers:
• The right product set to excite customers • At the right time • In the order that maximizes business value
• Responds dynamically to change faster than competitors
• Identifies and clarifies customer needs to remove uncertainty and maximize team velocity and value creation
• A Great Product Owner fundamentally changes an organization’s trajectory by winning in the market!
45
Product Owner
© 2
00
6-2
01
5 S
cru
m In
c.
The Product Owner Must Balance Multiple Product Attributes
46
© 2
00
6-2
01
5 S
cru
m In
c.
Right Order Maximizes Value
• A good Product Owner will get at least 20% more revenue by delivering the right features in right order
• 80% of value is in 20% of features. If you do this you will disrupt waterfall competitors
47
Mark Denne and Jane Cleland- Huang. Software by Numbers:
Low-Risk, High-Return Development. Prentice Hall 2003.
Billions of ways to
order Product
Backlog
$
© 2
00
6-2
01
5 S
cru
m In
c.
Trust is Essential for a Product Owner
• Product Owner will break trust if: • He tells people how to implement the product
• She assigns people tasks
• He changes the Sprint Backlog during a Sprint • The developers find out the Product Owner doesn’t really
know what the customer wants
• She tries to force team to do what they will not sign up for
• Any compromise of integrity or neglect of the team.
• The Product Owner is a special kind of leader and will be held accountable by the team for leadership qualities - honesty, integrity, clarity, and ability to align the whole company behind product creation.
48
© 2
00
6-2
01
5 S
cru
m In
c.
Product Owner is a Big Job
• Initially, one Product Owner may be able to generate ready backlog for several teams
• As team velocity increases, a Product Owner team, led by a Chief Product Owner, will be needed
• The Product Owner team are domain experts that describe the user experience, the screen shots, the workflow, the data requirements, the look and feel.
49
T TT T TT T TT
PO POCPO
PO
T TT T TT T TT
Modular Framework for Scaling Scrum
Product Ownership Cycle
Scrum Master Cycle
Backlog Prioritization
Backlog Decomposition &
Refinement
Release Planning
Team-Level Process
Release Management
Product & Release Feedback
Metrics & Transparency
Continuous Improvement & Impediment Removal
Cross-Team Coordination
Strategic Vision
Organization Level
Enterprise
Business Unit
Team
Leadership Action Team
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need to grasp the
Principles Behind Scrum In
order to understand why Scrum works
51
© 2
00
6-2
01
5 S
cru
m In
c.
© 2
01
3 S
cru
m In
c.
Why Scrum Works
52
We Leverage Systems Thinking
All activities are viewed through the lens of what creates value and optimizes productivity for the entire business, not just at one step of the process. We get more done when we achieve a steady state of flow
We Self-Organize Teams
Everyone, from the CEO to entry-level employees, is responsible for getting work done and empowered to decide how to do it. Any structure more than the minimum needed to work is WASTE
We Embrace Change
Change and uncertainty are not an inconvenience, but a source of opportunity. Organizations that manage uncertainty better possess a strategic competitive advantage
We FocusWe work best when we focus on one thing until it is DONE, all the way thru to a saleable product. Multi-tasking imposes switching costs on us, and is less efficient
1
2
3
4
5We Improve Over Time
Every day and in everything we do, we think about how to work better and then follow-through to remove the top source of waste. Our iterative work approach allows us to improve faster
© 2
00
6-2
01
5 S
cru
m In
c.
Velocity and Flow Exercise: The Dice Game
We will need: • A Team of 4 workers (dice turners) • A stack of polyhedral dice
The process: • Each worker represents one step of the
process • To complete the step, the worker must turn
the die so that their step number (i.e. “1” for step one) is facing up
• Once they have completed processing their batch of dice, they pass them to the next worker
The objective: • See how long it takes to process dice
in batches of all dice, half the dice, and 1.
53
D2 D1
D3 D4
PO
Penny Game
© 2
00
6-2
01
5 S
cru
m In
c.
Theory of Constraints – Smooth Flow
54
SM
PO
2. Fix bottleneck
1. Reduce intake
4. Fix next
Goal
Problem
Strategy
3. Increase intake
© 2014 Scru
m Inc.
Adding People to Late Projects Only Makes them More Late!
4 people
6 direct
communication
pathways
5 people9 direct
communication
pathways
6 people
15 direct
communication
pathways
Hours/$
0
8
15
23
30
Team size
2 4 6 10 17
Time
Cost
Source: http://www.qsm.com/process_01.html (491 projects)
This is called “Brook’s Law”Caused by deteriorating team communication saturation
© 2
00
6-2
01
5 S
cru
m In
c.
Remove “Waste” to Improve Efficiency
56
Muda (Wasted Effort)
Mura (Variability Waste)
Muri (Emotional Waste)
In‐Process Inventory
Overproduction
Extra Processing
Transportation
Wasted motion
Waiting
Correcting Errors
Unevenness
Inconsistency
Absurdity
Unreasonableness
Overburden
Partially implemented user stories, bugs or incomplete work that
cannot generate business value
Working on low‐value features that customers don’t care about rather
than saving capacity for high‐value work
Unnecessary management processes, redundant quality checks,
relearning others’ work
Handoffs across roles, teams, divisions and so on
Switching back and forth between tasks or “multi‐tasking,” delays from
interruption of the sprint
Delays, dependencies, capacity imbalances resulting from specialized
capabilities without cross‐training
Fixing bugs or other errors that should have been caught earlier or
systematically avoided to begin with
Varying granularity of work between team members
Different definitions of “Done” and process variations that make
defining “potentially shippable” product difficult
Stress due to excessive scope
Stress from an expectation that heroic actions to save the day are
normal
Stress due to excessive workload from “overhead” tasks
Sources of waste from Taiichi Ohno’s “The Toyota Production System”
© 2
00
6-2
01
5 S
cru
m In
c.
Deploy Aggressive Scrum!
57
The faster you go, the more resistance you get!
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need to understand the Product Backlog so I can build a better product and
deliver the most value quickly
58
© 2
00
6-2
01
5 S
cru
m In
c.
The Product Backlog
• An ordered list of everything that might be needed in the product • Composed of product “features” that describe the product • THE single source of requirements for any changes to be
made to the product and focus of team discussions
• The Product Backlog is shared across teams working on the same product to drive coordination
• There is only one Chief Product Owner who ultimately owns the product backlog
• For scaling we want one enterprise backlog which may have multiple products
59
• The Product Backlog must be “DEEP” • Detailed appropriately – clear enough to execute, but not more • Estimated – All items have an associated point estimate • Emergent – Backlog evolves to reflect new learning • Prioritized – Ordered to delight customers and deliver value
© 2
00
6-2
01
5 S
cru
m In
c.
Product Backlog Composed of Different “Product Backlog Items” (PBIs)
60
Customer
Features
Architecture
Team
Infrastructure
Research
Risk
Reduction
Detailed Design
Architecture
DB Schema
GUI
Testing
Server
Client
Wherever possible, backlog items should deliver complete vertical slices
of functionality across work layers
Backlog items include everything the team needs to do in one
ordered set of activitiesProduct
Backlog
Some teams also choose to include process improvements, bugs and technical debt fixes explicitly as
backlog items
© 2
00
6-2
01
5 S
cru
m In
c.
PB a Working Vision of the ProductUnlike the Sprint Backlog, it can Change at Any Time
• Any stakeholder can add anything to the Product Backlog
• Product Owner orders the backlog
• Backlog items that are lower priority can be defined more roughly
• The PO and team should spend time each sprint to refine the backlog
• Build in lessons learned from earlier work
• Refine feature definitions so they are “ready” when the time comes
61
8
5
35
5
5
35
5
8
Product
Backlog
8
5
35
5
Sprint
Backlog
Stable
Constantly Changing
© 2
00
6-2
01
5 S
cru
m In
c.
Product Backlog Improves Communication Effectiveness
62
(Ques
tion-a
nd-an
swer
)
(No ques
tion-an
swer)
2 people at whiteboard
2 people on email
2 people on phone
Video recording
Audio recording
Document
Communication effectiveness
Richness (”temperature”) of communication channel
Effective
HotCold
Ineffective
Source: research from McCarthy and Monk (1994) and Scrum Inc 2006-2015
Emphasis sh
ift fro
m docu
menta
tion to
conver
sation
2 people in video conference
© 2
00
6-2
01
5 S
cru
m In
c.
Backlog Maintenance
63
VV
2016
Q4 2015
Q3 2015
June 2015
May 2015
Apr 2015
V
T
2015
2016
2017
2018
V
© 2
00
6-2
01
5 S
cru
m In
c.
Steps to Creating a Product Backlog
1. What are the epics?
2. What are the stories that make up the epics?
3. Which epics are most important?
• MOSCOW, Kano, ROI, NPV, NPV/point
4. Prioritize the product personas
5. Walk the personas through the stories
6. This yields a single ordered list - the Product Backlog
7. Get the top of the Product Backlog READY for the first sprint
8. You only need two sprints of ready backlog to start sprinting
64
© 1993-2014 Jeff Sutherland
Not All Features Are Created Equal!
65
Valu
e t
o C
usto
mer
0.0000
12.5000
25.0000
37.5000
50.0000
Features
65% of features provide linle to no value,
are rarely used and/or aren’t actually
desired by the customer
The rest are OK,
but not as
important
80% of
value
typically
resides in
20% of
features
How can you tell ahead of time which features add value and which don’t?
© 2
00
6-2
01
5 S
cru
m In
c.
Delivering Customer Features Incrementally Can Drive Radically Better Value Delivery
66
Time, Cost, Features (%)
Value (%)
10 20 30 40 50 60 70 80 90 100
20
40
60
80
100
120
140
160
180
200
Better
© 2
00
6-2
01
5 S
cru
m In
c.
What Do We Build First?
67
Value
Effort
High Value High Effort
Low Value Low Effort
Low Value High Effort
High Value Low Effort
© 1993-2014 Jeff Sutherland
What We Build First Depends on Competitive Environment
• MoSCoW – Must have this – Should have – Could be nice to have – Won’t have this – maybe later
68
© 1993-2014 Jeff Sutherland
Kano Analysis
• Noriaki Kano: Quality is subjective – Kano analysis is a quality measurement tool used to prioritize
customer requirements based on their impact to customer satisfaction. [John Carter, isixsigma.com]
• We can divide perceived quality into four groups – Exciters: positive, beyond expectation – Performers (or Satisfiers): linear qualities – the more the better – Basic needs: we expect them to be there, if not we are
dissatisfied – Indifferent: we don’t expect them, and we don’t care. Some
might be annoying.
69
© 2
00
6-2
01
5 S
cru
m In
c.
Ordering of the Product Backlog
• Bubblesort Strategy
• Take first two items – which is more important?
• Take second and third – which is more important?
• Keep doing it until sort is complete
• Low Priority First Strategy
• Assume project does not complete one item – which item is given up?
• Assume another is not complete – which one is given up?
• Keep doing this and back into a forced ranking
• More Comprehensive Approaches
• Planning Poker
• Financial metrics - NPV/point
70
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need to write clear
User Stories to effectively
communicate what needs to be done.
71
© 1993-2014 Jeff Sutherland
Definition of an Epic• An Epic is a Product Backlog Item or User Story
that is too big to be completed in one Sprint
• Simple Epics may be small enough to be completed in as few as two Sprints
• Huge Epics may take the entire company several quarters or years to complete
• Simple Epics need to broken down so that the Team can deliver value in a given Sprint - Done at Backlog Refinement
• Larger Epics require the Product Owner to work with Leadership and the Team to create a Road Map so most valuable features created first
72
© 1993-2014 Jeff Sutherland
Epics and Business Value
• Epics are components of the enterprise’s vision
• Business value can best be estimated at this level
73
© 1993-2014 Jeff Sutherland
Epics as PBIs
• Most User Stories or PBIs as originally written are Epics
• Usually written by a Product Owner or a customer with knowledge of the product but not of the development process.
• Backlog Refinement meeting is where the Team works with the Product Owner to break the Epic down appropriately
74
© 2
00
6-2
01
5 S
cru
m In
c.
The Origin of User Stories
• User Stories derive from XP • Now widely used for all agile processes • While not required, most Scrum teams use User
Stories
• Written from the end user’s perspective • Helps Team visualize product end use
• Card • Template, notes
• Conversation • Face to face communication is part of the
specification
• Confirmation • Include internal acceptance tests
75
© 2
00
6-2
01
5 S
cru
m In
c.
User Story Templates
• As a <role> I would like to be able to <action> to achieve <business value>
76
http://storyfabricator.herokuapp.com/
© 2
00
6-2
01
5 S
cru
m In
c.
User Story Readiness Guidelines
77
Modified from Bill Wake – www.xp123.com
Product Backlog
Product vision
✔ I
✔ N
✔ V
✔ E
✔ S
✔ T
mmediately actionable
egotiable
aluable
stimable
ized to fit
estable
Free from external blockage?
Can be delivered independently?
Descriptive enough to support team debate and conversation?
Delivers customer or business-visible benefit?
Clear enough that team can estimate?
Divided into small enough blocks to complete within Sprint?
Clear acceptance criteria to know when it is “good enough?”
© 2
00
6-2
01
5 S
cru
m In
c.
From Product Vision to Executable Story: A User Story Hierarchy
78
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need to break down
User Stories so they are Ready for implementation.
79
© 2
00
6-2
01
5 S
cru
m In
c.
Books and Beyond
• We are building an application for a business that sells products such as books, movies, music, and greeting cards. Assume a physical store.
• As a Product Owner you have a story:
As a customer, I want to buy a product so that I can enjoy using it!
80
© 2
00
6-2
01
5 S
cru
m In
c.
Exercise:
• Your story is an epic that needs to be broken down into smaller stories
• As a customer, I want to buy a product so that I can enjoy using it!
• What is the first story you would implement?
• Get it ready:
• Immediately actionable
• Negotiable
• Valuable
• Estimable
• Size to fit
• Testable
• Any non-functional requirements?
81
© 2
00
6-2
01
5 S
cru
m In
c.
Slicing User Story Options Based on Value
• Slicing Requirements for Agile Success
• Ellen Gottesdeiner and Mary Gorman. Better Software Jul/Aug 2010
• Inspired by:
• Chris Matts and Olav Masson on real options and feature injection
• Bill Wake and others on story splitting
• Jeff Sutherland and others on ready requirements
• Dean Leffingwell on lean backlog
• Mike Cohn on minimizing team handoffs
http://www.ebgconsulting.com/Pubs/Articles/SlicingRequirementsForAgileSuccess_Gottesdiener-Gorman_August2010.pdf
82
© 2
00
6-2
01
5 S
cru
m In
c.
The Six Slicing Elements of a User Story
83
© 2
00
6-2
01
5 S
cru
m In
c.
User Role Options: Types and State
• What are possible user types?
• Individual Buyer
• Corporate Buyer
• Club Member Buyer
• Employee Buyer
• What are possible user roles?
• New
• Existing
• Anonymous
• Archived
• What combination yields the highest immediate value?
• Individual Anonymous Buyer
84
© 2
00
6-2
01
5 S
cru
m In
c.
Buyer Action Items
• To identify all possible buyer actions, consider “I want to buy a product.”
• Ask the Product Owner what typically happens for an Individual Anonymous Buyer.
85
© 2
00
6-2
01
5 S
cru
m In
c.
Buyer Action Items
• To identify all possible buyer actions, consider “I want to buy a product.”
• Ask the Product Owner what typically happens for an Individual Anonymous Buyer.
• Verify product cost
• Calculate tax amount
• Calculate total purchase amount
• Apply discount
• Apply wrapping fee
• Arrange for shipping
• Secure payment
• Adjust inventory
• Generate receipt
• Post payment to accounts receivable
86
© 2
00
6-2
01
5 S
cru
m In
c.
Select for Value
• What are the minimum requirements for the next delivery cycle?
87
© 2
00
6-2
01
5 S
cru
m In
c.
What are the Minimum Requirements for the Next Delivery Cycle?
• Verify product cost
• Calculate tax amount
• Calculate total purchase amount
• Apply discount
• Apply wrapping fee
• Arrange for shipping
• Secure payment
• Adjust inventory
• Generate receipt
• Post payment to accounts receivable
88
© 2
00
6-2
01
5 S
cru
m In
c.
Data Option Types and States
• What are product types?
• What are payment types?
• What are receipt types?
89
© 2
00
6-2
01
5 S
cru
m In
c.
Data Option Types and States: Select for Value
90
© 2
00
6-2
01
5 S
cru
m In
c.
Sliced and Diced Story (ready to discuss)
• As an individual anonymous buyer, I want to buy a new book with cash and receive a cash receipt.
91
© 2
00
6-2
01
5 S
cru
m In
c.
Step 4: Business Rule Options
92
© 2
00
6-2
01
5 S
cru
m In
c.
Step 5: Interface Type Options
93
© 2
00
6-2
01
5 S
cru
m In
c.
Step 6: Quality Attribute Options
94
© 2
00
6-2
01
5 S
cru
m In
c.
Step 7: Final Readiness Criteria
• Estimable
• Sized to fit
• Testable - acceptance tests
• Other company specific readiness criteria
95
© 2
00
6-2
01
5 S
cru
m In
c.
Sliced Story
• Immediately Actionable
• Negotiable
• Valuable
• Estimable
• Sized to fit
• Testable
96
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, the Team and I need clear
definitions of READY and DONE so the Team can complete the backlog quickly and
effectively
97
© 2
00
6-2
01
5 S
cru
m In
c.
Velocity
Teams Succeed by Driving READY Stories to DONE, while Removing Impediments
98D
ON
E!
RE
AD
Y!
Remove ImpedimentsSprint
Retrospective
Daily
Standup
© 2
00
6-2
01
5 S
cru
m In
c.
What does it mean to be READY?
1. Defined clearly enough that all members of the team understand what must be done • Includes team-developed tasking, if needed • Assume some ongoing discussion to refine, coordinate and clarify
2. Includes clear statement of resulting business value that allows the Product Owner to prioritize
3. Includes any required enabling specs, wire frames, etc.
4. Fully meet INVEST criteria for user stories • Estimated and sized to complete easily within one sprint
5. Free from external dependencies • I.e. there is nothing beyond the team’s control that must be done first
in order to complete the story
99
© 2
00
6-2
01
5 S
cru
m In
c.
Moving toward READY
• The Team regularly estimates items as part of “Refining”
the backlog – Expect to spend 5-10% of team time
– Often once a week at "The Wednesday Afternoon Meeting" – Update at the Sprint planning meeting
• The Team needs Product Owner support to clarify PBIs
• Product Owner supports and informs the Team, but may
direct them only through the product backlog
• The Scrum Master should enforce this!
100
© 2
00
6-2
01
5 S
cru
m In
c.
User Story Readiness Progression
101
Increasing Readiness
New Card Nursery
• All inputs accepted
• Promotion: Product Owner determines this story matches
product goals
Elementary School
• Analysts decompose
• User experience experts research context
• Business alignment needs identified
• Promotion: Matches release goals
Junior High
• Card details, acceptance criteria, UI pre‐work (wireframes,
visual and content prototypes
• Legal & compliance issues reviewed
• Promotion: Alignment with key stakeholders on features,
functions, and visuals
High School
• Ready for sprint
• Candidates for Release Planning/Sprint Planning
• Minimal refinement expected on core User Experience
© 2
00
6-2
01
5 S
cru
m In
c.
Refining the Product Backlog
102
Administrate users
Register new user
Edit existing user
Delete user
Find user
100 simultaneous
users
Operations manual
As a helpdesk operator I want to see who is logged
in
View Invoice in HTML, PDF, or
Excel format
100 simultaneous
users
Operations manual
As a helpdesk operator I want to see who is logged
in
View Invoice in HTML, PDF, or
Excel format
Register new user
Edit existing user
Delete user
Find user
100 simultaneous
users
Operations manual
As a helpdesk operator I want to see who is logged
in
View Invoice in HTML, PDF, or
Excel format
Source: Henrik Kniberg
© 2
00
6-2
01
5 S
cru
m In
c.
What Does it Mean to be DONE?
1. “Definition of Done” (DoD) decided on beforehand – along with acceptance tests • DoD can be standard across a group of common
stories, or defined specifically for unique ones
2. Done means the feature has been developed, tested AND meets all required acceptance tests
3. Ideally, Done means the feature could be shipped to a customer
4. Product Owner officially “accepts” Done features back from Team at the Sprint Review meeting
103
© 2
00
6-2
01
5 S
cru
m In
c.
Some Definitions of Done
104
Default Definition of Done
• Acceptance tested
• Release notes written
• Releasable
• No increased technical debtDefault Definition of Done
• Unit/Integration tested
• Ready for acceptance test
• Deployed on demo server = I haven’t messed up
the codebase or cut
corners on quality
Default Definition of Done
• Releasable
What else must be done before shipping the code? - For example ”customer acceptance test + user documentation” Why not? Who does it? When? What happens if a problem turns up? Burn up this work in release burndown!
Source: Henrik Kniberg
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need a simple system for
managing Technical Debt so that it does not build up and ultimately slow the team
down
105
© 2
00
6-2
01
5 S
cru
m In
c.
Clean & Simple Code
106
public class Dog { private final String name; private int woofCount = 0;
public Dog(String name) { this.name = name; }
public void woof() { ++woofCount;
}
}
import java.sql.Connection;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class Dog {
private Executor executor = Executors.newFixedThreadPool(18);
private int CACHE_SIZE = 50;
public Dog()
{
try
{
Class.forName("oracle.jdbc.ThinDriver");
connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");
statement = connection.prepareStatement("insert into Dog values (?, ?, ?)");
} catch (ClassNotFoundException e) {}
new Thread().start();
}
public void woof(Person woofCaller) {
Connection connection = null;
PreparedStatement statement = null;
try {
connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");
statement = connection.prepareStatement("insert into Dog values (?, ?, ?)");
statement.setLong(1, System.currentTimeMillis());
statement.setString(2, person.getName());
statement.setString(3, person.getPhoneNumber().getNumber());
statement.executeUpdate();
}
}
}
} Connection a = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");
b = a.prepareStatement("select * from Dog where name = '" + name + "'");
c = b.executeQuery();
if (c.next()) {
String foundName = c.getString("name");
PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount"));
Person person = new Person(foundName, phoneNumber);
return person;
} else {
return new Person("", null);
}
} catch (SQLException e) {
return null;
} catch (IllegalArgumentException x) {
throw x;
}
}
public List<Person> getAll() {
connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");
statement = connection.prepareStatement("insert into Dog values (?, ?, ?)");
statement.setLong(1, System.currentTimeMillis());
}
if (statement != null) {
if (c.next()) {
String foundName = c.getString("name");
PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount"));
Person person = new Person(foundName, phoneNumber);
return person;
} else {
Dog.java v0Dog.java v1.1 Big & hairy
Dog.java v1.2 Clean & simple
public class Dog { public static void main(String[] args) { System.out.println("WOOF 1!");
System.out.println("WOOF 2!");
}
}
Dog.java v1.0 Quick & dirty
Simple code: 1.Passes all tests 2.No duplication 3.Readable 4.Minimal
Simple is hard!
Source: Henrik Kniberg
© 2
00
6-2
01
5 S
cru
m In
c.
Technical Debt & Release Planning
107
1
Remaining story points
Sprint
2 3 4 5 6 7 8 9 10 11 12 13 14 15
100
200
300
400
Um... we’re done when we’re done!
We’ll be done by
sprint 10!
Sorry, we’re late!We should definitely by
done by sprint 12!
Source: Henrik Kniberg
© 2
00
6-2
01
5 S
cru
m In
c.
Dealing with Technical Debt
108
Vmax
Vactual
Velo
city
Time
Road to hell
First step Slow down Stop accumulating debt
Second step (optional)
Slow down even more Start repaying debt
Sustainable pace Increasing pace!
Definition of Done
• .... bla bla ....
• No increased technical debt
Definition of Done
• .... bla bla ....
• Technical debt decreased
Source: Henrik Kniberg
© 1993-2014 Jeff Sutherland © 2011 Scrum Inc.
As a PO, I need to participate in
Sprint Planning to get the team off to the right start of a sprint
109
© 1993-2014 Jeff Sutherland
The Product Owner Wants a READY Backlog Before Sprint Planning in Order to Increase the Team’s Velocity
Value Velocity
Daily Meeting
R E A D Y
D O N E
I M P E D IM EN TS
Sprint
110
© 1993-2014 Jeff Sutherland
Sprint Planning
• Review velocity and set Sprint capacity
• Adjust for vacations, holidays, etc.
• Forecast how many User Stories will be completed in the Sprint using Yesterday’s Weather • The team commits to do the best they can to hit the forecast. There
will be normal variation (about 20%).
• Select top-priority User Stories from Product Backlog • Select Sprint Goal
• Done collectively among team and PO, 1-2 sentence description of what the team plans to accomplish.
• Discuss and finalize Acceptance Criteria • Good Product Backlog Refining = at least 1 hour/week
of each Sprint
111
© 1993-2014 Jeff Sutherland
Roles in Sprint Planning
Product Owner • Present the backlog • Answers questions to clarify the backlog • Identify highest priority
Scrum Master • Facilitate the meeting • Confirm team capacity • Ensure stories are ready and have a definition of done
Team • Ask questions • Decide how much backlog to pull into the sprint • Agree on a sprint goal
112
PO
T TT
SM
© 1993-2014 Jeff Sutherland © 2011 Scrum Inc.
As a PO, I lead The Sprint Review to
ensure that we are delivering incremental value in each Sprint
113
© 1993-2014 Jeff Sutherland
Sprint Review Time Boxed to one hour per week of Sprint length
• This is when the state of the Product becomes transparent!
• The Team shows the Product Owner and other interested stakeholders what work was accomplished.
• The Product Owner reviews and accepts the work if it meets the Definition of Done.
• The main purpose is an in depth conversation between the Team and the Product Owner to see where the product is in the process, what they have learned, and what adaptations need to be made.
• As little time as possible should be spent preparing for the Sprint Review.
114
© 1993-2014 Jeff Sutherland
Product Owner’s Job at Sprint Review
• Get the right people in the room
• Be clear about what is Done and accepted and what is not
• Focus on positive feedback - Atta Boy!
• Lead an energetic discussion
• Get, filter, and prioritize feedback
• Adjust Product Backlog as needed
115
© 1993-2014 Jeff Sutherland © 2011 Scrum Inc.
As a PO I need to participate in the
Retrospective to capture learnings that allow us to become more efficient
116
© 1993-2014 Jeff Sutherland
The Retrospective – What is it?
• Team meeting that occurs at the end of the Sprint, following Sprint Review
• Questions for the team: • What worked well last Sprint?
• What could work better next Sprint?
• What process improvement would I like to try?
• As a team, everyone agrees on what change to try
• Inspect and Adapt
• Continuous improvement
117
© 1993-2014 Jeff Sutherland
Sprint Retrospective
Long term effect
118
Sprint
Velocity
4 5 6 7 8 9 10 11 121 2 3 13
Effective velocity over time (with retrospectives)
Effective velocity over time (without retrospectives)
Source: Henrik Kniberg
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need an introduction to
Key Scrum Patterns that can dramatically improve our performance
119
© 2
00
6-2
01
5 S
cru
m In
c.
Hyper productivity - at least 400% acceleration
• There are three proven methods for consistently moving teams into a hyper-productive state:
• Process Intensive: Systematic’s approach to get Ready Ready to be Done Done
• At CMMI Level 5 Systematic has every team follow the same rigorous process
• Coach Intensive: Shock Therapy
• A strong coach trains the team in the martial art of Scrum
• Team Intensive: Teams that Finish Early Acclerate Faster
• Use of a Pattern Language makes improvement Fast, Easy, and Fun
120
© 2
00
6-2
01
5 S
cru
m In
c.
Key Scrum Patterns Patterns are Not Required, but Enhance Scrum
121
Stable Teams ‐ How do you get started?
Yesterday’s Weather ‐ How do you pull backlog into a sprint?
Swarming ‐ How do you get work done quickly?
Interrupt Pattern ‐ How to deal with interruptions during the sprint?
Daily Clean Code ‐ How to get defect‐free product at sprint end?
Scrumming the Scrum ‐ How to ensure you improve continuously?
Happiness metric ‐ How do you ensure teams aren’t overburdened?
Teams that Finish Early Accelerate Faster ‐ How do you become hyper‐
productive?
www.scrumplop.org
© 2
00
6-2
01
5 S
cru
m In
c.
Exercise: Getting Work Done
122
Requirement: Write the Arabic numerals “1” to “10”, the Roman numerals “I” to “x”, and the Letter “A” to “J”
Time how long it takes to complete all steps using two different work policies…
Policy B: Limit Work in Process (WIP)
Arabic Roman Letter
1 i A
2 ii B
4 iv D
6 vi F
8 viii H
3 iii C
5 v E
7 vii G
9 ix I
10 x J
Policy A: Never keep a customer waiting
Arabic Roman Letter
1 i A
2 ii B
4 iv D
6 vi F
8 viii H
3 iii C
5 v E
7 vii G
9 ix I
10 x J
Total time = _____ Total time = _____
© 2
00
6-2
01
5 S
cru
m In
c.
Weinberg Table of Project Switching Waste
123
Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284.
© 2
00
6-2
01
5 S
cru
m In
c.
Pattern: Swarming Prioritizing Between Projects
124
Adapted from Henrik Kniberg
A1 A2 A3
B1 B2 B3
C1 C2 C3
Product A
Product B
Product C
A1 A2 A3B1 B2 B3C1 C2 C3
January February March April May June July
A1 A2 A3 B1 B2 B3 C1 C2 C3
Traditional strategy: ”Everything is important! Do it all at once!”
Agile strategy: ”Prioritize & focus!”
=
=
=
A
B
C
January February March April May June July
A
A
B
B
C
C
© 2
00
6-2
01
5 S
cru
m In
c.
Pattern: The Interrupt PatternDealing with the Unexpected
125
8
5
3
5
5
5
3
5
5
8
Product
Backlog
Beginning of sprint
8
5
5
3
Sprint
Backlog
Kaizen
5 Buffer
Support
Sales
Management
Now
Later
Low Priority
On Buffer Overflow ABORT, Replan, Dates Slip
PO
© 2
00
6-2
01
5 S
cru
m In
c.
Kanban• Some work is continuous flow - maintenance, call center,
anything with a ticketing system
• Kanban (team process) is:
• Make work visible
• Minimize work in progress
• Measure cycle time
• To get performance you need:
• Team
• Facilitative team leader
• Backlog management
• Daily meeting
• Retrospective with process improvement
• Good Kanban starts to look like Scrum
• Good Scrum with continuous deployment starts to look like Kanban
126
© 2
00
6-2
01
5 S
cru
m In
c.
© 2
014
Sc
rum
In
c.
© 2011-2014 Jeff Sutherland © 2
014
Sc
rum
In
c.
© 2011-2014 Jeff Sutherland
Therefore Wrap Scrum Around Kanban (like Toyota)
8
5
3
5
5
5
3
5
5
8
Improve Backlog
Support
Sales
Management
On Buffer Overflow ABORT, Replan, Dates Slip
Beginning of cycle
8
Backlog
Now
Later
Low Priority
Buffer 90
127
© 2
00
6-2
01
5 S
cru
m In
c.
Pattern: Scrum Emergency ProcedureKnow How to Respond when All Hell Breaks Lose
When team is more than 20% behind, execute the Scrum Emergency Procedure by mid-Sprint:
• Innovate - do something different • Identify impediments, root cause
analysis, remove impediments, otherwise ...
• Offload Sprint Backlog - get someone else to do it, otherwise ...
• Reduce scope in collaboration with Product Owner, or if this is not possible then ...
• Abort the Sprint • Recommended for new teams that need
to learn how to do better estimates128
buyinggoldcoins.net
© 2
00
6-2
01
5 S
cru
m In
c.
Pattern: Scrumming the Scrum
Use Scrum to Make Scrum Better
1. Identify top process improvement in the Scrum Retrospective (the kaizen)
2. Put the Kaizen in Sprint Backlog with measurable acceptance tests
3. Review the Kaizen at Sprint Review like any other story
Benefits:
• Finish the sprint early
• Pull forward future work
• Increase yesterday’s weather
• More backlog can be pulled
Teams that finish early typically accelerate faster.
129
During retrospective
, team members list likes/dislikes of previous
sprint
Discuss dislikes and how they
limit performance
Top improvement agreed on by
team
Create story for resolving,
with definition of
DONE
Add to top of sprint
backlog as the team kaizen
© 2
00
6-2
01
5 S
cru
m In
c.
Pattern: The Happiness Metric Focusing on Team Happiness to Guide Improvement
130
For each person:
1. On a scale of 1-5, how happy are you with your role in the company? 2. On the same scale, how happy are you with the company? 3. What specific events or activities increased your happiness? 4. What specific events or activities decreased your happiness? 5. What would increase your happiness moving forward?
For the team:
• What would make the team as a whole happier in the next sprint?
• Identify the top priority for the team • Execute the pattern “Scrumming the
Scrum”
The Happiness Metric is included as part of the Sprint Retrospective meeting…
© 2013 Scru
m Inc.
Employee Happiness is Important
• People are naturally motivated by intrinsic factors as well as traditional extrinsic ones
• This is not just “warm and fuzzy”…happier people do better work, and are more effective • Doctors in a positive mode show three times the intelligence
and creativity and diagnose 19% faster • Optimistic salespeople outsell pessimistic ones by 56% • Retail stores with higher employee life satisfaction generate
$21 more in earnings/SF than the other stores (Gallup)
Money Power Status
Purpose Mastery AutonomyIn
trinsic
Extrinsic
© 1993-2014 Jeff Sutherland
Team Happiness is a Leading Indicator of Performance
132
0.0000
7.5000
15.0000
22.5000
30.0000
0.0000
1.2500
2.5000
3.7500
5.0000
1 2 3 4 5 6 7 8 9101112131415
Happiness Velocity
First signs of trouble
• A happy Scrum team typically improves velocity by 5-10% each sprint
• Sudden and systematic declines in team happiness often precede rapid decline in velocity by a sprint or two
• Often indicates a major process challenge for the team, or an unresolved impediment
• Acting quickly on early signs of unhappiness can avert problems
VelocityHappiness
© 2006-2015 Scrum Inc.
Results
: Scru
mm
ing th
e S
cru
m
133
0"
50"
100"
150"
200"
250"
300"
350"
4/27/09"
6/27/09"
8/27/09"
10/27/09"
12/27/09"
2/27/10"
4/27/10"
6/27/10"
8/27/10"
10/27/10"
12/27/10"
2/27/11"
4/27/11"
6/27/11"
8/27/11"
10/27/11"
12/27/11"
2/27/12"
4/27/12"
6/27/12"
8/27/12"
10/27/12"
12/27/12"
2/27/13"
4/27/13"
6/27/13"
8/27/13"
10/27/13"
16
x o
utp
ut w
ith
4x F
TE
s =
4x p
rod
uctiv
ity
Ra
w S
cru
m In
c. V
elo
city
His
tory
(n
ot a
dju
ste
d fo
r fluctu
atio
n in
tea
m c
ap
acity
by s
prin
t)
© 2
00
6-2
01
5 S
cru
m In
c.
Deploy Aggressive Scrum!
134The faster you go, the more resistance you get!
© 2011 Scrum Inc.
As a PO, I need to know my role in the Daily Scrum
to help the team move faster
© 1993-2014 Jeff Sutherland
136The Impact of Agile Quantified. Rally, 2015.
© 1993-2014 Jeff Sutherland
What is the Daily Scrum?
• 15 minutes, same time every day
• 3 questions:
• What did I do yesterday that helped the Team meet the Sprint goal?
• What will I do today to help the Team meet the Sprint goal?
• Do I see any impediment that prevents me or the Team from meeting the Sprint goal?
• Not a status meeting
• If further discussion is needed, takes place after Stand-Up
137
© 2
00
6-2
01
5 S
cru
m In
c.
Motivation for Daily Scrum
0
20
40
60
80
100
120
0 20 40 60 80
Number of Roles
% S
atu
ra
tio
n
Communication Saturation and Roles. Organizational Patterns of Agile Software Development by Coplien and Harrison (2004)
Bell Labs Pasteur Project
82 Companies
138
© 1993-2014 Jeff Sutherland © 2
014
Sc
rum
In
c.
© 2011-2014 Jeff Sutherland
139
All Blacks, New Zealand http://www.youtube.com/watch?v=0C434QFTjok
© 1993-2014 Jeff Sutherland
Purpose of Daily Scrum
• Intensify team focus
• Collaboration and clarification
• Crush impediments
• Motivate team spirit
140
© 1993-2014 Jeff Sutherland
Exercise
• Daily Scrum
• Sprint Goal - learn everything necessary for Product Owner Certification
• What did you learn yesterday that moved you and your team towards the goal?
• Update your Scrum Board
• What is top priority for today for achieving the sprint goal?
• Prioritize your backlog
• Any process improvements?
• Scrum of Scrums
• All teams report
• Will all teams complete the release successfully?
• (ready for certification at 5pm today)
141
© 1993-2014 Jeff Sutherland
Product Owner’s Job at Daily Scrum
• LISTEN!!!
• Motivate the team
• Clarify business value
• Answer questions about the backlog
• Share as appropriate
142
© 2
00
6-2
01
5 S
cru
m In
c.
Source: Version One 2015
143
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum of Scrums
• Scrum is an object-oriented
organizational framework
• The organization will need to be
refactored to maximize flow
• Small steps regularly
• Large changes periodically
Communication Paths
n(n-1)/2 per team
5(4)/2 = 10
24 teams(10) = 240
+ a few cross team
80% less comm
Waterfall Comm Paths
n(n-1)/2 for 120 people
120(119)/2 = 7140
144
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a great PO, I need to create and maintain a clear and compelling
Strategic Vision so that my teams are working toward the same goal
145
© 2
00
6-2
01
5 S
cru
m In
c.
What is Strategic Vision?
• What is our ultimate goal(s)?
• How can we measure progress towards them?
• What do we believe the market wants or needs?
• How can we test these beliefs?
• What are our strengths and weaknesses relative to other competitors?
• How can we test these beliefs?
• What does this imply about what we should or should not do?
146
Goals
Markets
Competitive Position
Guiding Principles
How does product or organizational agility help to improve outcomes?
© 2
00
6-2
01
5 S
cru
m In
c.
Strategic Vision Differs Dramatically by Company and Context
147
Large Defense Contractor
• Top-down agile transformation motivated by perceived external market pressure
• Company vision to halve the cost of projects
Mid-size Software Company
• Opportunistic agile implementation triggered by acquisition of a small Scrum company
• Market leader Looking to stay ahead of competition
Growing “Agile Native” Company
• Disruptive technology innovator with successful product looking to scale to keep up with demand
• Leadership are steeped in agile principles
A B C
Name Classified Autodesk Spotify
Key Context: • Complex, integrated multi-
year hardware/software projects
• Each project has one customer
• Reliability a key priority • Must deliver to detailed
contract requirements
Key Context: • Redeploying a legacy
software product to cloud-based SaaS model
• Goal to increase pace of innovation
• Historically, releases a disruption for customers
Key Context: • Web/app-based product • Product and company set
up modularly • Allows teams to work
independently with minimal coordination
• Teams co-located
© 2
00
6-2
01
5 S
cru
m In
c.
Don’t Assume all Organizations ShareSame Agile Strategy Objectives
148
“Emergent” Product Design
“Convergent” Product Design
Pro
cess A
dapta
bility
Pro
cess P
redic
tability
EP
CP
EA
CA
Adapted from Michael Cottmeyer
© 2
00
6-2
01
5 S
cru
m In
c.
© 1993-2012 Jeff Sutherland
Product Vision as a Cereal Box
• Key sales proposition on front
• Name • Key selling points
• Details on back
• Feature list (i.e. product attributes)
• Version changes
• Operational requirements
149
© 2
00
6-2
01
5 S
cru
m In
c.
Example: Creating a Vision Statement
• FOR <target customers>
• WHO <statement of need>
• THE <product name> IS A <product category>
• THAT <key benefit, compelling reason to buy and use>
• UNLIKE <competition/alternative>
• OUR PRODUCT <differentiating statement>
150
A successful vision statement is compelling enough to be broadly shared, yet concise and easily remembered
Source: Crossing the Chasm by Geoffrey Moore
© 2
00
6-2
01
5 S
cru
m In
c.
Example: Creating a Vision Statement
• FOR MIT Stakeholders
• WHO need stuff done
• Scrum IS an Agile Process
• THAT delivers twice the results in half the time with higher quality
• UNLIKE traditional product management
• OUR PRODUCT delivers stuff four times as fast.
151
A successful vision statement is compelling enough to be broadly shared, yet concise and easily remembered
Source: Crossing the Chasm by Geoffrey Moore
© 2014 Scru
m Inc.
Example: Vision Statement for ScrumLab™
For experienced Scrum practitioners (Jill) who are “in the trenches”
Who need clear and actionable information to answer specific Scrum questions whenever they arise
ScrumLab Is the authoritative, curated on-demand source for Scrum Inc.’s leading edge thinking
That: • Clearly explains Scrum and its underlying principles
(the why) • Shares successful advanced practices for different
contexts • Provides actionable solutions to implement successfully • Is available whenever you need it
Unlike other online Scrum resources
Our product captures decades of successful experience and wisdom from the co-creator of Scrum and his hand-picked team of thought leaders
© 2
00
6-2
01
5 S
cru
m In
c.
Exercise: Scrum Café
• You and your team recently opened a local restaurant. It has:
• A small kitchen with sink, fridge and stove
• 5 café-style tables
• You have been serving soup and sandwiches at lunch, have attracted a small but loyal following, and are just breaking even with weekly revenue of $5,000.
153
• Since you use Scrum to run your restaurant, you know that team velocity is 100 points for each week-long sprint
• You have found a bank that will give you a loan at an interest rate of 7%, but they will want a compelling argument for how you plan to use the money
What should you do to grow your business?
photo credit: *Light Painting* via photopin cc
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Café 1: Product Vision
• You and your partners are wondering how to focus your efforts and the strategy for your business
• To inform this you need to align on a common vision for your product
Two Sprints
1. With your team members, discuss each element of a vision statement for Scrum Café
2. Document your vision statement as a key “enabling specification” for future use?
154
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a Great PO, I need to
Visualize the Customer to ensure
we are delivering products that our customers want
155
© 2
00
6-2
01
5 S
cru
m In
c.
Customers Often Don’t Know What They Want Until They See It! Humphrey’s Law
156
Customers
loved this…
…Until they
tried this…
© 2
00
6-2
01
5 S
cru
m In
c.
A Successful Product Must Delight All “Customers”
157
Users
• Interact directly with
the product
• Knowledge of current
usage patterns helps
to design better,
more usable products
• Unsatisfied users
work around the
product, nullifying its
benefits and
eventually
eliminating it
Purchasers
• Make buying or
adoption decisions
• Have their own wish
lists that may have
little to do with the
users’ needs
• Make purchasing
decision, so if they
aren’t happy, you
won’t get in the door
Influencers
• Interface with the
product or its users
• Support, install,
deploy or benefit
from use of the
product
• Can also wield
significant influence
on decision to
purchase, retain or
change products
Internal Stakeholders
• Influence scope,
priorities, budget and
schedule
• Assist with or may be
dependent on
product releases
• Can constrain or
evaluate architecture
or product
development
processes
© 2
00
6-2
01
5 S
cru
m In
c.
Customer Personas Make Data RealIt is Hard to Design Product for a Data Point
158
Personas are archetypes…not real people ▪ Describes the “centroid” of
a customer segment
Provides context for a user and what he/she wishes to accomplish ▪ Team can design for just
one person ▪ Personas often end feature
debates
Need a persona for each targeted customer segment and/or product
© 2
00
6-2
01
5 S
cru
m In
c.
Fleshing out Personas forGreater Context
Determine the information relevant to understanding customers: • Who are they? • What is their typical role? • How do they/might they use the product? • How would you recognize them if you saw them on the street?
(demographics) • How do they make decisions about purchases?
159
Avoid common persona pitfalls: • Beware of extraneous detail! • Base personas on data from customers don’t
just rely on “creative writing” • Use the persona throughout the design
process, not just at the beginning • Continue to evolve personas based on what
you learn
© 2
00
6-2
01
5 S
cru
m In
c.
How to Use Persona’s in Team Room
160
Keep the persona visible • Often posted next to
information radiator in team space
Refer to personas in team discussions • “I think David would
appreciate…”
Use them to settle disagreements about what to build or how to design the interface
To do Doing Done
Story
Story
Story
Story
Sprint
Release
Backlog
(points)
400
Story
© 2
00
6-2
01
5 S
cru
m In
c.
Walk Personas Through ProductBacklog to Clarify Prioritization
161
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Café 2: Personas
• Your partner team wants to build the improved Scrum Café to ideally meet the needs of its core customers
Five-Minute Time Box
1.With your team members, identify the potential customer segments that you could serve
2.Pick one segment to be your top priority
3.Develop a customer persona description for your top priority segment
162
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need to understand Story Sizing and Estimation so that I can
assist the Team in estimating stories
163
© 2
00
6-2
01
5 S
cru
m In
c.
Context: The Reason we Estimate in Scrum
164
Why do we
estimate user
stories?
In order to
determine our
team’s Velocity
Why do we need
Velocity?
Need a consistent measure
of team output each sprint;
2 reasons:
Release Planning
Knowing how much we can produce
each Sprint allows us to accurately
forecast when we will complete
future features
Continuous Improvement
Measuring if output increases,
decreases or stays the same confirms
whether we are removing
impediments successfully
1 2
© 2
00
6-2
01
5 S
cru
m In
c.
Agile Estimating Strategy
• Don’t estimate time • Estimate relative size of stories • Measure velocity per sprint • Derive release plan
• Estimates are done by the people who are going to do the work
• Not by the people who want the work done • Don’t assume that only one specific team member
will do the work
• Estimate continuously during the project, not only up front
• Prefer verbal communication over detailed, written specifications
165
© 2
00
6-2
01
5 S
cru
m In
c.
Points vs. Hours
• Rand Corporation received a grant from U.S. DOD in the 1940’s to determine best way to estimate tough projects
• Discovered estimation in hours has high error rate and wide variance
• Found people could put things in relative size piles best
• Fibonacci growth pattern easiest for humans • Seen everywhere in nature • RAND called it the Delphi technique
166
© 2
00
6-2
01
5 S
cru
m In
c.
Fibonacci Series is All Around Us
167
© 2
00
6-2
01
5 S
cru
m In
c.
Why Points are Better Than Hours
168
Cone of Uncertainty
Gray Line ‐ Hours
Red Line ‐ Points
Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan (2012) Scrum + Engineering Practices: Experiences of Three Microsoft Teams. IEEE Best Industry Paper Award, 2011 International Symposium on Empirical Software Engineering and Measurement.
1. Repeated studies have
shown estimates in
points are more accurate
2. There are a fixed number of hours in a day, so a velocity based on hours
can not increase!
© 2
00
6-2
01
5 S
cru
m In
c.
Estimating the Product Backlog
169
POT TT SM
Development Team • Estimate backlog • Estimates are forecasts,
not commitments
Scrum Master • Facilitates
process
Product Owner • Available to clarify intent
of PBIs to help estimate • But does NOT estimate
Two options for estimating process:
Estimate Stories
Individually
• Lay out all stories • Agree which one is least effort; call this “3-points” • Estimate other stories relative to the reference story
Estimate Groups of Stories
• First, group stories into similarly sized piles of activity • Then estimate number of points for each pile • Fast way to estimate a large number of stories
© 2
00
6-2
01
5 S
cru
m In
c.
Estimate User Stories with “Planning Poker”
170
© 2
00
6-2
01
5 S
cru
m In
c.
Beware Common Estimating Pitfalls
171
Irrelevant Information
A
B
C
A
B
C
Anchoring
20 pts! 39 pts!
Spec
Same spec plus
extraneous detail
A
B
C
A
B
C
A
B
C
Spec Same Spec Same Spec
20 pts!
25 pts., never
mind me
10 pts., never
mind me
30 pts! 15 pts!
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Café 3: Planning Poker
• Your team has suggested five potential enhancements: 1. Get a liquor license and start serving alcohol 2. Add ten tables of outdoor seating 3. Stay open for dinner as well as lunch 4. Advertise in the local paper or online 5. Install a high capacity espresso machine
• Estimate Epics • Pick smallest relevant Epic and assign it
21 story points • Estimate relative size of other the other
epics • Discuss outliers and vote again until all
numbers are within 3 cards, then average
172
As a X I want Y so that Z
As a X I want Y so that Z
As a X I want Y so that Z
As a X I want Y so that Z
As a X I want Y so that Z
As a X I want Y so that Z
As a X I want Y so that Z
As a X I want Y so that Z
8
2
3
5
1
2
5
13
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need to know how to estimate
Business Value and ROI so that I can order the Product Backlog effectively
173
© 2
00
6-2
01
5 S
cru
m In
c.
What Is Business Value?
Business Value results from the intersection of three dimensions
1. What you can implement successfully and sustainably
2. What your customers want and will buy (even if they don’t know it yet)
3. What your team is excited about creating
174
Should be an explicit consideration of the organization • Estimate at Epic rather than User Story level
• What is the source of value that will be created? • How much effort will it take to create that value?
• Prioritize Epics by ROI (most value with the least effort) • Coordinate with your Finance Department
• They already have a view of production function and ROI metrics • Engage them as an ally – they will love that you are speaking with them
What you can implement
What you can sell
What you are passionate about
© 2
00
6-2
01
5 S
cru
m In
c.
Sources of Business Value
175
Market Value
Will this feature allow us to: • Sell more units? • Charge a higher price? • Reduce the cost of providing the product/service?
Risk Reduction
How will completing this story allow us to: • Develop or refine hypotheses about the market? • Prove technical assumptions?
Capability Building
Will completing this story: • Enable our team to do something we couldn’t
before? • Reduce or eliminate the need for low-value
activity?
© 2
00
6-2
01
5 S
cru
m In
c.
Product Owner Tries to Trace “Value Curve”
176
Deliver here at the latest!
80% of value
20% of features
MVP may be here
© 2
00
6-2
01
5 S
cru
m In
c.
Methods for Determining Value
Bubble Sort
Planning Poker
Break-even analysis
Cost of Delay
Return On Investment
Cash Flow Analysis
Net Present Value
177
Faste
rM
ore
Deta
iled
• Pick a low value item and assign it 3 points • Use estimation cards to independently estimate a story • Show estimates, discuss highs and lows, estimate again • When everyone is within three cards, average the estimates
• Start at the top of a list of stories • Compare value of stories one at a time • Move the lower value story down one place in list • Repeat until all stories have been compared
• Compare cost of feature creation with expected incremental revenue of feature
• How many incremental units would we need to sell to equal the development cost?
• = [Total expected revenue from new feature]/total cost to develop feature] – 1
• Expressed as a percent
• Over a reasonable planning horizon, what are the revenues and expenses associated for a feature in each month?
• What is the net effect on cash flow over that horizon?
• Building on the cash flow analysis, what is the effect of including the “time value of money” in the calculation? (i.e. a dollar today is worth more than a dollar tomorrow)
• Estimate in a lightweight way the opportunity cost of NOT completing a feature
• Often divided by feature size to get a “proxy” for ROI
© 2
00
6-2
01
5 S
cru
m In
c.
Prioritization of Value/Effort Can Cut Cost & Time to Market by 50%
178
Maurits Rijk. A simulation to show the importance of backlog prioritization. 8 Jun 2011
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Café 4: Prioritization
• Your team has suggested five potential enhancements:
1. Get a liquor license and start serving alcohol 2. Add ten tables of outdoor seating 3. Stay open for dinner as well as lunch 4. Advertise in the local paper or online 5. Install a high capacity espresso machine
• You have already developed a “customer persona” for your typical customer
Part IV. Five-Minute Time Box
1. Using a “planning poker” approach, which of these improvements would you complete, and in what order?
2. ROI = business value points/estimated effort points
179
© 2
00
6-2
01
5 S
cru
m In
c.
Weinberg Table of Project Switching Waste
180
Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284.
© 2
00
6-2
01
5 S
cru
m In
c.
Four Pillars to Scrum Inc.’s Business Value Process
181
Jan
2. Regular Quarterly Cadence
Invoicing Expense processing Proposal response
CSM class CSPO class
PublishingCoaching
Mgmt. workshops
Consulting
Online content
New
knowledge
creation
Efficiency
improvements
IT, communications, and web
Webinars
1. Tiering Activity by Category
Cash Flow ($)
Time
3. NPV/point for each Epic
NPV/point
Points
4. Prioritization of Epics
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Inc. Activities Tiered into Parallel Workflows
182
Growth and
innovation activities
Keeping the
Lights On (KLO)
Value and revenue
creation activities
Invoicing Expense processing Proposal response
CSM class CSPO class
PublishingCoaching
Mgmt. workshops
Consulting
Online content
New
knowledge
creation
Efficiency
improvements
IT, communications, and web
Micro‐classes
© 2
00
6-2
01
5 S
cru
m In
c.
Business Value Vision Updated on a Regular Cadence
183
Jan
Each Sprint
Monthly
Quarterly
Yearly
• User story planning
• Backlog refinement
• Sprint goals
• Actual financial performance
• Epic progress check‐in
• Epic definition/prioritization
• Release planning
• Financial Forecasts and goals
• Strategic goals
• Financial estimates
Multiple parallel planning, review, and
retrospective cadences
© 2
00
6-2
01
5 S
cru
m In
c.
Cash Flow Profile for a Typical Epic
184
Cumulative
Cash Flow ($)
Time
Maximum Required Investment
Cash flow break even point
Point of Positive Return on Investment
Investment period Return period
© 2
00
6-2
01
5 S
cru
m In
c.
Calculating Net Present Value
185
ΣCt
(1+r)tt=1
N
Where
Ct is the net cash flow in time period t
r is the discount rate t is the time period N is the total number of time periods considered
Illustrative Example:
C0 = -$50; C4 = -$30; C6 = $45; C10 = $100
r is 5%
$100
$61
Cash Flow ($)
Time (t)‐$30
$45
t0 =
Today
5 10
NPV =
$34
‐$25
100
(1+.05)10= $61.40
15‐$50
$20
© 2
00
6-2
01
5 S
cru
m In
c.
The Calculation Is Easily Automated
186
Download an NPV calculation Excel tool at www.scruminc.com/npvtemplate
© 2
00
6-2
01
5 S
cru
m In
c.
NPV/Point Drives Better Decision Making
One metric to encapsulate return on investment 1. Calculate Epic NPV
2. Can also include “intangible” benefits • Use Planning Poker to estimate business value relative to
reference activity with known cash flows 3. Estimate story points to complete Epic
4. Divide total NPV by estimate of points • Answers: How can we get most return with least effort?
Focuses team on optimizing returns • Eliminates most internal power politics • Encourage teams to think in business case terms • Highlights key assumptions and variables to confirm • Supports after-action retrospective to improve accuracy • Improves ability to forecast financial results
187
© 2
00
6-2
01
5 S
cru
m In
c.
Prioritize Possible Epics by NPV/PointMinimum Level Set by Current Rev/Point Run Rate
188
NPV/point
Points
Available quarterly team capacity for Epics
(based on yesterday’s weather)
NPV/Point floor
(based on current
rev/point run‐rate)
E1
E2
E3
E4E5
E6
E7E8
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Inc. Case Study: Setup
189
Publish a bookInstall videoconference
system
Which project should we do first?
Should we do them both?
• New revenue opportunity
• $400,000 advance, paid at key milestones • 25% at contract signing • 50% at draft delivery (+12 mo.) • 25% at publication (+9 mo.)
• Estimate $5,000 in travel and research expenses
• Estimate intangible benefit of brand building at 2x reference story (reference worth $30,000)
• Estimate 1,500 points of effort to research, write and edit
• Performance improvement
• No additional revenues
• $5,000 in up-front expense
• Team estimates closer team integration will increase velocity by approx. 2% • Current velocity is 200pts/sprint • Current revenue “run rate” is $250/pt
• Estimate 25 points of effort to research, purchase and install
• Assume system will need replacement in 3 years
© 2
00
6-2
01
5 S
cru
m In
c.
Case Study: Calculate NPV/Point
190
Publish a book Install videoconference system
$
C1 = $100K
C13 = $200K
C22 = $100K
C2‐13 = ‐$500r = 10%
NPV = $358K
1,500 story points
÷
$279/point
Research (300pts) Writing (100pts/chapter x10) Editing (200pts)
$
C1 = ‐$5,000
r = 10%
NPV = $57K
25 story points
÷
$2,279/point
Research (10pts) Purchase (5pts) Install (10pts)
$60K of intangibles
+
$0 intangibles
+
VS.
C2‐36 = $2,000
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a Great PO, I must be able to
effectively Refine & Decompose the Backlog so
that teams can work quickly
191
© 2
00
6-2
01
5 S
cru
m In
c.
Backlog Refinement & Decomposition Accomplishes Several Goals
• A great PO maintains visualization of how ultimate vision breaks out into manageable incremental pieces
• Leveraging Agile architecture helps
• Individual components & features distributed to teams
• Regular refinement cadence ensure loosely defined features further down backlog are “Ready” by the time they reach the top
• Includes POs, Teams and stakeholders
192
Product Backlog
Component
Goal
Feature Capability
Feature Capability
EpicEpic EpicStor
yStor
yStor
y
Product Vision
Component
Goal
© 2
00
6-2
01
5 S
cru
m In
c.
Maintain a Clear Product Decomposition Hierarchy
193
Component
Goal
Feature Capability
Feature Capability
EpicEpic Epic
Story
Story
Story
Product Vision
Component
Goal
Product
Component
Feature
Epic
Story
Increase SB usage of eBanking website
Add online customer center for self-service
of common needs
Find Branch location
Able to search for specific language skills
Able to search close to a specified address
Able to search by hours of operation
Be the banking provider of choice for small businesses
Stop Payments
Access historical statements
Retail bank center rated “excellent” by
SB customers
Add monthly financial reporting summary to track company profits
Decomposition Level
Conceptual Hierarchy Example
© 2
00
6-2
01
5 S
cru
m In
c.
Modular/Agile Architecture Should Support Product Hierarchy
194
• Underlying structure is a set of largely independent modules with pre-defined interfaces
• Interfaces remain stable, allowing everything within the module to change without impacting other modules
• Enables product design to “emerge” rapidly in response to inspect and adapt cycles
• Also supports re-use of the same module for different contexts
The 8 modules of the Wikispeed Car
© 2
00
6-2
01
5 S
cru
m In
c.
Break Epics into Stories
195
As a frequent flyer I want to book flights customized to my preferences, so I save time
As a frequent flyer I want to book a trip using miles so that I can save money
As a frequent flyer I want to easily book a trip I take often so that I can save time
As a premium frequent flyer I want to request an upgrade so that I can be more comfortable
© 2
00
6-2
01
5 S
cru
m In
c.
User Story Mapping
• Epics at top, stories underneath
• Shows workflow
• Can be large features, company initiatives
• Two dimension view easier to understand than linear ordering
• Tool for identifying MVP
• Allows the team to see the big picture
196
© 2
00
6-2
01
5 S
cru
m In
c.
PO Should Write User Stories, Not Tasks
197
How?
What?
Why?
User Story Task Task Task
Confusing user stories with tasks unnecessarily limits the team’s ability to innovate, accelerate and try new approaches
• Focuses on WHAT the team
needs to do, and WHY they
need to do it
• Typically requires many team
members with different skills
to complete
• Can be completed
independent of other user
stories
Deliver independent customer
visible value!
• Focuses on HOW the team
will accomplish their work
• Typically can be done by one
or two team members with
similar skillsets
• Often must be completed
sequentially
• Address individual
development layers
Do not deliver independent
customer visible value!!
© 2
00
6-2
01
5 S
cru
m In
c.
Conduct Regular “Sanity Checks”
198
PO
?!?
TT
T
Despite the best intentions, dependent or task-level stories invariably slip through…
Make time as a team to check stories in the backlog regularly • E.g. at Sprint Planning or Backlog Refinement
Customer visible value – does every story
result in customer visible value? (customer
not necessarily just an external user)
If no then story probably
isn’t independent
Swarming – does this story require multiple
people to complete?
If no then it probably isn’t
a complete vertical slice
✗Test Driven Development – Does this story
have clear and testable acceptance criteria?If no then it probably isn’t
a complete vertical slice
✗
✗
✗External Dependency – Is this story free
from dependence on other stories or groups
outside the team?
If no then story probably
isn’t independent
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Cafe Example: Expresso Machine
• Epic - As an owner I want to serve expresso to gain more customers and make more money
• Research options
• Purchase specific expresso machine
• Research coffee options
• Design installation
• Buy other essential equipment
• Implement installation
• Train employees
• Trial run
• Open for business
• Marketing? Etc.
199
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Café 6: Refine User Stories
• You have already prioritized your potential new features/epics and generated an estimate of the effort required to achieve it
Part VI. Create Story Map
• For your top priority Scrum Café epic, create the user stories needed to deliver the functionality, one per sticky note
• Organize the user stories into a story map on your table
• Refine the definition of any stories that do not meet the INVEST criteria; split stories if needed
200
© 2006-2015 Scrum Inc.
Sto
ry M
ap
201
2012 Martien
van
0627
Steenbergen
202
2012 Martien
van
0627
Steenbergen
STORY MAP SAMPLES
Story Maps support the primary intent of user stories
203
© 2
00
6-2
01
5 S
cru
m In
c.
Delta Northwest Airlines Merger
204
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I must be able to drive Release Planning so that all stakeholders know
when to expect each feature
205
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Allows us to Break the Iron TriangleComplete More Scope in Less Time with Fewer People
VelocityBut in Scrum we find: • Small & stable teams are key
• Flexing scope actually much easier than changing resources • Requires scope defined as independent
features, and prioritized by value
• Increasing velocity allows team to get more done in the same time • Accomplished by removing impediments
206
Scope Tim
eResources
• Traditional planning views Scope, Time and Resources as locked in a fixed relationship • In theory, any dimension can change
to meet release requirements… • …But, in practice resources seen as
easiest to change, while scope & time seen as fixed constraints
© 2
00
6-2
01
5 S
cru
m In
c.
Release Plan Links Concept and Physical Worlds
207
Vision/Roadmap
Sprint Goals
Feature Availability
Product Release
Shippable Increment
Backlog Item
(User Story)
Conceptual View Physical Product View
© 2
00
6-2
01
5 S
cru
m In
c.
Elements of a Scrum Release Plan
• Clear Vision • Tied to concrete business value
• Aligns stakeholders
• Vision decomposed into independent features • Prioritized and estimated
• ROI and customer need driven
• Burndown chart of progress on prioritized backlog items • Measured in Points!
• Feature availability timeline • Best guess – subject to change
208
1
2
3
4
Sprint
Release
Backlog
(points)
400
Story
Story
Story
Feature
Story
Story
Story
Feature
Story
Story
Story
Feature
Story
Story
Stpry
Feature
© 2014 Scru
m Inc.
20
Q4200
Q3200
June2008
May2008
Apr2008
Release Burndown Chart MakesTeam’s Velocity Implications Visible
Sprint/Time
Points
Sprint/Time
Points
© 2
00
6-2
01
5 S
cru
m In
c.
Two More Considerations for Anticipating Burndown
210
Both factors must be accounted for to determine accurate burndown
Emerging Requirements
Bugs and Customer Feedback
Additional user stories beyond those known in the backlog that are “discovered” as the project evolves and require the team to do more work
Generally happens as a consistent percentage of estimated work, which can either be added to the backlog as a “buffer” or subtracted from velocity in calculating burndown
Additional work that cannot be anticipated in the release plan, but you know it will come up as product functionality is released
Track as a separate buffer as a percent of estimated work, and try to manage down the percent of velocity devoted to bugs as a way to speed up the team
© 2
00
6-2
01
5 S
cru
m In
c.
Roadmap Helps Stakeholders Know when to Expect New Features
• Facilitates conversations on feature priority
• Aligns stakeholders and heads off distraction
• Ground rule: Timeline is only an estimate, and subject to change
211
Q1
Q2
Q3
Q4
• Basic platform with ability to create new user • Homepage and introduction • Ability to view account status
• Ability to update account information/address • Select communication options and preferences • “Share with friends” link
• Ability to rate individual articles • Ability to sort by top rated articles • Ability to refer friends for a referral bonus
• New premium content offering • Corporate portal for company viewing
© 2
00
6-2
01
5 S
cru
m In
c.
Release Planning MeetingEnsures Plan is Regularly Updated with Empirical Data
212
T
Teams
SH
Leadership & Stakeholders
PO
Product Owners
T
SHPO
Sprint/Time
T
PO
T
PO
• Not part of the core Scrum framework…but many teams need it to maintain holistic long-term perspective • Planning distributed throughout
project, not only at beginning
• Similar to Sprint planning meeting with product and release rather than sprint time horizon • Held at regular intervals • Update release burndown with
latest velocity data • Adjust PBL as needed to meet
priority deliverables
• Produces updated release plan and burndown
• Allows teams to progress confidently
Release
Planning
Release
Planning
Release
Planning
SHSH
SHSHSH
SHSHSH
Sprint
Release
Backlog
(points)
400
Sprint
Release
Backlog
(points)
400
Updated Product
Backlog & Release
Plan
Updated Product
Backlog & Release
Plan
© 2
00
6-2
01
5 S
cru
m In
c.
Three Common Approaches toRelease Planning
• Deadline-based
• External deadline specified for team, they must complete as much of a given backlog as possible before that date
• Regular-Departure
• Set cadence of product releases. (e.g. quarterly) • Ready features are included in the release, non-
ready ones wait for next release
• Value-Based
• Team produces incremental potentially-shippable product each Sprint
• When PO decides enough new value has been created, features are released to customers
213
© 2
00
6-2
01
5 S
cru
m In
c.
Deadline–Based Release PlanningMedco Case Study
214
Points
On July 7 2006, Medco CEO promised Wall Street analysts a completely new pharmacy fulfillment system to be implemented by July 7, 2007 • Unfortunately, he didn’t check with the development team first!?!!
1,400
TimeJul‐06 Dec‐06 Jul‐07 Dec‐07
123
Plan
Code
Promised
Delivery Date
1,450
1,320
6090
1,230
700
990
Test
Medco Stock
© 2
00
6-2
01
5 S
cru
m In
c.
215
• Prior to 2005, Microsoft released a new version of its Team Foundation Server (TFS) product roughly every 18 months
• Using Scrum, it now deploys a new version internally every 3 weeks
2005
Release Release
18mo. 18mo.
Release
2008
Release
5wk. 5wk.
20123wk. 3wk.
Release Internally Every Sprint
Source: Sam Guckenheimer and Neno Loje. Agile Software Engineering with Visual Studio. Microsoft Press, 2012.
Regular Departure Release PlanningMicrosoft Case Study
© 2
00
6-2
01
5 S
cru
m In
c.
Value-Based Release PlanningHealthcare Startup Case Study
• Venture-backed healthcare startup looking to raise additional investment
• Needs to demonstrate value creation rapidly to court investors
216
1 2 3
Divide work into Epics, prioritized by expected revenue
Decompose epics into actionable user stories
and start working
As each Epic is completed, release
into market
ED Module
Ambulatory Module
Registration Module
ePrescribing
Patient Portal
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Café 7: Release Planning
• You have a prioritized and estimated set of epics and user stories
• You know that your average velocity per one week sprint is 100 points
Part VII. Five-Minute Sprint
• For your top priority epic decide what functionality is needed for your Minimum Viable Product (MVP) and what stories can be delivered in future releases
• How many sprints will it take to release your MVP?
217
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a Great PO, I need know how to
use Feedback effectively to improve my product
218
© 2
00
6-2
01
5 S
cru
m In
c.
Lean Startup in a Nutshell
• Cast your business case as a set of assumptions
• Rapidly build prototypes for early adopters to validate those assumptions
• “Get out of the building.”
• “Pivot” the strategic vision based on both qualitative & quantitative feedback
• Deliver quickly, often & with high quality using agile methods
219
Build
MeasureLearn
Product
Data
Ideas
© 2014 Scru
m Inc.
Two Central Lean Startup Concepts
The Minimum Viable Product (MVP)
A “Minimum Viable Product” might be: • Learning: Onsite
observation, fake menus, ads • Pitching: Preorders,
comparisons, joint design • Experiencing: Concierge,
prototypes
The Pivot
Based on what you learn, you might: • Target another customer group • Target a different need • Expand or contract feature focus • Change platforms or architecture • Change channels
Early releases focus on quickly & cheaply
testing ideas
Later releases focus on scaling
© 2
00
6-2
01
5 S
cru
m In
c.
Iterative Risk Management
221
© 2
00
6-2
01
5 S
cru
m In
c.
The Opportunity: Lots of Great Data
222
BUT…to use it effectively you need to understand who is saying what and where they fit in the market
The proliferation of social media, mobile technology, and internet analytics are
creating enormous amounts of data
Customers can easily: • Self-identify with your product • Tell you what features they want • Indicate where they are located • Reveal their usage paths and
patterns
The cost of acquiring customer data has plummeted
© 2
00
6-2
01
5 S
cru
m In
c.
Introducing Behavioral Graphs A Mental Model of Customer Product Preferences
223
Convenience
Quality
Price
Represents the theoretical “ideal” combination of product attributes for a particular customer • Rough approximation can be determined from
survey data, interviews, or “Conjoint” analysis
x
z
y
Customer 1
Used to define, test, and refine hypotheses about what customers want • Visualizes “Lean Startup” approach to validated
learning
Many different potential product attribute dimensions. Iterative inspect and adapt cycles will determine which ones are important
Customer defined by behaviors and preferences, not demographics
Assumption that customers will buy the product that is closest to their ideal
© 2
00
6-2
01
5 S
cru
m In
c.
Conjoint Analysis One Way to Identify a Customer’s Preference
224
• Similar to A/B testing for a web site, a conjoint survey asks customers to decide between two products with different parameterized attributes
• Analyzing the results of several such tradeoffs shows how the customer weights different product attributes
• Categorical regression • Linear Programming • MaxDiff
• In the agile world, subsequent iterations of a product create a natural conjoint analysis set
Please select your preferred product (select only one each row)
20” screen 60 Hz, 400i picture 30lbs $200
40” screen 120Hz, 1080p picture 25lbs $2,000
40” screen 120Hz, 1080p picture 25lbs $2,000
50” screen 60 Hz, 1080p picture 50lbs $1,500
© 2
00
6-2
01
5 S
cru
m In
c.
Customer Clouds and Segmentation Teasing Out Targetable Differences in Preference
225
Convenience
Quality
Price
Behavior graphs can represent thousands/millions of individual customers in a “customer cloud”
Looking carefully at pairs of dimensions, possible to identify meaningful customer segments
Convenience
Quality
Price
Quality
Segment 1 – “Premium”
Segment 2 – “Cost-conscious”
No Obvious
Segmentation!
© 2
00
6-2
01
5 S
cru
m In
c.
Distilling Segments to Point EstimatesWhere is the “Bull’s Eye?”
226
Price
Quality
Thousands of individual customer data points are difficult to work with!!
Often much easier to distill clouds to a single point estimate located at the “centroid” of the segment • Represents target at the center of the
customer cloud that you are aiming for
Range or standard deviation data can help drive statistical analysis on customer behavior
© 2
00
6-2
01
5 S
cru
m In
c.
Segment Evolution Tracking Customer Preference Shifts Over Time
227
Price
Quality Consumer behavior is organic…it evolves over time
Product designers ignore consumer preference shifts at their peril
Cloud centroids trace out “tracks” over time • Refresh market data in regular iterations
to follow tracks
© 2
00
6-2
01
5 S
cru
m In
c.
Quantitative Customer Modeling can Inform Business Value Estimation
228
Identify the natural segmentation of your customers
Determine the common demographic profile of your target “Persona” • Age • Income • Gender
Leverage publicly-available demographic data to determine how big a segment is, and where it is located
Use assumptions to build value hypotheses • Segment size • Penetration rate • Average purchase
Refine these hypotheses based on early feedback and observations
1
2
3
4
5
Price
Quality
Revenue = 30M ppl x 10% pen x $2.50pp
Iterate
© 2
00
6-2
01
5 S
cru
m In
c.
Using These Techniques to Drive Validated Learning
229
Price
Quality
Product Timeline
Beh
avio
ral
Mo
del
Develo
pm
en
t A
cti
vit
y
Iteration 1
1.Conduct initial market research to develop behavioral model
2.Develop MVP 3.Release to market 4.Measure results
MVP
Price
Quality
Iteration 2
1.Add several features that enhance the “perceived quality”
2.Raise the price a little
3.Measure results
Vers 1
Iteration 3
1.Fix top priority bugs 2.Add a quality-
enhancing feature 3.Raise the price a
little more 4.Measure results
Price
Quality
Etc.
Sales = $2K Sales = $500K Sales = $600K
Vers 2
© 2
00
6-2
01
5 S
cru
m In
c.
Illustrative Example: Scrum Café
230
The co-founders can’t agree on anything: location, format, cuisine…
But they remember the lessons of this class, and so start by setting up a Facebook page to gather customer data and engaging in a discussion with their potential customers.
Responding customers were asked to complete a conjoint analysis
“Antonio’s” Large portion sizes, good value
for money, Table cloth and smartly dressed wait staff
“Lou’s Place” Like your own kitchen, except you don’t need to clean! If you don’t
leave full, we haven’t done our job
“Reuben’s” High quality artisanal
ingredients in a relaxed and friendly atmosphere
“Chez Scrum” The finest French cuisine served
in a historic townhouse by Cordon-Bleu educated chefs
Let’s say we are opening the most analytically over-supported restaurant in history…naturally somewhere in the greater Boston area
Please select your preferred option from each pair of choices
© 2
00
6-2
01
5 S
cru
m In
c.
Example: Map Customer Dataonto an Actionable Persona
231
Customer Responses
Am
bia
nce
0
1.25
2.5
3.75
5
Food Quality
0 1.25 2.5 3.75 5
“Patrick” • 18-24 year old male • Student at the local
college • Enjoys eating food
with friends • Worries more about
feeling “full” than exactly what he is eating
• Avid fan of “dollar menus”
“Kristen” • 30-40 year old female • Career-oriented • Self-proclaimed
“Foodie” • Enjoys fine dining as
a way to relax • Concerned about
using locally-sourced ingredients
© 2
00
6-2
01
5 S
cru
m In
c.
Example: Find your Customers
232
Census Tracts with >25% of residents in target demographic
Source: MassGIS and US Census 2010 Tiger data
With a clear picture of our potential segments, we turn to US census data…
There are 75,000 residents of Boston that match the “Kristen” profile, but 200,000 “Patricks”
Digging deeper into public geospatial data reveals where these customers live, and thus potential locations for our restaurant
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need know ways to work
with Distributed Teams so that we can get to output effectively
233
© 2
00
6-2
01
5 S
cru
m In
c.
Guidance on Distributed Scrum
From Craig Larman and Bas Vodde
• On to our key recommendation: After working for some years in the domains of large , multisite , and offshore development, we have distilled our experience and advice down to the following: Don’t do it.
234
• There are better ways to build large systems than with many developers in many places. Rather, build a small group of great developers and other talents that can work together in teams, pay them well, and keep them together in one place with product management or whoever acts as the voice of the customer.
• But of course you are still going to do large, multisite, or offshore development. This is because your existing system is already structured that way, or because—in the case of large groups—there is the mindset that “big systems need lots of people.”
© 2
00
6-2
01
5 S
cru
m In
c.
Distribution & Outsourcing Styles
235
Fully Isolated Scrums
Coordinated backlog and Scrum of Scrums
Distributed Daily Meeting
© 2
00
6-2
01
5 S
cru
m In
c.
Scrum Changes the Basic Economics of Outsourcing
• What happens if you outsource $2M of development?
▪ Industry data show 20% cost savings on average
• Outsourcing from PatientKeeper to waterfall team in India:
▪ Two years of data showed breakeven point occurs when Indian developer costs 10% of American Scrum developer
▪ Actual Indian developer cost is 30%
• $2M of Scrum development at my company costs $6M when outsourced to waterfall teams
236
© 2
00
6-2
01
5 S
cru
m In
c.
Distributed Scrum Success Story SirsiDynix – Digital Library Catalogue
237
PO
SyrsiDynix • Provo, UT • Denver, CO • Waterloo, ONT
Starsoft Labs • St. Petersburg,
RUS
Catalogue Serials Circulation Search Reporting
PO PO
SM
Dev
Dev
Dev
Test lead
Dev
Dev
Dev
© 2
00
6-2
01
5 S
cru
m In
c.
SirsiDynix: Daily Meeting Scheduled to Fit Both Team’s Calendar
238
SyrsiDynix • Provo, UT • Denver, CO • Waterloo, ONT
Starsoft Labs • St. Petersburg,
RUS17:45
7:45
Daily Meeting
Local Team
Meeting
Daily Meeting conducted by video to enhance robustness of communication
© 2
00
6-2
01
5 S
cru
m In
c.
SirsiDynix: Robust Metrics Dashboard Supported Transparency
239
© 2
00
6-2
01
5 S
cru
m In
c.
SirsiDynix: Outcome
240
Waterfall1 Scrum1 SirsiDynix2
Person Months 54540 827
Lines of Java 51,00058,000 671,688
Function Points 959900 12,673
Function Points/ Developer Mo.
17.82.0 15.3
1. M. Cohn, User Stories Applied for Agile Development. Addison-Wesley, 2004 2. J. Sutherland, A. Viktorov, J. Blount, and N. Puntikov, "Distributed Scrum: Agile Project Management with
Outsourced Development Teams," in HICSS'40, Hawaii International Conference on Software Systems, Big Island, Hawaii,
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I should understand how to set up a
Scrum Metrics Dashboard to support streamlined transparency and enable better
decision making by all stakeholders
241
© 2
00
6-2
01
5 S
cru
m In
c.
Five-Metric Dashboard to Track Progress
1. Release Burndown chart • Will we finish as expected?
2. Acceleration – Velocity over time • How much are we producing?
3. Business value per point • Are we producing the right things?
4. Happiness metric • Are we doing it sustainably?
5. Process efficiency • Deep dive on specific issues
242
Sprint
Velocity (points)
Quarter
Rev $/point
Sprint
Happiness rating
Role Company
Step 1 Step 2 Step 3 Step 4Queue
5 20
2 10 60
3 17
6 30
+ + + + = 16 137
(12%)
Sprint
Release Backlog (points)
400
© 2
00
6-2
01
5 S
cru
m In
c.
Looking at Metrics TogetherReveals Insight
243
Sprint
Velocity (points)
Quarter
Rev $/point
Sprint
Happiness rating
The Team is working well
Sprint
Velocity (points)
Quarter
Rev $/point
Sprint
Happi-ness
Team is driving velocity by focusing on easy, low-
value stories
Sprint
Velocity (points)
Quarter
Rev $/point
Sprint
Happi-ness
Team is burning out to deliver results
A B C
© 2
00
6-2
01
5 S
cru
m In
c.
“Business Value” a good concept, but what does it mean in practice?
244
At the end of the day, what is within the team’s control that delivers value to the company?
Actual Profit from work delivered
Actual Revenue from work delivered
Incremental Revenue over time
Forecast NPV of features delivered
Customer Impact (no. and level of interactions)
Incremental “Earned Value”
Better
Worse
• Actual • Real-time • Linked to
company results
• Modeled • Delayed • Company
result proxies
© 2
00
6-2
01
5 S
cru
m In
c.
What Does it Mean When BVPP Drops?
245
BVPP = Points (velocity)
Business Value
• Is “point inflation” occurring?
• Is the business value of each epic known?
• Is BV explicitly built into backlog prioritization?
• Are there no more high-value features left to deliver?
Improve Product Ownership process
Release product Get feedback on valuable features
Re-establish reference stories
© 2
00
6-2
01
5 S
cru
m In
c.
Scaling Metrics Across Multiple Teams
246
The Happiness Metric can be averaged across teams (it already is an index)
Sprint
Happi‐
ness
Point-based metrics cannot be aggregated meaningfully across teams…
…But percentage or indexed versions of the same metrics can!
Index = Current
Original
Sprint
Velocity
(points)
Percent = Planned
Remaining
Sprint
Velocity
(index)
1.0
Sprint
Release
Backlog
(points)
400
Sprint
Release
Backlog
(pct.)
100
%
© 2
00
6-2
01
5 S
cru
m In
c.
Automatic Reporting Via Scrum Tools
247
Backlog Tool
$
Financial DataHappiness Tool
API connection
1. Tap into data the team should already collect to manage their process
2. Pull and aggregate it automatically • API interfaces • “The Cloud”
3. Make it available to everyone to drive radical transparency
• Minimizes wasted effort generating reporting
• Team gets clear feedback • Leadership gets required
visibility • Creative solutions to “make
work visible” welcome!
• No additional work
Information “Radiator”
© 2
00
6-2
01
5 S
cru
m In
c.
An Example Scrum Leader’s Dashboard
248
rint
© 2
00
6-2
01
5 S
cru
m In
c.
Other Metrics that Leaders Track
• Points breakdown by category • How are we spending our effort?
• Financial burndown vs. budget • Are financial results on track?
• Happiness by team member • Are there pockets of unhappiness?
• Happiness vs. velocity • What is our current “optimal velocity?”
• Marketing/Sales pipeline • Are our future sales on track?
249
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a Great PO, it is helpful to
understand how Agile Contracts can enable my organization to partner
better
250
© 2
00
6-2
01
5 S
cru
m In
c.
Motivation: The Purpose of Legal Contracts
Elements of a Contract
• Promise to do something (Pledge)
• Exchange of value (Consideration)
• Agreement of additional terms
• Specifies what happens if one party fails to meet their promise
251
Value of Formal Contracts • Align both parties on what will be done • Set boundaries on the work, like scope and budget • Define what constitutes satisfactory completion • Describe what happens if there is a breakdown in
collaboration between the parties
Contracts are not for day-to-day management! If the
contract is being referenced, the project is already off track
© 2
00
6-2
01
5 S
cru
m In
c.
Limitations of Traditional Contracts
Traditional contract structures run into many problems, particularly when governing Agile work.
252
• Typically make change expensive to prevent “scope creep” • Vendor avoids hassle of change process
• Not easy to incorporate new learning • Difficult to respond to new market conditions
Discourage Change
• Assumes lack of trust between parties • Generally reward people for effort over delivering value • Discourages continuous improvement • Drive additional and unnecessary complexity • Often set unreasonable expectations
Incent Negatives
Outcomes
• Typically specifies required process rather than clarifying vision • Limits contract partners from being as innovative as they can be • Sets up distracting confrontational relationship over scope • Wastes time and effort to manage complex processes
• Prevents customer from getting what they actually want
Erodes Value
© 2
00
6-2
01
5 S
cru
m In
c.
Principles of Agile Contracting
253
Align Incentives
Collaborate & Be
Transparent
Build in Ability to
“Inspect and Adapt”
Pay for output, not effortEncourage vendors to create value, not waste time
Offer Money for nothingProvide “fair” way to end contract early if key value has been delivered
Offer Change for freeInclude mechanism to update scope without worrying about “scope creep”
Trust must be maintainedAssume parties act in good faith, spell out consequences if they don’t
Specify vision, not process
Clear goals/objectives in contract & reference backlog for detailed scope
Share the benefits of continuous improvement
Reward vendors for demonstrating improved efficiency
Establish regular feedback cycles
Specify Sprint cycle and review, retro, and backlog refinement meetings
Set the rules of engagement…
Identify roles & processes to give feedback, refine backlog, accept work
…But anticipate the unexpected
Define how likely extensions of initial contract will be handled
1
2
3
© 2
00
6-2
01
5 S
cru
m In
c.
Pay for Value Delivery, Not Time Spent: Not All Features Are Created Equal!
254
Valu
e t
o C
usto
mer
0
12.5
25
37.5
50
Features
65% of features provide little to no value,
are rarely used and/or aren’t actually
desired by the customer
The rest are OK,
but not as
important
80% of
value
typically
resides in
20% of
features
The fact that a large share of requested features end up being unimportant opens up many “win win” contracting opportunities
© 2
00
6-2
01
5 S
cru
m In
c.
Agile Contracts: Money for Nothing
1. Projects are usually prioritized by return on investment.
2. Ordering your Product Backlog allows you to prioritize features by return on investment.
3. Since 65% are never or rarely used, during the project it will become evident that the next low priority feature costs more than the value it delivers.
255
Valu
e t
o
Custo
mer
0
12.5
25
37.5
50
Features
4. Stop the project at that point and deploy the valuable features. Contractor and customer split remaining budget.
5. All projects should deliver early and save money. End project
here
Split this
remaining
budget
© 2
00
6-2
01
5 S
cru
m In
c.
Agile Contracts: Change for Free
1. Create a prioritized backlog of work to be done with highest business value items first.
2. Implement in short sprints, always less than a month.
3. When higher priority requirements emerge, put them in the next sprint.
256
4. Cut an equivalent amount of the lowest priority items out of the project to the work added. These features are unlikely to be used anyway.
5. Change for free allows you to meet your budget and deliver on time.
Valu
e t
o
Custo
mer
0
12.5
25
37.5
50
Features
For any
changes added
here
Remove an equivalent
amount of work here
© 2
00
6-2
01
5 S
cru
m In
c.
Share the Benefits of Continuous Improvement
257
Paid by Hour
Traditional Incentive
Structure
Common Undesired
Outcome
Better Incentive
Structure
• Rewards consumption of time • Actively discourages productivity
improvement
• Pay per point delivered
Overly Complex
Approval Process
Partially Completed
Functionality
Paid by Lines
of Code
Fixed Date
and Scope
• Slows delivery • Limits vendor’s ability to
experiment with process or
product improvements
• Encourages teams to cut corners
to deliver on time (E.g.
HealthCare.gov Web Launch)
• Incents enormous amounts of
Work in Progress (E.g. EVM)
• Rewards volume of output, not
quality • Discourages clean, concise code
(E.g. Hospital Medical Errors)
• Pay by business value delivered
• Only count releasable functionality in
business value delivered
• Pick one or the other!
• Have a single point of approval (like a
Product Owner) • Have enough of a process to
guarantee quality, and no more
© 2
00
6-2
01
5 S
cru
m In
c.
Trust, Vision and Regular Feedback Cycles
258
“Scope of work will be mutually negotiated through backlog.”
“Vendor will estimate point value of all features in the backlog.”
“For projects ended because sufficient value has been delivered, the vendor will receive 25% of remaining contract price. However this will not apply to projects ended due to breach of trust.”
“Currently, the website is divided among 3 different platforms with different levels of functionality. Our goal is to integrate these into a single platform with functionality that is editable by staff with limited need for on-going external support and maintenance.”
“Backlog will reflect the prioritized list of features in the upcoming sprint.”
“The vendor will meet with the purchaser for a weekly review meeting on Mondays to demonstrate newly created functionality.”
“Purchaser agrees to provide feedback on the demonstrated feedback in a timely manner.”
Trust must be maintained
Establish regular feedback cycles
Specify vision, not process
© 2
00
6-2
01
5 S
cru
m In
c.
Flexibility to Inspect and Adapt: The US Constitution as an Agile Contract
Sets the rules of engagement • Vision for system of government
• Three branches of government
• Branch powers and responsibilities
• How new laws are made
• Interactions between stakeholders
• When it comes into force
But leaves room to inspect & adapt • No actual laws included
• Provision for amendment
• Regular election cycle every 2-6 years
259
Same social contract still relevant ~250
years later
© 2
00
6-2
01
5 S
cru
m In
c.
What Agile Contracts Allow You to Do
260
Get things done faster
without penalizing the
vendor
Change direction easily
without raising cost
Unleash your contract
partner’s creative
potential
Satisfy the purpose of a
legal contract
Faster development time allows you to get
new innovations to market first and crush
the competition
Incorporate insights as you go to
consistently build a successful product that
customers actually want to buy
Informed partners can make better
decisions and may deliver innovative
solutions you never could have imagined
Avoid unpleasant surprises, “black hole”
projects and the potential consequences of
a chaotic breakdown in collaboration
© 2
00
6-2
01
5 S
cru
m In
c.
Illustrative Case Study: Scrum Inc. Web Migration – The RFP
261
What we did specify What we didn’t specify
Vision and context
Initial backlog of features • With expectation we will refine it
further together before contracting
Rules of engagement • Partner must be willing to use Scrum
• We will manage backlog together
• We expect “Change for Free”
• Demo every Monday at our Review
• We need access to demo site to test
Offered “Money for Nothing” to sweeten the deal
Specified that the contract would be AGILE, and what that means
Exactly what needed to be done
A fixed and defined scope
An elaborate set of procedures for
approval, cross‐checking and verifying
contract compliance
Not
Not
Not
Actual RFP available to view on ScrumLab
© 2
00
6-2
01
5 S
cru
m In
c.
Illustrative Case Study: Scrum Inc. Web Migration – Selecting a Vendor
262
RFP Posted online, tweeted, and e‐mailed to a
targeted group of 15 local service providers
Initial expression of interest and request for
further information from 150 companies
Initial screening based on: 1. Demonstrated projects 2. Familiarity with likely platforms 3. Past experience with or willingness to learn Scrum
Resulted in 9 short‐list candidates
Live meetings to discuss project and assess whether
vendors are truly agile. Focus on HOW we can work
together more than WHAT they have proposed
Team selection of best qualified vendor
Seattle‐based Portal Integrators unanimously selected as
preferred partner
Collection
Screening
Evaluation
Selection
1
2
3
4
5
© 2
00
6-2
01
5 S
cru
m In
c.
Illustrative Case Study: Scrum Inc. Web Migration – Our Agile Contract
263
Period of Performance
Engagement Resources
Scope of Work
Fee Schedule
Termination/Renewal
Client & Contractor Responsibilities
The contract has 6 sections:
• 1-week sprints, until ended by either party
• A Dev Team in the Philippines with a SM & Proxy PO • A customer Product Owner to answer any questions
• Clear goals for first 3 sprints (proof of concept) • After that, contract backlog will define scope
• Client provides feedback & maintains prioritized backlog • Contractor provides transparency and weekly demo
• Contractor is paid at the end of each 1-week sprint
• Both parties can decide to renew or cancel after each sprint review
© 2
00
6-2
01
5 S
cru
m In
c.
Illustrative Case Study: Scrum Inc. Web Migration – Working Together
264
Product Backlog
Refinement
Portal
Integrators
Team Sprint (1 week)
Team Sprint (1 week)
Sprint
Retrospective
Sprint
Planning
• Time carved out of regular weekly sprint
review to demo new Portal Integrators
functionality • Feedback incorporated into parallel
contract backlog
• Contract Backlog (Google Doc)
supports communication between
teams • Has “acceptance” step in addition
to normal Scrum board steps
• Designated contract Product
Owner (from customer) • Available to answer vendor
questions and clarify backlog
intent
Contract
Backlog
© 2
00
6-2
01
5 S
cru
m In
c.
Illustrative Case Study: Scrum Inc. Web Migration – The Results So Far
265
What has worked well Challenges
• Vendor makes excellent suggestions to improve product
• E.g. plug-ins that provided significant functionality rapidly
• Contract backlog makes clear: • What vendor is working on • What will be covered at the coming
review • What functionality vendor believes
is done • What has been officially accepted
• Review meetings provide collaborative dialogue
• Manage “discovered work” together
• Starting to develop release plans
• Significant effort to verify that vendors actually are agile • Many say they are…but aren’t
• Discipline needed for internal stakeholders to interact regularly with the draft product to provide feedback
• Contract backlog separate from main team backlog requires greater ongoing PO effort to coordinate
© 2
00
6-2
01
5 S
cru
m In
c.
Agile Contracts are Coming
Section 804 “Implementation of new acquisition process for information technology systems” added to the 2010 Defense Acquisition Bill. These are the rules that the Department must follow when purchasing anything.
266
The key language is: 2. Contracts must be designed to
include… A. Early and continual involvement of the
user;
B. Multiple, rapidly executed increments or releases of capability;
C. Early, successive prototyping to support an evolutionary approach; and
D. A modular, open-systems approach.
Basically, DoD now requires Agile Contracting!
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As a PO, I need to help eliminate Difficult Impediments
to improve team performance
267
Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System
By Durward K. Sobek II., Art Smalley
Managing to Learn: Using the A3 Management ProcessBy John Shook
© 2
00
6-2
01
5 S
cru
m In
c.
MIT Context
• MIT needs a Product Owner organization with a Chief Product Owner, a
product owner team, and a prioritized backlog for all projects in the
enterprise.
• Every MIT project is prioritized and every team has one Product Owner from
the Product Owner team to talk with.
268
© 2
00
6-2
01
5 S
cru
m In
c.
A3 Exercise
• MIT does not yet have effective Product Owner organization.
• What is the biggest challenge that blocks implementation?
269
© 2
00
6-2
01
5 S
cru
m In
c.
Root Cause Analysis
http://www.youtube.com/watch?v=IETtnK7gzlE
270
© 2
00
6-2
01
5 S
cru
m In
c.
Stories Aren’t Ready Before Sprint Planning
• Sprint Planning Meeting is tedious and takes a long time to complete, maybe even a full day
• Team has many questions during Sprint Planning that PO cannot answer during the meeting
• Stories are difficult to estimate at Sprint Planning • At the end of each Sprint there are several stories
not finished or not even started
Typical symptoms
•Team writing lots of new stories at Planning • New stories needed to deliver Sprint priorities
• Team sees upcoming work for the first time • Team not investing in
Refinement •Lots of unplanned work emerges during the Sprint
•Research or clarification often required to begin work planned
• Team hasn’t thought all work needed to deliver the story
• Team not investing in Refinement
•PO needs input from external stakeholders • Team needs more information to plan
• PO hadn’t anticipated required lead time • Team not investing in
Refinement
Root causes
SM encourage Team to look ahead • Adopt mindset of looking forward to anticipate
questions, dependencies and risks • Coordinate regular Refinement meetings for Team
and PO to discuss future sprints • Coach team to utilize INVEST criteria
PO meet with Team before each Sprint • Approach specific Team members with questions
needed to prepare Sprint Backlog • Attend Refinement meetings with Team to explain
upcoming work, get Team clarification • Clarify work with stakeholders before Planning
What to do about it
• Shorter and more effective Sprint Planning meetings (1 hour or less per week of Sprint)
• Few “surprises” during Sprint that could have been avoided with better planning
• Team finishes planned work ~80%+ of Sprints • Team and PO work together to Refine backlog
(expect 5-10% of the Team’s time)
Target end-state
Impediments
Re
ad
y
Do
ne
L
271
© 2
00
6-2
01
5 S
cru
m In
c.
Countermeasures (Experiments) • Proposed countermeasure(s) to address each
candidate root cause. [This should be a series of quick experiments to validate causal model analysis.]
• Identify where in the cause/effect model changes are possible and likely to significantly improve the overall situation.
• Predict results for each countermeasure.
Do
Background • Why is this important? • Why should the reader care about this situation and
be motivated to participate in improving?
P
Current Condition • How do things work today? • What is the problem? • Baseline Metrics?
L
Goal / Target Condition • What outcomes are expected for what reasons? • What changes in metrics can be plausibly expected?
A
Root Cause Analysis • What is the root cause(s) of the problem? • Use a simple problem analysis tool (e.g., 5 why’s,
fishbone diagram, cause/effect network) to show cause-and-effect relationships.
N
Owner: Mentor: Date:
Title: Concise, self-explanatory
A3 Template
272
© 2
00
6-2
01
5 S
cru
m In
c.
© 2011 Scrum Inc.
As an class group, we need a Course Review & Retrospective to capture our key learnings and things we will do
differently
273
© 2
00
6-2
01
5 S
cru
m In
c.
Product Owner Success Factors
• Availability
• Your customer and teams need a vision, strategy, and plan that is constantly evolving
• Knowledgability
• Assume that you don’t really know. Test your hypotheses. The market will educate you.
• Decisiveness
• Fast and clear prioritization will motivate your team and drive production
• Accountability
• You are directly responsible for measurable value creation.
274
Agile Product Ownership in a Nutshell
© 2
00
6-2
01
5 S
cru
m In
c.
Certification
• You should already have received an email from Scrum Inc which includes:
• A link to this slide deck
• A password for a free one-month subscription to ScrumLab
• You will get a second email from the Scrum Alliance with login instructions
• If there are any problems please contact [email protected]
276
© 2
00
6-2
01
5 S
cru
m In
c.
Stay Connected
Scruminc.com
• For up coming events, new content releases, and more!
ScrumLab • articles, online courses, tools, and papers on all things
scrum
• www.scruminc.com/scrumlab
Blog • http://www.scruminc.com/category/blog/
Online Courses • advance your scrum with our online courses. Visit the
Scrumlab store to view upcoming topics.
Twitter, Facebook, and G+
• @ScrumInc, @jeffsutherland, scrum and scrum inc.
277
© 2006-2015 Scrum Inc.
Qu
estio
ns?
278
© 2
00
6-2
01
5 S
cru
m In
c.
What Do We Mean by “Successful Innovation?”
1. Something new from a Product, Process, or Business Model standpoint…
1. …Actually delivered to the end customer…
1. …That addresses a real customer need… • Need may be known or unknown before the innovation is delivered
2. …And that can be delivered in a way that is attractive to the provider
• Provides sufficient margin and Return on Investment (ROI)
279
Innovation comes from two primary sources, and in two different types
E.g. Penicillin E.g. Toyota Prius
E.g. Powerbar E.g. Facebook
Source
Type
Happy
AccidentStructured
Experimentation
Breakthrough
Sustaining