Вы находитесь на странице: 1из 233

SCRUM

THE

ART OF DOING TWICE THE WORK IN HALF THE TIME


!
!
!
!
!

States - 3440 in the Germany

With help from Citrix Online, Google, Yahoo, Microsoft, IBM, Oracle, MySpace, Adobe, GE, Siemens, Disney Animation,
BellSouth, Nortel, Alcatel-Lucent, EMC, GSI Commerce, Ulticom, Palm, St. Jude Medical, DigiChart, RosettaStone,
Healthwise, Sony/Ericsson, Accenture, Trifork, Systematic, Exigen Services, SirsiDynix, Softhouse, Philips, Barclays 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, 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, CWSBOCO, 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 Deer,
Mass IT, HP, Lockheed, Saab, European Union, EduScrum.com
1993-2014 Jeff Sutherland

2014 Scrum Inc.

534,339 (7%) open Scrum jobs in the

!
!
!
United
!

As a class group we need

Introductions

2
1993-2014 Jeff Sutherland

2014 Scrum Inc.

in order to work together effectively

Group Introductions
Whos in your group?
Pair introductions
Talk to each other and line up across

3
1993-2014 Jeff Sutherland

2014 Scrum Inc.

the room by level of Scrum


experience
Line up in a second dimension by job
function
What companies, industries, nonsoftware application are represented?

Self-Organize Teams
Based on line exercise, divide up into crossfunctional 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
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scrum Stuttgart
Doing

Done

5
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Do

Course Overview
Sprint 1: Day 1 morning
The Scrum Framework and its origins

Sprint 2: Day 1 afternoon


Patterns for starting Scrum

Sprint 3: Day 2 morning


Building and managing the Backlog

Sprint 4: Day 2 afternoon

6
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Team Backlogs
Advanced topics and closeout

Agenda - Sprint 1
Sprint 1 - Scrum Origins and Practice

Intro (2)
Team Learning Backlog (8)
Scrum Origins (9)
Agile Manifesto (5)
Airplane Game (9)
Getting Started (6)
Scrum Framework (8)

7
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint 2 - Starter Kit for a Scrum Master


Sprint 3 - Planning & Estimation
Sprint 4 - Team Backlogs & Review

Agenda - Sprint 2
Sprint 1 - Scrum Origins and Practice
Sprint 2 - Starter Kit for a Scrum Master
Roles - Project Manager Exercise (8)
Patterns (4)
Daily Clean Code (5)
Avoid Multitasking: Swarming (9)
Handle Interrupts (3)
Improve Flow - Constraint theory (2)
Identify Bottlenecks - Value Stream Mapping (3)
Remove Major Impediments - A3 exercise (7)
Scrumming the Scrum (6)

8
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint 3 - Planning & Estimation


Sprint 4 - Team Backlogs & Review

Agenda - Sprint 3
Sprint 1 - Scrum Origins and Practice
Sprint 2 - Starter Kit for a Scrum Master
Sprint 3 - Planning & Estimation
A3 Review (2)
Exercise: Daily Meeting (7)
Exercise: Scrum of Scrums (3)
Scrum Board (5)
User Stories (12)

Nice to have
* Money for nothing
* Velocity
* Technical Debt
* Acceptance tests

Exercise: Create User Stories (4)


Failed Scrum (9)
Exercise: Estimate Stories (7)

9
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint 4 - Team Backlogs and Review

Agenda - Sprint 4
Sprint
Sprint
Sprint
Sprint

1
2
3
4

Scrum Origins and Practice


Identify and Remove Impediments
Planning & Estimation
Advanced Topics and Review

Product Backlog Refinement (5)


Release Planning (6)
Teams Backlogs (27)

XP Game (12)
Dan Pink Video (1)
Certification/Handouts/Evaluations (1)

10
1993-2014 Jeff Sutherland

2014 Scrum Inc.

11
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master understanding the


Origins of the Agile Manifesto
will help me implement Scrum

Disruptive Leadership:
Life, Liberty, and the Pursuit of Happiness

Make Work Visible

Plans are Worthless, Planning is Everything!

Captain Edwin Atterberry Shot Down August 1967- Wikipedia

GANNT Chart

Landing the Project

YouTube: RF-4E of the Hellenic Air Force

Make Work Visible!

infoq.com

Continuous Improvement

Nonaka and Takeuchi


Type A Isolated cycles of work

NASA

Type B Overlapping work

Fuji Xerox
Scrum Project Management
Type C All at once

Honda, Toyota, 3M,

Agile Leadership

Sales, Marketing, Finance

Manufacturing

Technology, Software

Families and weddings

Education

Agriculture

Government

Space

Changing the World


Higher grades
Faster learning
More fun
Leadership Development
Involves handicapped
Motivated students
Self-discipline

eduscrum.com

23
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master understanding the


Agile Manifesto
will help me implement Scrum

Lean Enterprise Institute

Production
Techniques

Lean

Product
Creation

24
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scrum

Applicability of Scrum!
Ogunnaike and Rays Process Control Requirements!

Far from Agreement

Chaos

Requirements

Complex

Empirical Process (Scrum)


Lean

Complicated

Defined Process

Simple
Close to Agreement

Close to Certainty

Technology
Adapted from Snowdens Cynefin Framework - see Wikipedia

25
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Far from Certainty

Defined Process

Defined plan with one input and one output and (hopefully) no deviations
26
1993-2014 Jeff Sutherland

2014 Scrum Inc.

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)

Empirical Process

Empirical plan with a new input after each cycle

27
1993-2014 Jeff Sutherland

2014 Scrum Inc.

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.

Agile Manufacturing - Beyond Lean

28
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Agile competition goes beyond the Japanese


marketing strategies know as lean
manufacturing by permitting the customer,
jointly with the vendor or provider, to determine
what the product will be.
For agile competitors, the ability to individualize
products comes at little or no increase in
manufacturing cost. It does, however exact a
cost: It requires major changes in
organization, management philosophy, and
operations.

Agile Manifesto
www.agilemanifesto.org!
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:!
!

Individuals and interactions over processes and tools!


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

29
1993-2014 Jeff Sutherland

2014 Scrum Inc.

That is, while there is value in the items on


the right, we value the items on the left more.

Agile Manifesto Principles


1. Our highest priority is to satisfy the customer through early
and continuous delivery of Customer visible value.

7. Customer Visible Value is the primary measure of progress.

8. Agile processes promote sustainable development. The


sponsors, developers, and users should be able to maintain a
constant pace indefinitely.

2. Welcome changing requirements, even late in


development. Agile processes harness change for the
customer's competitive advantage.

3. Deliver Value frequently, from a couple of weeks to a couple


of months, with a preference to the shorter timescale.

9. Continuous attention to technical excellence


and good design enhances agility.

4. Business people and the Delivery team must work together


daily throughout the project.

10. Simplicity--the art of maximizing the amount


of work not done--is essential.

6. The most efficient and effective method of


conveying information to and within a delivery team is face-toface conversation.

12. At regular intervals, the team reflects on how to become


more effective, then tunes and adjusts its behavior
accordingly.

Survey: Mario Moreira

30
1993-2014 Jeff Sutherland

2014 Scrum Inc.

5. Build projects around motivated individuals.


Give them the environment and support they need, and trust
them to get the job done.

11. The best architectures, requirements, and designs emerge


from self-organizing teams.

State of Agile
Chaos Manifesto 2011, Standish Group International, Inc.

Source:
31
1993-2014 Jeff Sutherland

2014 Scrum Inc.

The agile process is the universal remedy for software development project
failure. Software applications developed through the agile process have
three times the success rate of traditional waterfall method and a much
lower percentage of time and cost overruns. The secret is the trial and error
and delivery of the iterative process.

32
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Source: Version One

Top 12 Failure Modes for Scrum

Overburdening team (bad management, no happiness metric)


No stable teams or people not assigned 100% to one team
Poor user stories, no clear definition of READY (bad product owner)
Taking too much into a sprint and failing to deliver working
software
Daily meeting not replanning and removing impediments
Not fixing bugs found inside a sprint, particularly integration bugs
Working on too many stories at once inside the sprint
Failure to have a plan for interruptions or emergencies
No clear definition of DONE
Not executing improvements identified in the retrospective

33
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scrum Production
!
!
!
!

34
1993-2014 Jeff Sutherland

2014 Scrum Inc.

How to Play the Game


Goal: See how good your team can get at making many airplanes
Each airplane must be made from of a sheet of Letter/A4-sized paper
Each team member may only do 1 fold of the paper at a time. You must then pass
the airplane to another team member to do the next fold.
Planes must have a blunt tip (so no injury if hit in the eye)
Each airplane must tested and shown to fly 3 meters in the testing area.
Planes may only be tested once; if it fails, it must be discarded.
Only successfully tested planes count towards your goal.
Work in progress (partially folded airplanes) must be discarded at the end of each
Sprint.
Teams are responsible for self-organizing, and deciding among themselves how to
manage the work, assign roles, etc.
Teams are not in competition with each other only with themselves.

