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

http://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


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


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


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


We Buy

Snowflakes

1‐5 coins

21


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


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


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


Elements of Core Scrum

• Roles

• Meetings (ceremonies/rituals)

• Artifacts (social objects)

• Scrum Values (courage, commitment, focus, respect, openness)

27


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


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


Scrum Makes Work Visible

• Product Backlog

• Sprint Backlog

• Scrum Board

• Burndown Chart

• Show work remaining

• Velocity

Scrum is designed to be self-reporting

30


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


35

© 2011 Scrum Inc.

As a PO, I need a clear understanding of

All the Roles in Scrum in order to work well together


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


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


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


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


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


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

http://www.qsm.com/process_01.html

© 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.


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


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


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


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

http://www.isixsigma.com/dictionary/Kano_Analysis-263.htm

© 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


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


Epics and Business Value

• Epics are components of the enterprise’s vision

• Business value can best be estimated at this level

73


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/

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


in


Excel format

Register new user

Edit existing user

Delete user

Find user

100 simultaneous

users

Operations manual


in


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!


© 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 {



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() {



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!


© 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!


© 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


© 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


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


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


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


As a PO, I lead The Sprint Review to

ensure that we are delivering incremental value in each Sprint

113


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


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


As a PO I need to participate in the

Retrospective to capture learnings that allow us to become more efficient

116


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


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)


© 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.


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


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.


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


136The Impact of Agile Quantified. Rally, 2015.


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.


139

All Blacks, New Zealand http://www.youtube.com/watch?v=0C434QFTjok

http://www.youtube.com/watch?v=0C434QFTjok


Purpose of Daily Scrum

• Intensify team focus

• Collaboration and clarification

• Crush impediments

• Motivate team spirit

140


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


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.


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








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

http://maurits.wordpress.com/2011/06/08/a-simulation-to-show-the-importance-of-backlog-prioritization/

© 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

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.

© 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.

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: 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.

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

http://www.youtube.com/watch?v=IETtnK7gzlE

© 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

mailto:[email protected]

© 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

http://www.scruminc.com/category/blog/

http://www.scruminc.com/category/blog/

© 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

certified scrum product wner - scrum inc … · • scrum formation • autonomy • transcendence...

Documents