35
1993-2014 Jeff Sutherland

2014 Scrum Inc.

36
1993-2014 Jeff Sutherland

2014 Scrum Inc.

One Person, One Fold

37
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Product Owner Tests

38
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Agile DC ScrumInc Build Party 2013

Amsterdam
32/33

39
1993-2014 Jeff Sutherland

2014 Scrum Inc.

World Record

Munich
32/32

As a Scrum Master I need to understand

How to Get Started

40
1993-2014 Jeff Sutherland

2014 Scrum Inc.

in order to begin a Scrum

Scrum is easy to understand but hard


to implement

41
1993-2014 Jeff Sutherland

2014 Scrum Inc.

A systematic approach to implementing


Scrum will give you the most benefit
fastest for the least effort.
The Shu Ha Ri concept from the martial
arts can help.

Aikido

42
1993-2014 Jeff Sutherland

2014 Scrum Inc.

The Way in Harmony with the Spirit

Making the Most of your Scrum


Shu state
Scrum Master sets up process as in the Scrum Guide. See

43
1993-2014 Jeff Sutherland

2014 Scrum Inc.

scrumguides.org. Team has a known velocity at a


sustainable pace
Retrospective is used to enhance performance
Review Core Scrum at agileatlas.org for Scrum Alliance
version of Scrum Guide.

Ha State

44
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Team has software done with all features tested


and no bugs at the end of a sprint.
Product owner has ready backlog at beginning of
the sprint (good user stories)
Team has data showing velocity and quality has
at least doubled.
Team is positioned to work towards
hyperproductivity, the design goal of Scrum

Ri State

45
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Teams look different. People will say this is not


Scrum
Software delivered multiple times in sprint
ancestry.com goes live 12 times per day
hubspot.com goes live 170-270 times per day

Team of One in Ri State

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

46
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Team needs to be hyperproductive.


But what does a great Scrum Master do?

47
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master I need to understand


the Scrum Framework
in order to implement Scrum

Scrum Framework
Scrum

Product
Backlog

Make Work
Visible

Product
Backlog
Refinement
Get Backlog Ready

Meeting Deliverables

Social
Objects
Scrum Board
Burndown
Points
Velocity

Sprint
Planning
Sprint Backlog

Roles

Scrum Master

Team
Ceremonies

Daily
Scrum
Replan

Sprint
Review
Product Increment!
Velocity!
Feedback

Retrospective

Kaizen

1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint
Backlog

Product
Owner

Scrum has Three Roles


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)

Scrum Master
Facilitates the Scrum process and Team self-organization
Removes obstacles and shields the team from interference
Responsible for improving performance of the team

Team
autonomy regarding how to achieve its commitments
typically 3-9 people
49
1993-2014 Jeff Sutherland

2014 Scrum Inc.

cross-functional (incl. testing)


self-organizing/-managing group of individuals, has

Scrum has Four Meetings


Sprint Planning
Product Owner presents READY backlog to Scrum Master and Team
Deliverable is Sprint Backlog

Daily Scrum
Team self-organizes to improve performance
Deliverable is new daily plan for implementation and impediment

removal

Sprint Review
Team presents backlog that is DONE to Product Owner and Stakeholders
Deliverable is velocity (what Product Owner confirms is DONE), feedback

(used to update Product Backlog), and potentially shippable Product


Increment

Retrospective

50
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scrum Master and team identify the top process improvement


Deliverable is the KAIZEN to put at top of Sprint Backlog for next Sprint.

Scrum Makes Work Visible


Scrum Artifacts
Product Backlog
Sprint Backlog
Amount of work remaining in Sprint
!

Useful tools
Scrum Board
Burndown Chart
Show work remaining

51
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Helps calibrate velocity

52
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint - Iterative and Incremental

1993-2014 Jeff Sutherland

2014 Scrum Inc.

53

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 ounce for
Scrum Inc.s leading thinking
That:
Clearly explains Scrum and its underlying principles (i.e. why
if works)
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
54
1993-2014 Jeff Sutherland

2014 Scrum Inc.

ScrumLab Vision Statement

55
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master I need to understand


Roles & Responsibilities
in order to implement Scrum

Scrum Value
Courage
Commitment
Openness
Focus

56
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scrum Master Role &


Responsibilities
Facilitator
Knowledgeable about the Scrum process
Coach Team and PO to enhance team performance
Removes impediments
Protects the team from interruptions
Holds Scrum values and practices

57
1993-2014 Jeff Sutherland
1993-2014 Jeff Sutherland

2014 Scrum Inc.

The Scrum Master Owns


The Process
Scrum is a simple framework that requires
consistent discipline
!

Scrum Master owns the process


Facilitates Daily Stand-Up
Facilitates Sprint Planning
Facilitates Retrospective
Protects the team
Removes impediments

58
1993-2014 Jeff Sutherland
1993-2014 Jeff Sutherland

2014 Scrum Inc.

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

59
1993-2014 Jeff Sutherland
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Spend the other half working closely with the team


clarifying specifications.

Delivers:
The right product set to excite customers
At the right time
In the order that maximizes business value

Value

A Successful Product Owner

Time

Responds dynamically to change faster than competitors


Clarifies customer need to development teams so that
uncertainty is removed and developer velocity is
maximized
!

$
60
1993-2014 Jeff Sutherland
1993-2014 Jeff Sutherland

2014 Scrum Inc.

The Product Owner is ultimately accountable for


winning in the market!

Scrum Master
Works with the Product Owner to:
Find techniques for effective Product Backlog

61
1993-2014 Jeff Sutherland

2014 Scrum Inc.

management;
Clearly communicate vision, goals, and Product Backlog
items to the Team;
Teach the Scrum Team to create clear and concise Product
Backlog items;
Understand long-term product planning in a Scrum
environment;
Understand and implement the values of the Agile
Manifesto; and,
Facilitate Scrum events such as release planning

Teams are:

62
1993-2014 Jeff Sutherland
1993-2014 Jeff Sutherland

2014 Scrum Inc.

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
Collaborative - they work together to achieve the
Sprint goal
No more than 3 - 9 people

Basic Truths about Teams


Team motivation
People are most productive when they manage themselves.
People take their commitment more seriously than other peoples commitment for

them.
People do the best they can.
Under pressure to work harder, developers automatically and increasingly reduce
quality.

Team performance
Teams and people do their best work when they arent interrupted.
Teams improve most when they solve their own problems.
Broad-band, face-to-face communications is the most productive way for teams to

work together.

Team composition
Teams are more productive than the same number of individuals
Maximum effective team size is around 7-8 people.

the work
Changes in team composition reduce productivity.
Source: Ken Schwaber

63
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Products are more robust when a team has all of the cross-functional skills focused on

Leadership Responsibilities
Provide challenging goals for the teams
Create a business plan and operation that works
Set up the teams (in collaboration with teams)
Provide all resources the teams need

Identify and remove impediments for the teams


Know velocity of teams
Understand what slows teams down
Remove waste

64
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Hold Product Owners accountable for value


delivered per point
Hold Scrum Masters accountable for process
improvement and team happiness

Exercise: Project Manager/Leader

65
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a team, write down all responsibilities of a


traditional project manager/leader
Put one responsibility on each sticky note
Time: 4 minutes

Exercise: Project Leader


Sort Project Leader responsibilities on sticky
notes into these five categories
Product Owner
Scrum Master
Team
Waste
Other
!

66
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Time: 5 minutes

Problems with Traditional Project Model

67
1993-2014 Jeff Sutherland

2014 Scrum Inc.

GANTT charts are unreliable


Too much time is spent trying to unsuccessfully
resolve dependencies in the GANTT chart
Project Managers annoy teams by constantly
requesting estimate updates in hours
Teams do not take responsibility for the plan
Some of the best people are the Project Leaders
who could be doing productive work

Scrum Patterns

As a Scrum Master I need to understand

Common Pitfalls and Solutions

68
1993-2014 Jeff Sutherland

2014 Scrum Inc.

to enable a high performing team

69
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Its all about technique ...

Scrum Patterns - scrumplop.org

70
1993-2014 Jeff Sutherland

2014 Scrum Inc.

A pattern is a problem statement/solution pair.


It identifies forces that cause the problem
It proposes a common solution that is known to work
in at least three different companies.
It is workshopped by Scrum experts and not published
until experts agree that its quality and effectiveness
are excellent.
It encapsulates the valuable knowledge of the global
Scrum community.

Scrum Team Hyperproductive Pattern Language


Teams that Finish Early Accelerate Faster
Stable Teams - How you get started
Yesterdays Weather - How you pull backlog into a sprint
Daily Clean Code - How to get defect-free product at sprint end
Swarming - How you get work done quickly
Interrupt Pattern - How to deal with interruptions during the sprint
Stop the Line - How to deal with emergencies
Scrumming the Scrum - How to ensure you improve continuously

Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams!
47th Hawaii International Conference on System Sciences (HICSS) !
By Jeff Sutherland, Neil Harrison, Joel Riddle !
January 2014
71
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Happiness metric - How to ensure teams arent overburdened

Run a Lean Scrum

As a Scrum Master my Team

needs to have Daily Clean Code

72
1993-2014 Jeff Sutherland

2014 Scrum Inc.

to double production and quality

73
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Taiichi Ohnos Taxonomy of Waste

The 7 Wastes of Software


Development Features and functions used in a typical system:
Partially done work
Extra features
Lost knowledge
Handoffs
Task switching
Delays
Defects

Always
7%

Never
45%

Only 1/5 of the


stuff we build is used
often or always!

Often
13%

Sometimes
16%

Rarely
19%
2/3 of the stuff we
build is rarely or
never used!

Source: Standish Group Study Reported at XP2002


by Jim Johnson, Chairman

There is surely nothing quite so useless as doing with


great efficiency what should not be done at all.
Peter Drucker
74
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Systematic Strategy for Lean


Level\Dimension
Production

Value

Flow

Pull

Perfection

P6 Build Integrity in

P2 Amplify Learning P2 Amplify Learning

P6 Build Integrity In

T19 Refactoring
T20 Test

T5 Synchronization
T4 Iterations

T18 Conceptual
integrity
T17 Perceived

T3 Feedback
T6 Setbased
development

integrity!

Management

P1 Create Value

P4 Deliver Fast

P7 See the Whole

T1 Eliminate Waste

T11 Queue theory

T22 Contracts

T2 Value streams

T12 Cost of delay

T21 Measurement
T10 Pull

People

P3 Defer Commitment
T7 Options thinking
T8 Defer commitment
T9 Decisionmaking

P5 Empower team

P5 Empower team

P5 Empower team

P5 Empower team

T16 Expertise

T14 Motivation

T15 Leadership

T13 Self determination

Thinking tools are best transformed by people and projects


75
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Tools divided
into three
dimensions

Systematic Pilot Results


Project effort
100%

100 %

Rework
Work

90%
80%

CMMI
50 %

70%

Process focus

69 %
9%

SCRUM

60%
50%

50 %

40%

35 %
4%

50 %

25 %

20%
10%
CMMI 1
Source: Systematic Software engineering 2006

10 %

6%

CMMI 5

CMMI 5
SCRUM

76
1993-2014 Jeff Sutherland

2014 Scrum Inc.

30%

Impediments
Data driven removal of impediments using control charts from 11/2007
Examples on causes:
!

Special competencies
Disk full
Setup misunderstood
COTS failed

Root cause analysis of time to fix a bug automatically


generates Scrum Masters impediment list.

77
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Daily Clean Code Pattern


scrumplop.org
!

... bugs turn into features at midnight ...


Here we discuss bugs that arise within the sprint. Preexisting bugs should be prioritized
by the Product Owner and managed in the Product Backlog. Bugs appearing from outside
the sprint such as customer emergencies should be handled by the Illigitimus non
Interrupus pattern.
It is natural to want to keep a list of bugs. There are several forces that encourage this.
One of the most compelling reasons to put bugs on a bug list is that developers are
busy with other tasks, and shouldnt be interrupted.
Managers can see that adding new features increases revenue, but fixing bugs does
not apparently increase revenue. If the team has a fuzzy Definition of Done, work
might be considered Done.
Bugs that arrive might be considered low priority, and its nice to have a place to put
them.
In short, deferring the fixing of bugs until later is borrowing against your future velocity.

Therefore: Fix all bugs in less than a day.


78
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Velocity is limited because a team spends time dealing with too many bugs.

Good Agile: Use Definition of Done to


Drive Performance
Daily
Meeting

R
E
A
D
Y
Value

Remove
Impediments

D
O
N
E

R
E
T
R
O
S
P
E
C
T
I
V
E

Velocity

79
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint

Scrum Patterns

As a Scrum Master I need to encourage

Swarming

80
1993-2014 Jeff Sutherland

2014 Scrum Inc.

to enable a high performing team

Exercise: Never Keep Customers Waiting

Never keep a
customer waiting
!

Start early
= Finish early

LIS
BOB
ERI
M AR

Dave
Lisa

Bob

Eric
Maria

81
1993-2014 Jeff Sutherland

2014 Scrum Inc.

D AV E

Round 2 Swarming

Limit WIP
(work in process)
!

Current limit =
1 customer
at a time

Dave

L I SA

Lisa

Bob

Eric
Maria

82
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Policy

D AV E

83
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Discussion what was the


difference? Why?

Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284.
84
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Weinberg Table of Project Switching Waste

Prioritizing Between Projects


Product A

A1

A2

A3

Product B

B1

B2

B3

Product C

C1

C2

C3

Traditional strategy: Everything is important! Do it all at once!

A1

B1

January

C1

February

A2

B2

C2

April

March

May

A3

B3

C3

June

July

June

July

Agile strategy: Prioritize & focus!

January

B
B

February

March

C
C
April

C
May

Adapted from Henrik Kniberg


85
1993-2014 Jeff Sutherland

2014 Scrum Inc.

This product rocks!

Swarming

Care about the whole product


Boy are we effective
as a team!

Im more efficient if I just do my


tasks

Source: Revised after Henrik Kniberg

86
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Not just your little task

87
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Enterprise Level Swarming

88
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master I need to manage


Interruptions
in order for the team to be successful

Illigitimus Non Interruptus


Beginning of sprint

Product
Backlog

Sprint
Backlog

Support

Kaizen

5
3
5

5
8
5
3

Management
Now

PO

Sales

10

Later

Low Priority
On Buffer Overflow ABORT, Replan, Dates Slip
89
2011-2014
1993-2014 Jeff Sutherland

2014 Scrum Inc.

90
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master I need to optimize


Flow
in order for the team to be successful

Theory of Constraints Smooth Flow


Goal

PO

SM

Problem

Strategy

int

ak

ak

Typ
2.

Fix

ce

int

Typ

x
ne

du

se

x
Fi

Re

rea

4.

1.

Inc

91
1993-2014 Jeff Sutherland

2014 Scrum Inc.

3.

Case Study:
Developing Products >5x Faster

92
1993-2014 Jeff Sutherland

2014 Scrum Inc.

A real-life example of applying Value


Stream Mapping and Scrum to
dramatically speed up product
development.

Design-ready games

Game backlog

15

Sam
1m
2h

4h

6m

Lisa
assigns
resources
1d

1w

Graphics
design
1m

Games out of date


Missed market windows
Demotivated teams
Overhead costs

Sound
design
3w

12

Dev
6m

6m

3m
(1m+2m)
3.5 m value added
time
25 m cycle time

Integr. &
deploy

3w
Process
= 14% cycle
efficiency

Estimate

w1 w2 w3 w4 w5 w6 w7 w8

2 m cycle time

= 12x faster

Preliminary result
3-4 m cycle time = 6-8x faster

w1 w2 w3 w4 w5 w6 w7 w8
Source: Henrik Kniberg
93
1993-2014 Jeff Sutherland
1993-2013 Jeff Sutherland

2014 Scrum Inc.

2d

Concept
pres.

Production-ready games

Case Study
Take-away Points

w1 w2 w3 w4 w5 w6 w7 w8

Speeding up product development is often a matter of


improving the process rather than adding people.
Value stream mapping is a great tool for spotting
bottlenecks
Scrum is a great tool for removing bottlenecks
But beware the trap suboptimization!! Hey, lets do Scrum here! Maybe
we can cut dev time in half!
The pictures make it look easy....
From 3 months to 1.5 months...
But executing the change is usually hard

2d

1m
2h

Lisa assigns
resources
6m

4h

Graphics
design

Sound
design

1w
1d

6m
1m

Source: Henrik Kniberg

3w

Integr. &
deploy

Dev
6m
3m
(1m+2m)

3w

94
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Concept
pres.

Sam

Managing to Learn: Using the A3 Management Process


By John Shook

Eliminating Challenging Impediments


A3 Process

Understanding A3 Thinking: A Critical Component of Toyota's


PDCA Management System

95
1993-2014 Jeff Sutherland

2014 Scrum Inc.

By Durward K. Sobek II., Art Smalley

Exercise

96
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Think of the most difficult problem in your


company.
Share the problem with the team.
Team pick the most interesting problem to write
an A3.
The person with the real problem picked by the
team is the Product Owner
Develop an A3 in three short sprints (8 minutes
each) that will enable the Product Owner to
return to his/her company and implement a
countermeasure.

http://www.youtube.com/watch?v=IETtnK7gzlE
97
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Root Cause Analysis

1993-2014 Jeff Sutherland

2014 Scrum Inc.

98

Venture Company Example


A3 Process Creates Pull-Based Authority
Background
Teams not getting software done and tested
Critical components failing every other sprint

P
Current Condition
Engineers not working together?
Inability to test causing failure
Waste estimated at 2.1M Euro/year

Goal / Target Condition


Clean tested code worked at end of sprint
Cut waste by 90%
Save 1.8M Euro/year while improving quality

Root Cause Analysis


Why- engineers had different design concepts
Why- Team members not communicating
Why- Scrum Master not doing good job
Why- No continuous integration
Why- Product Owner focused on new features
Why- Product Owner is CEO

Owner:
Mentor:
Date:

Countermeasures (Experiments)
Meet with board member
Conference call with CEO
Commitment to implement continuous
integration
Site visit to demonstrate working processes

Do
Confirmation (Results )
Clean implementation in one month
Velocity of seven teams average increase of 20%
Immediately savings of 1.7M Euro/year
Cost of implementation 3000 Euro for expert
consultant

Check
Follow-up (Actions)
Introduced prioritized automated testing
Introduced code reviews
Cut deployment time in half
Cut support calls in half
Increased sales
A3 Thinking Durward Sobek

Act
99
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Title: Seven teams failing too many sprints

A3 Template
Title: Concise, self-explanatory

Background
Why is this important?
Why should the reader care about this situation
and be motivated to participate in improving?

Current Condition
How do things work today?
What is the problem?
Baseline Metrics?

Goal / Target Condition


What outcomes are expected for what reasons?
What changes in metrics can be plausibly
expected?

Owner:
Mentor:
Date:
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
A

N
100

1993-2014 Jeff Sutherland

2014 Scrum Inc.

Root Cause Analysis


What is the root cause(s) of the problem?
Use a simple problem analysis tool (e.g., 5 whys,
fishbone diagram, cause/effect network) to show
cause-and-effect relationships.

101
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master I need to


Scrum the Scrum
to get an effective Retrospective

Sprint Retrospective
What happened?

First story
ready for
test

New desks
installed

Week 1

Half-day
nce
confere
Sam sick

Big
argument

Story #25
removed
from sprint

Server
crashed

LAN
shootout

Week 2

New build
server

Team flow!

Sprint
demo

Week 3

Source: Henrik Kniberg

102
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint
planning

Source: Henrik Kniberg

103
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint Retrospective

Sprint Retrospective
Velocity

Long term effect

1 2 3 4 5 6 7 8 9 10 11 12 13
Sprint

Effective velocity over time


(without retrospectives)

Source: Henrik Kniberg

104
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Effective velocity over time


(with retrospectives)

Powering Up the Retrospective


Identify the top process improvement
Create acceptance tests
Put it in the sprint backlog as top priority
!

This is called Scrumming the Scrum


!

105
1993-2014 Jeff Sutherland

2014 Scrum Inc.

An easy way to identify top process improvement


is the Happiness Metric

Happier People Function Better

106
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Doctors in a positive mode show three times the


intelligence and creativity and diagnose 19%
faster.
Optimistic salespeople outsell pessimistic
counterparts by 56%.
Happier CEOs are 15% more productive.
Happier managers improve customer satisfaction
by 42%.
Research shows that happiness causes better
performance

Happiness Metric
On a scale of 1 - 5 we rate
How do you feel about your role?
How do you feel about the company?
What would make you feel better?
With data from Happiness Metric, order individual and
company improvements by value - then Scrum the
Scrum

Vote for highest value

Estimate value
107
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Rules

108
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Only address one impediment


Put the kaizen in the backlog for the sprint Scrum the Scrum
Action should usually yield results quickly
Communicate actions (and success or not) back
to the Team
And the hardest rule: Use common sense.

0"

2011-2014
1993-2014 Jeff Sutherland

2014 Scrum Inc.

10/27/13"

8/27/13"

6/27/13"

4/27/13"

2/27/13"

12/27/12"

10/27/12"

8/27/12"

6/27/12"

4/27/12"

2/27/12"

12/27/11"

10/27/11"

8/27/11"

6/27/11"

4/27/11"

2/27/11"

12/27/10"

10/27/10"

8/27/10"

6/27/10"

350"

4/27/10"

2/27/10"

12/27/09"

150"

10/27/09"

8/27/09"

6/27/09"

4/27/09"

Results: Scrumming the Scrum Using Happiness Metric


Raw Scrum Inc. Velocity History
(not adjusted for fluctuation in team capacity by sprint)

300"

250"

200"

16x output with


4x FTEs = 4x

100"

50"

Scrum is mandatory reading for any leader, whether theyre leading troops on the battlefield or in the marketplace.
The challenges of todays world dont permit the luxury of slow, inefficient work. Success requires tremendous speed,
enormous productivity, and an unwavering commitment to achieving results. In other words success requires Scrum.!
--General Barry McCaffrey
!
Jeff Sutherland has written the essence of Scrum for the masses. In this easy-to-read book, which is filled with lively
stories, apt metaphors, and illuminating quotes, Jeff has converted all the tacit knowledge he has gained -- as a West
Point cadet, fighter pilot in Vietnam, Aikido enthusiast, academic, technology expert, and father of Scrum -- into wisdom.
This book elevates Scrum from a fix-it tool to a way of life.!
--Hirotaka Takeuchi, Professor of Management Practice, Harvard Business School
!
Jeff Sutherland's book masterfully speaks truth to the political complexities that easily stand in the way of getting
a lot of work done in the least amount of time. He lays out a doctrine of simplicity, showing -- with surprising insight -how to categorize roadblocks, systematize solutions, choose action over prolonged study, and retain the important
emotional aspects of work that ground meaningful interactions. The busy professionals wholl likely be drawn to this
book will find not only an effective manual for getting things done but, also, a how-to guide for living a meaningful
life.!
--John Maeda, Design Partner, Kleiner Perkins Caufield & Byers
!
This extraordinary book shows a new way to simplify your life and work, increase your focus, and get more done
in less time than you ever thought possible.!
--Brian Tracy, bestselling author of Eat that Frog and Time Power
!
EngagingSutherland tackles the problem of the perennially late, over-budget projectand actually shows how
to solve it. His fascinating examples of rescued projects will change the way you think and act."!
--Dorothy Leonard and Walter Swap, authors of Deep Smarts: How to Cultivate and Transfer Enduring Business Wisdom
!
Jeff Sutherland is the master of creating high-performing teams. The subtitle of this book understates Scrums
impact. If you dont get three times the results in one-third the time, you arent doing it right!
--Scott Maxwell, Founder & Senior Managing Director, OpenView Venture Partners

110
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Preorder discounted new Scrum book


on Amazon or Barnes and Noble! Get
free signed copy of Power of Scrum!

SCRUM: TWICE

THE

WORK

Sbastien Chabal

IN

HALF

THE

TIME
111
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Preorder and
get free Power
of Scrum

1993-2014 Jeff Sutherland

2014 Scrum Inc.

112

113
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master I need to


Run a Good Daily Meeting
to help the Team improve performance

Motivation for Daily Scrum

% Saturation

120
100

Bell Labs Pasteur Project!


82 Companies

80
60
40
20
0
0

20

40

60

80

Communication Saturation and Roles. Organizational Patterns of Agile Software Development by


Coplien and Harrison (2004)
114
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Number of Roles

115
1993-2014 Jeff Sutherland

2014 Scrum Inc.

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

Purpose of Daily Scrum


Build team focus
All arms linked - intense collaboration
Mental attitude - we will crush impediments
Create team spirit

116
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Daily Scrum Meeting


15 minutes


What did I do yesterday that helped the Team meet the Sprint goal?

117
1993-2014 Jeff Sutherland

2014 Scrum Inc.


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?

Brooks Law:
Adding People to a Late Project Makes It Later

3-5

5-7

9-11

15-20

Optimal team size is 4.6 people according to Harvard research.

Source: http://www.qsm.com/process_01.html (491 projects)

118
1993-2014 Jeff Sutherland

2014 Scrum Inc.

1.5-3

Scrum of Scrums

Waterfall Comm Paths!


n(n-1)/2 for 120 people!
120(119)/2 = 7140!
!

Communication Paths!
n(n-1)/2 per team!
5(4)/2 = 10!
24 teams(10) = 240!
+ a few cross team!
80% less comm
119
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scrum is an object-oriented
organizational framework!
The organization will need to be
refactored to maximize flow!
Small steps regularly!
Large changes periodically

Manufacturing Scrum of Scrums


First Zero Defect Release

After failed software releases we adopted a program Scrum-Of-Scrums


!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
-Very uncomfortable for people in the beginning
-Huge impact on communications and problem resolution

!!
!
I was reluctant at first but the Daily Scrum of Scrums was the key reason this is the
best launch in our history...

Adapted from Slides By Chris Sullivan


120
1993-2013
1993-2012Jeff
JeffSutherland
Sutherland
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Manufacturing Manager

121
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master I need to act on


Scrum Board Warning Signs
in order to improve team performance

Visual Flow Tools


Principle 7 of the Toyota Way is to use visual
control to improve flow
Visual control is any communication device used in the

work environment that tells us at a glance how work


should be done and whether it is deviating from the
standard.
It helps employees who want to do a good job see
immediately how they are doing.

Scrum artifacts are visual flow tools


The Scrum Board is not a core artifact in the Scrum Guide.

122
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Yet it is an extremely useful tool used by almost all Scrum


teams.

1993-2014 Jeff Sutherland

2014 Scrum Inc.

123

Sprint: Day 0
To Do:

Doing:

Sprint Goal:
Get a ready release!

Done!

Burndown

Daily Clean
Code

3pts

Kaizen

100

Buffer
33

Deposit

90
80

Points

70

code
write a failing
cleanup. 2
test.. 2 pts.pts


Integration
test

2 pts

DAO

3pts

60
50
40
30
20
10

Backend
Login
Backend
User
Admin

write a failing
pts.

Miigration
8 pts
test..
2

Days

Implement
Integrate w//
GUI

boss

5 pts
8 pts

GUI design

Clarify Req

write a failing 5 ptsImplement 3 pts
test.. 2 pts.

GUI

5 pts

124
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Migration
Tool

Tapestry ry
spike

code
write a failing
8 pts
cleanup. 2 test.. 2 pts.
GUI spec


Miigration 8
2 pts pts
pts

Sprint Backlog: After First Meeting


To Do:

Doing:

Sprint Goal:
Get a ready release!

Done!

Burndown

Daily Clean
Code

3pts

Kaizen

100
90

Buffer
33

70

code
cleanup. 2
pts
Integration
test

2 pts

write a failing
test.. 2 pts.

DAO

3pts

DB Design

3pts

Points

Deposit

80

60
50
40
30
20
10

Tapestry ry
spike

8 pts

code
cleanup. 2
pts Miigration 8
pts

Backend
Login

write a failing
test.. 2 pts.

Backend
User
Admin

GUI design

Clarify Req

5 ptsImplement 3 pts
write a failing
GUI

test.. 2 pts.

5 pts

write a failing
test.. 2 pts.

Days

Integrate w//
boss
Implement
8 pts
GUI

5 pts

125
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Migration
Tool

GUI spec
2 pts

Sprint Backlog: Day X


To Do:

Doing:

Sprint Goal:
Get a ready release!

Done!

Burndown

Daily Clean
Code

3pts

Kaizen

100

Buffer
23

90

Sales Support

3pts

Fix Bug

2 pts

White Paper

5 pts

80

Deposit

code
write a failing cleanup. 2
test.. 2 pts.
pts
DB Design

3pts
Integration
DAO

test

3pts

2 pts

Points

70
60
50
40
30
20
10

Backend
Login
Backend
User
Admin

code
cleanup. 2
pts

Miigration 8
pts

Integrate w//
boss
Implement
Miigration 8 pts
GUI

8 pts
5 pts

write a failing Tapestry ry


spike

test.. 2 pts.

8 pts

GUI spec
2 pts

Days

write a failing
test.. 2 pts.

GUI design

Clarify Req

5 ptsImplement 3 pts
write a failing
test.. 2 pts.

GUI

5 pts

126
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Migration
Tool

127
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scrum Board Warning Signs

Warning Sign #1
To Do:
Kaizen

Doing:

Sprint Goal:
Get a ready release!

Done!

Burndown

Daily Clean
Code

100
90

Buffer
33
Deposit

80

Points

70

code
cleanup. 2
write a failing
pts
DB Design
test.. 2 pts.

Integration
3pts
DAO

test

3pts

2 pts

60
50
40
30
20
10

Backend
Login

GUI spec
2 pts
Tapestry ry code
spike
cleanup. 2
pts
8 pts

write a failing
test.. 2 pts.

Miigration 8
pts

Implement
GUI

5 ots

Days

Integrate w//
boss

8 pts

write a failing
test.. 2 pts.

Backend
User
Admin

GUI design

Clarify Req

write a failing 5 ptsImplement 3 pts
test.. 2 pts.

GUI

5 ots

1993-2014 Jeff Sutherland

2014 Scrum Inc.

Migration
Tool

Warning Sign #2
To Do:

Doing:

Kaizen

Sprint Goal:
Get a ready release!

Done!

Burndown

Daily Clean
Code

100
90

Sales Support

3pts

Deposit

code
cleanup. 2
write a failing
pts
DB Design
test.. 2 pts.

Integration
3pts
DAO

test

3pts

2 pts

Marketing
Demo

5 pts

Fix Bug

2 pts

Fix Bug

2 pts

White Paper

5 pts

Customer
Down!

13 pts

80
70

Points

Buffer
3

60
50
40
30
20
10

Backend
Login
Backend
User
Admin

code
Tapestry ry
cleanup. 2
spike

pts
8 pts

Integrate w//
Miigration
boss
8 pts
8 pts

write a failing
test.. 2 pts.

write a failing
test.. 2 pts.

Miigration 8
pts

Days

write a failing
Implement
GUI
test.. 2 pts.

5 ots

GUI design

Clarify Req

5 ptsImplement 3 pts
GUI

5 ots

129
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Migration
Tool

GUI spec
2 pts

Warning Sign #3
To Do:

Doing:

Sprint Goal:
Get a ready release!

Done!

Burndown

Daily Clean
Code

Kaizen

100

Migration
Tool

Backend
Login
Backend
User
Admin

White Paper

5 pts

write a
DB Design

failing test.. 2 code
3pts

cleanup. 2
DAO
pts.

pts
3pts

Integration
test

2 pts

80
70
60
50
40
30
20

write a
failing test.. 2
Miigration 8 pts.

pts

code
cleanup. 2
pts

Implement
GUI

5 ots

Miigration 8 pts

GUI design

5 ptsImplement
GUI

5 ots

GUI spec
2 pts
Tapestry ry
spike

8 pts

10
0

Days

write a
failing test.. 2
Integrate
pts.

w//boss

8 pts

Clarify write
Req
a failing
3 pts test.. 2 pts.

130
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Deposit

Fix Bug

2 pts

90

Customer
Down!

13 pts

Points

Buffer Buffer
12
33 Points

Source: Jim Coplien

131
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Swimlane Scrum

Scrum Board Contest Winner

132
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scrum Board on Steroids

Teams That Finish Early Accelerate Faster


scrumplop.org

Daily
Meeting

R
E
A
D
Y
Value

Remove
Impediments

D
O
N
E

R
E
T
R
O
S
P
E
C
T
I
V
E

Velocity

133
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint

134
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Product Backlog and User Stories

Product Backlog

135
1993-2014 Jeff Sutherland

2014 Scrum Inc.

The Product Backlog consists of work to be done


ordered by business value
Anyone can put anything on the backlog
Product Owner is the final authority on ordering
the backlog.
The backlog consists of Product Backlog Items
(PBIs)
The majority of Scrum teams use User Stories as
PBIs.

User Story

136
1993-2014 Jeff Sutherland

2014 Scrum Inc.

A UserStory is a story, told by the user, specifying how the


system is supposed to work, written on a card, and of a
complexity permitting estimation of how long it will take to
implement.
The UserStory promises as much subsequent
conversation as necessary to fill in the details of what is
wanted.
The cards themselves are used as tokens in the planning
process after assessment of business value and [possibly]
risk.
The customer prioritizes the stories and schedules them
for implementation. -- RonJeffries

User Story Templates

137
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a <role> I would like to be able to <action> to


achieve <business value>

138
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Whats Wrong with This Story?

Break Epics into Stories

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 I can be more
comfortable
139

1993-2014 Jeff Sutherland

2014 Scrum Inc.

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

User Story - Guidelines


Product vision

Product
Backlog

A
B
C

Immediately actionable
Negotiable
Valuable
Estimable
Sized to fit
Testable
Modified from Bill Wake www.xp123.com

A B C
!

Customer facing value


delivered every sprint
!

Slices accumulate in value

GUI

Client
Server
DB schema

Stuff not
needed
140
1993-2014 Jeff Sutherland

2014 Scrum Inc.

User Stories slice through all


layers

One Companys Definition of Ready!

141
1993-2014 Jeff Sutherland

2014 Scrum Inc.

User Story, Acceptance Tests, Examples, Wire frame, Estimates

User Stories Improve


Communication Effectiveness
2 people at
whiteboard

Effective

Google Hangout
2 people on
phone
Communication
effectiveness

Cold

ti
s
e

r)
e
w

ti
s
e

u
q
o
N
(

an
n

Richness (temperature) of
communication channel

Hot

Source: research from McCarthy and Monk (1994)

142
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Document

an
n

u
Q
(

2 people
on email

Ineffective

s
n
a
d-

Video
recording

Audio
recording

r
e
w

Irrelevant Information
Spec 1

Same spec
+ irrelevant details

A
B

B
C

20 hrs
39 hrs
SM

Source: How to avoid impact from irrelevant and misleading


info on your cost estimates, Simula research labs estimation
seminar, Oslo, Norway, 2006

143
1993-2014 Jeff Sutherland

2014 Scrum Inc.

SM

User stories notes may be enough for a web site


For a complex system you need enabling specification
Short - 3-5 pages for a feature
Usually a lightweight use case
Product Owner documents critical information in
collaboration with team
User experience (design)
Business logic
Data structures
Stories are derived from the enabling specification
The enabling specification is a living document
Updated over time
Global picture of the feature
Allows traceability of stories back to product design
144
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Enabling Specification

Use the Definition of Ready to Improve


Team Performance
Daily
Meeting

R
E
A
D
Y
Value

Remove
Impediments

D
O
N
E

R
E
T
R
O
S
P
E
C
T
I
V
E

Velocity

145
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint

146
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Create User Stories Exercise

Exercise Background
General situation
Today is Jan 1.
The government has announced Outlook will be outlawed from April 1 to
save money!
We are greatsoftware.com
Our goal:
Create bookmeeting.com an online resource booking service targeted

primarily towards those that use Outlook for booking meeting rooms.
March 1: Pilot customer will start using it.
April 1: Commercial rollout.

Our context:
We have built similar services before, so we have a functioning team,

development environment, and operational environment.


This project is top priority, we have a 5-person Scrum team ready to start

Source: Henrik Kniberg

147
1993-2014 Jeff Sutherland

2014 Scrum Inc.

today.

Product Vision
Welcome to
bookmeeting.com! It doesnt
get any simpler than this.
Getting started guide:
Create an account at
bookmeeting.com
Set up rooms
Your company can now surf

to bookmeeting.com and
book meetings!
Payment
Pay per month (rate may
vary depending on number
of rooms)

Roles
Booker
Creates and administrates the
meeting booking, invites
participants
Participant
Attends meetings. Receives
invitations & updates.
Admin
Sets up rooms and users.
Buyer
Buys the service and pays for its
use.
Seller
Hosts the service and charges
for it use. Initially
greatsoftware.com.

Source: Henrik Kniberg

148
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Bookmeeting.com

Exercise
Goal: Pile of users stories
Acceptance criteria for one story
!

Time: 10 minutes

Write on sticky notes.


Use a thick pen.
Use the story template.
As a X
I want Y
so that Z As a X
I want Y
As a X so that Z
I want Y
so that Z
As a X
I want Y
As a Xso that Z
I want Y
As a X so that Z
I want Y
As a X
so that Z
I want Y
so that Z

As a X
I want Y
so that Z

149
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Create product backlog

As a Scrum Master I need to know how to go from

150
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Waterfall to Scrum
in order to do my job

Case Study
Stopping a Death March

151
1993-2014 Jeff Sutherland

2014 Scrum Inc.

This is the real story and not for public consumption!


It demonstrates:
1. How to fail with Scrum
2. How to rescue a failed Scrum
3. How to convert a waterfall team into a Scrum team

Symptom: Waterfall process (under Scrum banner)

2006

2007

Requirements
Coding

Release
Testing?

Q2

Q3

Q4

Q1

Q2

We are here

152
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Q1

153
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Symptom: Long, detailed requirements


specifications

154
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Symptom: Lack of trust & commitment

Strategy: Implement Scrum


Create product backlog
Estimate product backlog
Execute 2 sprints, measure velocity

Show us where we stand


Help us move faster

2007

Feb

We are here
155
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Jan

Step 1: Change Definition of Done


Old definition of done:

New definition of done:

Releasable

Tester added to team

156
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Code checked in

Step 2: Create a product backlog


feature X

feature X

feature X

feature X

feature X

feature X

feature X

feature X

Features implemented but not tested & integrated

feature X

feature X

feature X

Test/integr
feature Y

feature X

Test/integr
feature Y

feature X

Test/integr
feature Y

feature X

Test/integr
feature Y
Test/integr
feature Y
Test/integr
feature Y

Test/integr
feature Y

feature X

Test/integr
feature Y

feature X
feature X

feature X

Test/integr
feature Y

Test/integr
feature Y
Test/integr
feature Y
Test/integr
feature Y

Test/integr
feature Y

feature X
feature X

feature X

Test/integr
feature Y

feature X

Test/integr
feature Y

Test/integr
feature Y

Test/integr
feature Y

Test/integr
feature Y

Test/integr
feature Y

PO

157
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Features left to implement

Barry Boehm. Cost Estimation with COCOMO II. CS 577a, University of Southern California, Center for Software Engineering. Fall 2006!

158
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Software Estimation Error

Points vs. Hours


Rand Corporation received a grant from U.S.
DOD in the 1940s 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
Experts need to estimate independently - avoid anchoring

Fibonacci growth pattern easiest for humans


Seen everywhere in nature

159
1993-2014 Jeff Sutherland

2014 Scrum Inc.

RAND called it the Delphi technique

Why Points are Better Than Hours


Cone of Uncertainty

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.
160
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Gray Line - Hours


Red Line - Points

Anchoring

456 hrs

Same spec

Same spec

500 hrs
Never mind me

PO

50 hrs
Never mind me

PO

555 hrs

99 hrs

SM

SM

SM

Source: How to avoid impact from irrelevant and misleading


info on your cost estimates, Simula research labs estimation
seminar, Oslo, Norway, 2006

161
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Spec

The Fibonacci Sequence


Barry Boehme called it the Wideband Delphi Technique for software
http://www.youtube.com/watch?v=ahXIMUkSXX0

162
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master I need to know how to

Estimate Stories

163
1993-2014 Jeff Sutherland

2014 Scrum Inc.

in order to know velocity and pull the right !


amount of work into a sprint

Agile Estimating Strategy


Dont estimate time
Estimate relative size of stories
Measure velocity per sprint

Estimates are done by the people who are going


to do the work
Not by the people who want the work done
Team allocate 10% of sprint time to Product Owner

164
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Estimate continuously during the project, not all


up front
Prefer verbal communication over detailed,
written specifications

Estimate stories
Pick smallest story and give it 3 story

points
Estimate relative size of other stories
Discuss outliers and vote again until
all numbers are within 3 cards, then
average.
!

TIME: 10 minutes

As a X
I want Y 2
so that Z
As a X
I want Y 3
so that Z
As a X
I want Y 5
so that Z
As a X
I want Y 1
so that Z
As a X
I want Y 2
so that Z
As a X
I want Y 5
so that Z
As a X
I want Y 13
so that Z
165
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Exercise

As a X
I want Y 8
so that Z

166
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Case Study Continued

Step 3: Estimate product backlog


Features left to implement

Features implemented but not tested & integrated

Total:
180 points

Total:
70 points

2
5

2
3

167
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Step 4: Execute 2 sprints


Actual
Velocity

Sprint 1

30

Sprint 2

25

10

168
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Estimated
Velocity

Step 5: Face reality & Revise the


plan

Backlog = 250 points

Velocity = 10 points/sprint
2007

Q1

25 sprints

2008 Earliest

Promised
release

Q2

> 1 year until release!

likely
release

Q3

Q4

Q1

Q2

169
1993-2014 Jeff Sutherland

2014 Scrum Inc.

We are here

Step 6: Act
Reduce

Reduce total scope


Incremental releases

Overall priorities
1. Operations
2. Project X
3. Anything else

Backlog = 250 points


Velocity = 10 points/sprint

170
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Increase

Fix impediments
Pressure on team
Ineffective build & test environment
Lack of teamwork, discipline & motivation
Disruptions & context switching
Unrealistic expectations
ROOT CAUSE: Company not focused

Result

Originally promised
release
(big-bang)

2007

Q1

Q2

Velocity
30

2008

estimated

Earliest likely release if


process hadnt
changed
(big-bang)
Q3

Q4

Actual release
(incremental)

Actual release
(incremental)

Q1

Q2

25-30

20
actual
9-10
Q1

Q2

Q3

2007

171
1993-2014 Jeff Sutherland

2014 Scrum Inc.

10

Case 3: Take-away points

Waterfall is still waterfall even if you call it Scrum

Know your tools, get training & coaching early.


Dont believe your plan

There is no the plan must be right because we promised.

Make sure you have reliable feedback loops & a changeable


plan.
There is no too low velocity

Just actual velocity, and a realistic or unrealistic plan.


Build quality in

Dont postpone test & integration, that gives a false velocity.


Having good people isnt enough

An inappropriate process can cause even a great team to fail.


Dramatic improvements can be made quickly

With a strong management team that has access to empirical


data and is willing to focus.

172
1993-2014 Jeff Sutherland

2014 Scrum Inc.

173
1993-2014 Jeff Sutherland

2014 Scrum Inc.

As a Scrum Master I Need My Team to


Work with the Product Owner to
Refine the Product Backlog

Register new
user

Register new
user

Edit existing
user

Edit existing
user

Find user

View Invoice in
HTML, PDF, or
Excel format

View Invoice in
HTML, PDF, or
Excel format

Delete user

As a helpdesk
operator I want
to see who is
logged in

As a helpdesk
operator I want
to see who is
logged in

View Invoice in
HTML, PDF, or
Excel format

Find user

Administrate
users

Operations
manual
100
simultaneous
users

As a helpdesk
operator I want
to see who is
logged in

Operations
manual
100
simultaneous
users
Source: Henrik Kniberg

Operations
manual
100
simultaneous
users
Delete user

174
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Product Backlog

Splitting Stories and Breaking


Out Tasks
Break into tasks
(normally during sprint planning meeting)
Split stories

User admin

REgister new
user

User admin

Administrate
users

Create DB
schema

Write form
validation

Do GUI design

Write serverside logic

Do integration
test

User admin

User admin

Edit existing
user

Delete user

Source: Henrik Kniberg

175
1993-2014 Jeff Sutherland

2014 Scrum Inc.

13

Find user

Write failing
test

Definition of Done

Default Definition of Done



Unit/Integration tested

Ready for acceptance test

Deployed on demo server

= I havent messed up
the codebase

Whats else must be done before shipping the code?


- For example customer acceptance test + user documentation
Why not? Who does it? When? What happens if a problem turns up?
Burn up this work in release burndown!
Source: Henrik Kniberg

176
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Default Definition of Done



Releasable

Default Definition of Done



Acceptance tested

Release notes written

Releasable

No increased technical debt

Burndown Strategies
Burndown number of stories completed
stories must be small and of similar size
not recommended for new teams

Burndown stories only in points


stories must be small

Burndown tasks in points


spread points from stories across tasks - keep it simple

Burndown tasks in hours


Scrum Foundation and ScrumInc. no longer view this as best

177
1993-2014 Jeff Sutherland

2014 Scrum Inc.

practice

As a Scrum Master I Need to Know How to Do

Release Planning

178
1993-2014 Jeff Sutherland

2014 Scrum Inc.

to Deliver Working Product to End Users

Product Owner Responsibility


Get one sprint READY backlog
Team can get started

Get two sprints READY backlog


Team can accelerate sprint to sprint

Build out Release Plan


Company can predict revenue

Build one year roadmap

179
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Customers can be briefed on company strategy

Release Cycles
Goal: every sprint results in potentially releasable product increment.
Product owner decides when to release.

Sprint #

Release 2
(Beta)

10

Release 3
(Live)

11

12

Source: Henrik Kniberg

13

Release 5
Release 4
(maintenance)(maintenance)

14

15

16

17

18

19

Release 6
(maintenance)

20

180
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Release 1
(Alpha)

Backlog Maintenance

2009

Apr
2008
May
2008

June
2008

2010

Q3
2008

Q4
2008

2011

2009

2012
181
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Release Planning Prerequisites


Vision for release
Product backlog prioritized and estimated
Historical data

Velocity of teams
Emerging requirements
Undone work
Customer feedback that must be dealt with immediately
after release

182
1993-2014 Jeff Sutherland

2014 Scrum Inc.

If historical data is not available, velocity,


emerging requirements, and undone work must
be estimated after the first few sprints

Release Planning Meeting Participants


Includes stakeholders, Product Owner team, and
all parties that execute the release
Scrum Masters and cross functional teams
Third party team teams (waterfall teams or external

vendors)
Sales, marketing, and operations

183
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Could be half a day for small release with Ready


backlog
Could be multiple days for large release or
backlog that needs refinement

Release Planning Agenda


Background, business and competitive climate (PO)
Release goals (PO)
Current product and development state (PO)

Product Backlog refinement for release (All)


Capture and discussion of issues (All)
Technical Issues (Dev teams)
Technology
Testing Challenges and Strategies
Dependencies
Engineering Standards and Practices
Hardening and Hackathon
Development regimen
Build
Test
Continuous integration
Scrum of Scrums
Special handling of multi-team Sprint Planning, Sprint Reviews
Multi-team retrospectives

Tentative schedule (PO)


184
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Team interactions (Dev teams)

Measuring Velocity
Beginning of sprint

Product
Backlog

End of sprint

Sprint
Backlog

Sprint
Backlog

8
5
5
3
5
5

Done!

8
5
5
3
5

Estimated
velocity =
26

Done!
Done!
Almost done
Not started

Actual
velocity =
18

5
5
3
5

185
1993-2014 Jeff Sutherland

2014 Scrum Inc.

5
3
5

Release Burndown Chart Key to


On Time Project Delivery
Answers the key
question Will we be
done on time?

Work
remaining
(story points)

Useful for what if?


analysis and
managing tradeoffs
of Scope, Velocity
and Time

400

300

200

Vital for identifying


and addressing
unreasonable
expectations

100

9 10 11 12 13 14 15 16

Sprint
Source: Henrik Kniberg

186
1993-2014 Jeff Sutherland

Critical Estimates for Release Date

Product Backlog Estimates (based on Definition of Done)


Undone Work (anything beyond DoD needed to deploy)
Emerging Requirements (historical data)
Customer Issues post release (historical data)
Example:
For a healthcare company in Houston, for every 100 points

estimated there are 20 points of undone work (User Acceptance


Testing) plus 40 points of emerging requirements plus 60 points
of customer feedback when new features go live for the first time.
Plan must include 100+20+40+60 = 220 points for every 100
points of initial estimate

187
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Release plan must be updated based on real data


after every sprint

188
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Acceptance Tests

Modern Agile Acceptance Model


The move toward Acceptance Test Driven
Development requires a more complete model of
progressing requirements acceptance
Example model (sharper definition of done)
Conditions of Satisfaction - broad terms

189
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Acceptance Criteria - further refined


Examples - actual scenarios or data
Executable Examples - Executable Spec

Simple Scenarios
Suppose we are creating a registration function
It consists of specifying email (as User ID) and
Password

Enter your Email and Password to Register


Email Address:
Password:

190
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Register

Acceptance

Condition of Satisfaction
Conditions of Satisfaction are high level criteria
established with an initial Epic/Feature/User
Story
In our previous example, the conditions of acceptance for

the password would be:

Ensure the password is not easy to crack.

The PO would define the conditions of acceptance


in concert with business stakeholders

Email Address:
Password:
Register

191
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Enter your Email and Password to Register

Acceptance

Examples Make It Real


Actual examples are the ultimate way to
communicate requirements:
Password

Expected

Expected Message

abc123

Invalid

abcdefghi
!

Invalid

Your password must be at least 8 characters


and no more than 12 charcters long
Your password must contain at least one
character and one number

!
!

1aaaaaaaa
Valid
!
!
ajx972dab

Comment

Why valid?

Valid

The PO works closely with a tester, developer,


and business stakeholder to define these
criteria
192
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Acceptance

Acceptance Criteria
Acceptance Criteria specifies the details
that the team can then build against:
Following the example for Password:
Must be at least 8 characters and no more than 12
Must contain only alpha-numberics and the period
Must contain at least one digit
Must contain at least one character
Etc. (there may be more criteria)

Enter your Email and Password to Register


Email Address:
Password:
Register

193
1993-2014 Jeff Sutherland

2014 Scrum Inc.

The PO works closely with a tester,


developer, and business stakeholder to
define these criteria

Acceptance Test Driven Development (ATDD)


Tools: Fit and Cucumber

Cucumber
New tool for natural language scenarios

numerator

denominator

quotient

10

12.6

4.2

100

25 expected
24 returned

In order to ensure my account is correct


As a Registered User
I want to check my recent activity
!
Scenario: Recent Account Activity
Given I am a registered user Jsmith
And I am logged in with password xyx123
And I have had account activity in the last 45 days
And I am on the home page
When I click the Recent Activity button
Then I should see the Account Activity Page
And I should see a list of my activity over the last 45 days
!
Scenario: No Recent Account Activity
Given I am a registered user Jsmith
And I am logged in with password xyx123
And I have had account activity in the last 45 days
And I am on the home page
When I click the Recent Activity button
Then I should see the Select Account Activity Period Page
And I should get a message: You had no activity in the last
45 days, please select a time frame to review
194
1993-2014 Jeff Sutherland

2014 Scrum Inc.

FIT (Framework for Integrated Test) and Fitnesse (Wiki front end)
Test specified in table format
Developers generates classes (fixtures) to hook into application
Users/testers use Wiki or Excel to specify inputs and outputs

195
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Prince 2

What Is PRINCE2?
Process driven Project Management method
Describes procedures to coordinate people and activities in

a project

A project has a clear start and end


Goal: deliver product according to business case

Projects are split in stages

Source: Marco Mulder

196
1993-2014 Jeff Sutherland

2014 Scrum Inc.

At the end of each stage, verify if business case is still valid


If not: terminate

197
Rev. 2013 - 01

Rev. 2013 08

10 September 2013

198
Rev. 2013 - 01

Rev. 2013 08

10 September 2013

199
Rev. 2013 - 01

Rev. 2013 08

10 September 2013

SCRUM FLOW AND PRINCE2

Stage
Plan
PID

Project
Brief

Project
Mandate

Notification Highlight
Next Stage Report
200

Rev. 2013 - 01

Rev. 2013 08

10 September 2013

12

201
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Velocity and Technical Debt

Clean & Simple Code

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 class Dog {


public static void main(String[] args) {
System.out.println("WOOF 1!");
System.out.println("WOOF 2!");
}
}

public void woof(Person woofCaller) {


Connection connection = null;
PreparedStatement statement = null;
try {
connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");
statement = connection.prepareStatement("insert into Dog values (?, ?, ?)");
statement.setLong(1, System.currentTimeMillis());
statement.setString(2, person.getName());
statement.setString(3, person.getPhoneNumber().getNumber());
statement.executeUpdate();
}
}
}
} Connection a = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");
b =
a.prepareStatement("select * from Dog where name = '" + name + "'");
c = b.executeQuery();
if (c.next()) {
String foundName = c.getString("name");
PhoneNumber phoneNumber = new PhoneNumber(c.getString(woofCount"));
Person person = new Person(foundName, phoneNumber);
return person;
} else {
return new Person("", null);
}

} catch (SQLException e) {
return null;
} catch (IllegalArgumentException x) {
throw x;
}
}

public List<Person> getAll() {


connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead");
statement = connection.prepareStatement("insert into Dog values (?, ?, ?)");
statement.setLong(1, System.currentTimeMillis());
}
if (statement != null) {
if (c.next()) {
String foundName = c.getString("name");
PhoneNumber phoneNumber = new PhoneNumber(c.getString(woofCount"));
Person person = new Person(foundName, phoneNumber);
return person;
} else {

Simple code:
1.Passes all tests
2.No duplication
3.Readable
4.Minimal
!

Source: Henrik Kniberg

202
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Simple is hard!

Velocity Calibration
Actual
Velocity

40

30

40

30

28

40

30

31

40

30

30

Estimated
40
50
60

Actual
30
30
30

Estimated

Estimated

Actual
30
30
30

Actual

30 40

35

25 35

30

20 30

25

Source: Henrik Kniberg

203
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Estimated
Velocity

Technical Debt & Release


Planning
Remaining
story points
400

Well be
done by
sprint 10!

300

Sorry, were late!


We should definitely by
done by sprint 12!

200

Um... were done


when were done!

100

10

11

12

13 14

15

Sprint

Source: Henrik Kniberg

204
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Technical Debt

Vmax
Vactual

Sustainable pace!

time

time
Source: Henrik Kniberg

205
1993-2014 Jeff Sutherland

2014 Scrum Inc.

velocity

velocity

Vmax
Vactual

Code duplication
Test coverage
Code readability

Definition of Done!
.... bla bla ....!
No increased technical debt

Dealing with Technical Debt

Ro
a

to

Definition of Done
.... bla bla ....
Technical debt decreased

he

ll
!
e
c
a
p
g
in
s
a
e
Incr

Sustainable pace

First step
Slow down
Stop accumulating debt

Second step
(optional)

Slow down even more


Start repaying debt

time
Source: Henrik Kniberg

206
1993-2014 Jeff Sutherland

2014 Scrum Inc.

velocity

Vmax
Vactual

Definition of Done
.... bla bla ....
No increased technical debt

Gartner - Technical Professional Advice


2012 Planning Guide: Application Delivery Strategies

207
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Business users are losing patience with oldschool IT culture. Relationships are tense and
resentful. Legacy systems and practices impede
agility. Bottom line - GET AGILE
Adopt a product perspective.
Say goodbye to waterfall.
Improve cross-competency collaboration.
Launch a deep usability discipline.
Start a technical debt management program.

1993-2014 Jeff Sutherland

2014 Scrum Inc.

208

1993-2014 Jeff Sutherland

2014 Scrum Inc.

209

210
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint Planning

Sprint Planning Meeting


Goal: xyz
Sprint 1
Backlog

Jackass team, sprint 15


!

Sprint goal
- Beta-ready release!
!

Sprint backlog
- Deposit (5)
- Migration tool (13)
- Backoffice login (3)
- Backoffice user admin (5)
(Estimated velocity = 26)
!

Schedule
- Sprint period: 2006-11-06 to 2006-11-24
- Sprint demo: 2006-11-24, 13:00, in the cafeteria
- Daily scrum: 9:30 9:45, in conference room Jimbo
!

Team
- Jim
- Erica (scrum master)
- Tom (75%)
- Niklas
- Eva
- John

211
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Product
Backlog

Why is it important that the team AND product


owner attend the sprint planning meeting?

Scope

PO

As a helpdesk
operator I want
to see who is
logged in

Priority

PO

212
1993-2014 Jeff Sutherland

2014 Scrum Inc.

SM

Cost

Sprint Planning Meeting Example


Goal
Less important
More important
Present product backlog
e
c
i
B
f
a
c
f
k
o
o
f
k
f
c
i
c
a
e Withdraw
Migration
B

Reprioritize,
re-estimate,
split/combine
stories
t
i
s
Encrypted
o
Dep
P
e
r
f
T
T
e
s
t
T
logTin User aTdmin
tool
Password
T
20
8 Break out
13 tasks 3
13
8
Write failing
testEstimate
draw the line
User velocity,
Transaction

T
T
8h
T
4h

Integr
Test

DB
design

2h

Refact.

T
Migration
5 tool

T
Migration
5 tool

GOAL: Beta-ready release!

213
1993-2014 Jeff Sutherland

2014 Scrum Inc.

T
12h
Impl.
DAO

8h

The Sprint Commitment


Teams commitment to the Product Owner:
We promise that ...
We believe we can reach the sprint goal.
We will do everything in our power to reach the goal and will inform
you immediately if we have problems.
Code will be potentially shippable at the end of the sprint.
If we fall behind schedule we will remove the lowest priority stories
first.
If we get ahead of schedule we will add stories from the product
backlog in priority order.
We will display our progress and status on a daily basis.
Every story we do is complete.
Caveat
Estimates are estimates. We will be early some times and late other
times. We will document this normal variation with our sprint
velocity.

214
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Sprint Demo
What have we accomplished?

Team demonstrates working code to stakeholders


Only 100% completed stories are demonstrated
Partially complete stories are ignored

215
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Direct feedback from stakeholders


Feedback incorporated into the product backlog

Can We Talk About Other


Things?
Yes.
But talk is cheap (and easy to misunderstand)

Yes.
Velocity and its meaning
Meaning of progress to date
New Release plan
Etc, etc, etc

216
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Testing Ideal Case

End users

v1.0.0

Sprint 1

Sprint 2
Timeline

Source: Henrik Kniberg

217
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scrum team

v1.1.0

Testing Common Alternative


End users

v1.0.1

Acceptance test team

1.0 acceptance test

Bug!
v1.0.0

Scrum team Sprint 1

v1.0.1

v1.1.0

Sprint 2

218
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Timeline

219
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scaling

Microsoft Scrum - 3000 people!


Deploys live at end of every sprint
Product Owner

220
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Engineering
Practices

221
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Linear Scalability

222
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Engineering Practices and Scrum

Scrum

Scrum & XP
Team

Daily Scrum
XP

Sprint
backlog

Whole
team
Collective
ownership

Product
backlog

Product
owner

Customer
tests

TDD

Pair
programming

Continuous
Integration

Simple
design

Coding
standard

Refactoring

Burndown
chart

Planning Sprint
game Planning
meeting

Sustainable
Pace

Metaphor

Sprint
Review
Source: Henrik Kniberg

223
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Scrum Master

Small
releases

Feedback Cycles

Sprint demo
Daily Scrum
Continuous
integration

Unit test

Source: Henrik Kniberg

224
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Pair
programming

1993-2014 Jeff Sutherland

2014 Scrum Inc.

225

Scrum Team Exercise

As a class group we need a

Course Review

226
1993-2014 Jeff Sutherland

2014 Scrum Inc.

in order to retain knowledge

1993-2014 Jeff Sutherland

2014 Scrum Inc.

227

XP Game - Preplanning
Elect a Product Owner (PO) and Scrum Master (SM) in
each team
PO fetch product backlog
SM fetch props
For each story in backlog:
Team estimates relative complexity

(story points)
PO prioritize stories

228
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Teams estimates how many cards can get done in


sprint

229
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Agile DC ScrumInc Build Party 2013

Next Steps

As a class group we need a

Course Retrospective

230
1993-2014 Jeff Sutherland

2014 Scrum Inc.

in order to wrap up effectively

For those who want certification ...


!

231
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Read agileatlas.org on Core Scrum and the Scrum Guide


at scrumguides.org before taking the test.
You will receive email from the Scrum Alliance with login
instructions to take the test.
Students who pass the test will receive a list of missed
questions with correct answers highlighted.
Students who fail will receive a list of missed questions
without answers.
The test can be taken one additional time at no charge.
After that a fee of $25 per additional attempt will be
charged.
A passing score is a least 24 out of 35 questions correct.

http://www.youtube.com/watch?v=u6XAPnuFjJc
232
1993-2014 Jeff Sutherland

2014 Scrum Inc.

Motivate your teams

Stay Connected
Our Website

check in for announcements, new content and services, book


releases, and more!
for step by step implementation of Scrum use the Scrum Handbook
www.scruminc.com/scrumhandbook.pdf
www.scruminc.com/csmjsv18.pdf for this deck

ScrumLab

articles, videos, papers on all things scrum


scrumlab.scruminc.com

Blog

scrum.jeffsutherland.com

Online Courses

advance your learning with our interactive online courses. visit the
scrumlab store to view upcoming topics.

Twitter, Facebook, and G+

@jeffsutherland, scrum and scrum inc.


233
1993-2014 Jeff Sutherland

2014 Scrum Inc.