Scrum PDF

SCRUM
THE ART OF DOING TWICE THE WORK IN HALF THE TIME

!
!
!
!
!
!
!
482,430 (6.7%) open Scrum jobs in the United
! States - 2812 (0.8%) in 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,
2014 Scrum Inc.

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
2
1993-2014 Jeff Sutherland
Your Trainers
Dr. Jeff Sutherland CEO, Scrum Inc.!
Jeff is the co-creator of Scrum and a leading expert on how the framework has evolved to meet
the needs of todays business. The methodology he developed in 1993 and formalized in 1995
with Ken Schwaber has since been adopted by the vast majority of software development
companies around the world. But Jeff realized that the benefits of Scrum are not limited to
software and product development. He has adapted this successful strategy for several other
industries including: Finance, healthcare, higher education and telecom.!
As the CEO of Scrum Inc. and the Senior Advisor and Agile Coach to OpenView Venture Partners,
Jeff sets the vision for success with Scrum. He continues to share best practices with
organizations around the globe and has written extensively on Scrum rules and methods. With a
deep understanding of business process gleaned from years as CTO/CEO of eleven different
software companies Jeff is able to describe the high level organizational benefits of Scrum and
what it takes to create hyper-productive teams.
Christine Hegarty Product Owner, Scrum Inc.!

!
After working in several organizations that practiced traditional management methods, Christine
knew there had to be a better way. She looked for companies that cared about efficiency, process
improvement, eliminating waste and treating people right. That search led her to Scrum. Christine
believes so strongly in the power of the Scrum principles that shes dedicated her career to
helping organizations apply them and gain tremendous benefits. Her role includes client outreach,
development and marketing.!
2014 Scrum Inc.

3
As a class group we need
Introductions
in order to work together effectively
2014 Scrum Inc.

4
Group Introductions
Whos in your group?

Pair introductions
Talk to each other and line up across
the room by level of Scrum
experience
Line up in a second dimension by job
function
What companies, industries, non-
software application are represented?
2014 Scrum Inc.

5
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
2014 Scrum Inc.

6
Scrum OpenView
Do Doing Done
2014 Scrum Inc.

7
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
Team Backlogs
Advanced topics and closeout
2014 Scrum Inc.

8
Agenda - Sprint 1
Sprint 1 - Scrum Origins and Practice
Intro (2)
Team Learning Backlog (8)
Scrum Origins (9)
Agile Manifesto (4)
Airplane Game (9)
Getting Started (6)
Scrum Framework (8)
Sprint 2 - Starter Kit for a Scrum Master
Sprint 3 - Planning & Estimation
Sprint 4 - Team Backlogs & Review
2014 Scrum Inc.

9
Agenda - Sprint 2
Roles - Project Manager Exercise (8)
Patterns (4)
Daily Clean Code (5)
Nice to have:
Avoid Multitasking: Swarming (9) Emergency Procedure
Handle Interrupts (3)
Improve Flow - Constraint theory (2)
Identify Bottlenecks - Value Stream Mapping (3)
Remove Major Impediments - A3 exercise (7)
Scrum the Scrum (6)
Sprint 4 - Team Backlogs & Review
2014 Scrum Inc.

10
Agenda - Sprint 3
A3 Review (2)
Exercise: Daily Meeting (7) Nice to have
Exercise: Scrum of Scrums (3) * Money for nothing
* Velocity
Scrum Board (5) * Technical Debt
User Stories (12) * Acceptance tests
Exercise: Create User Stories (4)
Failed Scrum (9)
Exercise: Estimate Stories (7)
Sprint 4 - Team Backlogs and Review
2014 Scrum Inc.

11
Agenda - Sprint 4
Sprint 2 - Identify and Remove Impediments
Sprint 4 - 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)
2014 Scrum Inc.

12
As a Scrum Master understanding the
Agile Manifesto
will help implement Scrum
2014 Scrum Inc.

13
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.
2014 Scrum Inc.

14
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)
2014 Scrum Inc.

Defined plan with one input and one output and (hopefully) no deviations
15
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.
2014 Scrum Inc.

Empirical plan with a new input after each cycle 16
Applicability of Scrum!
Ogunnaike and Rays Process Control Requirements!
Far from Agreement
Chaos
Requirements
Complex Empirical Process (Scrum)
Complicated Lean
Simple Defined Process

Close to Agreement
Close to Certainty Far from Certainty
2014 Scrum Inc.

Technology
Adapted from Snowdens Cynefin Framework - see Wikipedia

17
Lean Enterprise Institute
Production
Techniques
Scrum Lean
2014 Scrum Inc.

Product
Creation 18
Agile Manufacturing - Beyond Lean
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.
2014 Scrum Inc.

19
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
That is, while there is value in the items on

the right, we value the items on the left more.
2014 Scrum Inc.

20
Agile Manifesto Principles
1. Our highest priority is to satisfy the customer through early 7. Customer Visible Value is the primary measure of progress.
and continuous delivery of Customer visible value.
8. Agile processes promote sustainable development. The
2. Welcome changing requirements, even late in sponsors, developers, and users should be able to maintain a
development. Agile processes harness change for the constant pace indefinitely.
customer's competitive advantage.
9. Continuous attention to technical excellence
3. Deliver Value frequently, from a couple of weeks to a couple and good design enhances agility.
of months, with a preference to the shorter timescale.
10. Simplicity--the art of maximizing the amount
4. Business people and the Delivery team must work together of work not done--is essential.
daily throughout the project.
11. The best architectures, requirements, and designs emerge
5. Build projects around motivated individuals. from self-organizing teams.
Give them the environment and support they need, and trust
them to get the job done. 12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
6. The most efficient and effective method of
accordingly.
conveying information to and within a delivery team is face-to-
face conversation.
2014 Scrum Inc.

Survey: Mario Moreira
21
State of Agile
Chaos Manifesto 2011, Standish Group International, 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.
2014 Scrum Inc.

Source:
22
2014 Scrum Inc.
Source: Version One
23
Top 12 Failure Modes for Scrum
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 replanting and removing impediments
Not fixing bugs found inside a sprint, particular 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
Overburdening team (bad management, no happiness metric)
2014 Scrum Inc.

24
!
Scrum Production
!
2014 Scrum Inc.

25
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.
2014 Scrum Inc.

26
One Person, One Fold
2014 Scrum Inc.

27
Product Owner Tests
2014 Scrum Inc.

28
Agile DC ScrumInc Build Party 2013
2014 Scrum Inc.

29
Munich
32/32
World Record
Amsterdam
32/33
2014 Scrum Inc.

30
As a Scrum Master I need to understand
How to Get Started
in order to begin a Scrum
2014 Scrum Inc.

31
Scrum is easy to understand but hard
to implement
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.
2014 Scrum Inc.

32
Aikido
The Way in Harmony with the Spirit
2014 Scrum Inc.

33
Making the Most of your Scrum
Shu state
Scrum Master sets up process as in the Scrum Guide. See
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.
2014 Scrum Inc.

34
Ha State
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
2014 Scrum Inc.

35
Ri State
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
2014 Scrum Inc.

36
Team of One in Ri State
Team needs to be hyperproductive.
But what does a great Scrum Master do?
2014 Scrum Inc.

http://www.youtube.com/watch?v=Hzgzim5m7oU 37
the Scrum Framework
in order to implement Scrum
2014 Scrum Inc.

38
Scrum Framework
Product
Scrum
Backlog
Product Owner
Sprint Backlog
Social Objects Roles Scrum Master
Scrum Board
Make Work Burndown Chart
Visible Points Team
Velocity
Ceremonies
Product
Backlog Sprint Planning Daily Scrum Sprint Review Retrospect-ive
Refinement
Ready Done Kaizen
2014 Scrum Inc.

39
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
cross-functional (incl. testing)
self-organizing/-managing group of individuals, has
autonomy regarding how to achieve its commitments
typically 3-9 people
2014 Scrum Inc.

40
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
Scrum Master and team identify the top process improvement
Deliverable is the KAIZEN to put at top of Sprint Backlog for next Sprint.
2014 Scrum Inc.

41
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
Helps calibrate velocity
2014 Scrum Inc.

42
Sprint - Iterative and Incremental
2014 Scrum Inc.

43
2014 Scrum Inc.
44
Roles & Responsibilities
in order to implement Scrum
2014 Scrum Inc.

45
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
2014 Scrum Inc.

46
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
2014 Scrum Inc.

47
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.
!
Spend the other half working closely with the team
clarifying specifications.
2014 Scrum Inc.

48
A Successful Product Owner
Delivers:
Value
The right product set to excite customers
At the right time Time
In the order that maximizes business value
!
Responds dynamically to change faster than competitors

Clarifies customer need to development teams so that
uncertainty is removed and developer velocity is
maximized
!
The Product Owner is ultimately accountable for

winning in the market!
2014 Scrum Inc.

49
Scrum Master
Works with the Product Owner to:
Find techniques for effective Product Backlog
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
2014 Scrum Inc.

50
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
Collaborative - they work together to achieve the
Sprint goal
Usually 3 - 9 people
2014 Scrum Inc.

51
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.
Products are more robust when a team has all of the cross-functional skills
focused on the work
Changes in team composition reduce productivity.
2014 Scrum Inc.

Source: Ken Schwaber 52
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
Hold Product Owners accountable for value
delivered per point
Hold Scrum Masters accountable for process
improvement and team happiness
2014 Scrum Inc.

53
Exercise: Project Manager/Leader
As a team, write down all responsibilities of a
traditional project manager/leader
Put one responsibility on each sticky note
Time: 4 minutes
2014 Scrum Inc.

54
Exercise: Project Leader
Sort Project Leader responsibilities on sticky
notes into these five categories
Product Owner
Scrum Master
Team
Waste
Other
!
Time: 5 minutes
2014 Scrum Inc.

55
Problems with Traditional Project Model
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
2014 Scrum Inc.

56
Scrum Patterns

Common Pitfalls and Solutions
to enable a high performing team
2014 Scrum Inc.

57
Scrum Master Startup Strategy !
Fast, Easy, and Fun vs. Slow, Hard, and Painful
Train everyone on how you do Scrum at your company
Get team focused by making backlog visible
Build agreement on a definition of READY with the
Product Owner and Team
Build agreement on a definition of DONE
Make sure only READY backlog goes into Sprint Planning.
Remove the biggest impediment the team has in the first
Sprint
Make sure only DONE backlog is shown at the Sprint
Review
Execute best patterns during the Sprint
2014 Scrum Inc.

58
Patterns
2014 Scrum Inc.

59
Its all about technique ...
2014 Scrum Inc.

60
Scrum Patterns - scrumplop.org
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.
2014 Scrum Inc.

61
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
Happiness metric - How to ensure teams arent overburdened
Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams!
47th Hawaii International Conference on System Sciences (HICSS) !
2014 Scrum Inc.

By Jeff Sutherland, Neil Harrison, Joel Riddle !
January 2014
62
Run a Lean Scrum
As a Scrum Master my Team

needs to have Daily Clean Code
to double production and quality
2014 Scrum Inc.

63
Taiichi Ohnos Taxonomy of Waste
2014 Scrum Inc.

64
The 7 Wastes of Software
Development Features and functions used in a typical system:
Partially done work Only 1/5 of the
stuff we build is used
Always often or always!
Extra features 7%
Lost knowledge Often
13%
Handoffs
Never
Task switching 45%
Delays Sometimes
16%
Defects
Rarely
19%
2/3 of the stuff we

build is rarely or Source: Standish Group Study Reported at XP2002
by Jim Johnson, Chairman
never used!
2014 Scrum Inc.

There is surely nothing quite so useless as doing with
great efficiency what should not be done at all.
Peter Drucker 65
Systematic Strategy for Lean
Level\Dimension
Value Flow Pull Perfection
P6 Build Integrity in P2 Amplify Learning P2 Amplify Learning P6 Build Integrity In
Production T19 Refactoring T5 Synchronization T3 Feedback T18 Conceptual
T20 Test T4 Iterations T6 Setbased integrity
development T17 Perceived
integrity!
Tools divided P1 Create Value P4 Deliver Fast P7 See the Whole P3 Defer Commitment
into three Management T1 Eliminate Waste T11 Queue theory T22 Contracts T7 Options thinking
dimensions T2 Value streams T12 Cost of delay T21 Measurement T8 Defer commitment
T10 Pull T9 Decisionmaking
P5 Empower team P5 Empower team P5 Empower team P5 Empower team

People T16 Expertise T14 Motivation T15 Leadership T13 Self determination
2014 Scrum Inc.

Thinking tools are best transformed by people and projects
66
Systematic Pilot Results
Project effort
100 % Rework
100%
Work
90%
CMMI Process focus
80%
50 % 69 %
70%
9% SCRUM
60%
50%
40% 50 % 35 %
4%
30%
50 %
20% 25 %
10%
10 % 6%
CMMI 1 CMMI 5 CMMI 5
SCRUM
Source: Systematic Software engineering 2006
2014 Scrum Inc.

67
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.
2014 Scrum Inc.

68
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.
Velocity is limited because a team spends time dealing with too many bugs.
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.
2014 Scrum Inc.

Therefore: Fix all bugs in less than a day.
69
Good Agile: Use Definition of Done to
Drive Performance
Daily
Meeting
Sprint R
E
T
R D R
E O O
S
A Remove N P
E
D Impediments
E C
T
Y I
Value V
E
Velocity
2014 Scrum Inc.

70
Scrum Patterns
As a Scrum Master I need to encourage

Swarming
to enable a high performing team
2014 Scrum Inc.

71
Exercise: Never Keep Customers Waiting
D AV E Dave
LIS Lisa
Never keep a
customer waiting
!
BOB Bob
Start early
= Finish early ERI Eric
M AR Maria
2014 Scrum Inc.

72
Round 2 Swarming
Policy D AV E Dave
Limit WIP
L I SA Lisa
(work in process)
!
Current limit = Bob
1 customer
at a time
Eric
Maria
2014 Scrum Inc.

73
Discussion what was the
difference? Why?
2014 Scrum Inc.

74
Weinberg Table of Project Switching Waste
2014 Scrum Inc.

Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284.
75
Prioritizing Between Projects
Product A A1 A2 A3 = A
Product B B1 B2 B3 = B
Product C C1 C2 C3 = C
Traditional strategy: Everything is important! Do it all at once!

A B C
A1 B1 C1 A2 B2 C2 A3 B3 C3
January February March April May June July
Agile strategy: Prioritize & focus!
A B C
A A A B B B C C C
January February March April May June July
2014 Scrum Inc.

Adapted from Henrik Kniberg
76
This product rocks!
Swarming
Care about the whole product
Boy are we effective
as a team!
Not just your little task T
Im more efficient if I just do my

tasks
2014 Scrum Inc.

Source: Revised after Henrik Kniberg 77
Enterprise Level Swarming
2014 Scrum Inc.

78
As a Scrum Master I need to manage
Interruptions
in order for the team to be successful
2014 Scrum Inc.

79
Illigitimus Non Interruptus
Beginning of sprint
Product
Sprint
Backlog
Backlog
Kaizen Support
8
8
5 5 Management
5 5
3 PO Sales
5
3 Now
5
5
10
8
Later
5
3
5
Low Priority
2014 Scrum Inc.

On Buffer Overflow ABORT, Replan, Dates Slip
80
2011-2014
As a Scrum Master I need to optimize
Flow
in order for the team to be successful
2014 Scrum Inc.

81
Theory of Constraints Smooth Flow
Goal
PO
SM T
Problem
Strategy
3.
Inc
rea Typ Typ
4.
1. se
Fi
Re int
2014 Scrum Inc.

x
du ak 2.
ne
ce e Fix
xt
int
ak
e
82
Case Study:
Developing Products >5x Faster
A real-life example of applying Value

Stream Mapping and Scrum to
dramatically speed up product
development.
2014 Scrum Inc.

83
Game backlog Design-ready games Production-ready games
15 12
8
Lisa
Concept Graphics Sound Integr. &
Sam assigns Dev
2d 1m
pres.
6m resources 1w
design design
6m 6m
deploy T
2h 4h 1d 1m 3w 3m 3w
(1m+2m)
Games out of date
Missed market windows Process
Demotivated teams 3.5 m value added
time = 14% cycle
Overhead costs 25 m cycle time efficiency
Estimate
2 m cycle time = 12x faster

w1 w2 w3 w4 w5 w6 w7 w8
Preliminary result
3-4 m cycle time = 6-8x faster
w1 w2 w3 w4 w5 w6 w7 w8
2014 Scrum Inc.

Source: Henrik Kniberg
84
Case Study
w1 w2 w3 w4 w5 w6 w7 w8
Take-away Points
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
Concept Lisa assigns Graphics Sound Integr. &

Sam Dev
pres. resources design design deploy
2d 1m 6m 1w 6m 6m
2h 4h 1d 1m 3w 3m 3w
(1m+2m)
2014 Scrum Inc.

85
!
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
By Durward K. Sobek II., Art Smalley
2014 Scrum Inc.

86
Root Cause Analysis
2014 Scrum Inc.

http://www.youtube.com/watch?v=IETtnK7gzlE
87
2014 Scrum Inc.
88
Exercise
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.
2014 Scrum Inc.

89
Venture Company Example
A3 Process Creates Pull-Based Authority
Title: Seven teams failing too many sprints Owner:
Mentor:
Background Date:
Teams not getting software done and tested
Critical components failing every other sprint Countermeasures (Experiments)
Meet with board member
Conference call with CEO
P Commitment to implement continuous
integration
Current Condition Site visit to demonstrate working processes
Engineers not working together?
Inability to test causing failure L Do
Waste estimated at 2.1M Euro/year
Confirmation (Results )
Goal / Target Condition Clean implementation in one month
Clean tested code worked at end of sprint A Velocity of seven teams average increase of 20%
Cut waste by 90% Immediately savings of 1.7M Euro/year
Save 1.8M Euro/year while improving quality Cost of implementation 3000 Euro for expert
consultant
Check
Root Cause Analysis
Why- engineers had different design concepts Follow-up (Actions)
Why- Team members not communicating Introduced prioritized automated testing
Why- Scrum Master not doing good job Introduced code reviews
Why- No continuous integration N Cut deployment time in half
2014 Scrum Inc.

Why- Product Owner focused on new features Cut support calls in half
Why- Product Owner is CEO Increased sales Act
A3 Thinking Durward Sobek 90
A3 Template
Title: Concise, self-explanatory Owner:
Mentor:
Background
Date:
Why is this important?
Why should the reader care about this situation
P
and be motivated to participate in improving? Countermeasures (Experiments)
Proposed countermeasure(s) to address each
candidate root cause.
[This should be a series of quick experiments to
Current Condition
validate causal model analysis.]
How do things work today?
What is the problem? L Identify where in the cause/effect model
changes are possible and likely to significantly
Baseline Metrics?
improve the overall situation.
Predict results for each countermeasure.
Goal / Target Condition Do

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 whys,
fishbone diagram, cause/effect network) to show
cause-and-effect relationships.
2014 Scrum Inc.

N
91
As a Scrum Master I need to
Scrum the Scrum
to get an effective Retrospective
2014 Scrum Inc.

92
Sprint Retrospective
What happened?
Sprint
Half-day
planning nce
First story confere
ready for
Sam sick
test
Story #25
removed
from sprint
New desks Server New build Sprint
installed Big crashed LAN server
Team flow! demo
argument shootout
Week 1 Week 2 Week 3
2014 Scrum Inc.

93
2014 Scrum Inc.

94
Long term effect
Velocity
1 2 3 4 5 6 7 8 9 10 11 12 13
Sprint
Effective velocity over time Effective velocity over time

(with retrospectives) (without retrospectives)
2014 Scrum Inc.

95
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

!
An easy way to identify top process improvement

is the Happiness Metric
2014 Scrum Inc.

96
Happier People Function Better
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
2014 Scrum Inc.

97
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
2014 Scrum Inc.

Estimate value
Vote for highest value
98
Rules
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.
2014 Scrum Inc.

99
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"
4x FTEs = 4x
6/27/10"
16x output with
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"
Raw Scrum Inc. Velocity History
8/27/12"
10/27/12"
12/27/12"
2/27/13"
(not adjusted for fluctuation in team capacity by sprint)
4/27/13"
6/27/13"
8/27/13"
10/27/13"
Results: Scrumming the Scrum Using Happiness Metric
2011-2014
2014 Scrum Inc.

SCRUM: WAY TEAMS WORK
2014 Scrum Inc.

THE
Sbastien Chabal 101
Preorder discounted new Scrum book on
Amazon or Barnes and Noble! Get free signed
Software in 30 Days or Power of Scrum!
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
2014 Scrum Inc.

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
102
As a Scrum Master I need to
Run a Good Daily Meeting
to help the Team improve performance
2014 Scrum Inc.

103
Motivation for Daily Scrum
120
100
% Saturation Bell Labs Pasteur Project!
80
82 Companies
60
40
20
0
0 20 40 60 80
Number of Roles
Communication Saturation and Roles. Organizational Patterns of Agile Software Development by
2014 Scrum Inc.

Coplien and Harrison (2004)
104
2014 Scrum Inc.
All Blacks, New Zealand http://www.youtube.com/watch?v=0C434QFTjok 105
Purpose of Daily Scrum
Build team focus
All arms linked - intense collaboration
Mental attitude - we will crush impediments
Create team spirit
2014 Scrum Inc.

106
Daily Scrum Meeting
15 minutes

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?
2014 Scrum Inc.

107
Brooks Law:
Adding People to a Late Project Makes It Later
1.5-3
3-5 5-7
9-11 15-20
2014 Scrum Inc.

Optimal team size is 4.6 people according to Harvard research.
108
Source: http://www.qsm.com/process_01.html (491 projects) 1993-2014 Jeff Sutherland
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!
Waterfall Comm Paths! n(n-1)/2 per team!
n(n-1)/2 for 120 people! 5(4)/2 = 10!
120(119)/2 = 7140! 24 teams(10) = 240!
+ a few cross team!
2014 Scrum Inc.

!
80% less comm
109
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...
!
Manufacturing Manager
2014 Scrum Inc.

Adapted from Slides By Chris Sullivan
110
1993-2013
1993-2012Jeff
JeffSutherland 1993-2014 Jeff Sutherland
Sutherland
As a Scrum Master I need to act on
Scrum Board Warning Signs
in order to improve team performance
2014 Scrum Inc.

111
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.
Yet it is an extremely useful tool used by almost all Scrum
teams.
2014 Scrum Inc.

112
2014 Scrum Inc.
113
Sprint: Day 0
Sprint Goal:
To Do: Doing: Done! Get a ready release!
Kaizen
Daily Clean
Code
Burndown
3pts
100
Buffer
90
80
33 70
60
Points
code 50
write a failing
cleanup. 2
test.. 2 pts.pts

40
Deposit Integration
test

DAO
30
3pts

2 pts
20
10
Tapestry ry
Migration code spike

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

Tool 2 pts pts Miigration 8
pts Days
Backend write a failing

Miigration 8 pts
Implement
Integrate w//
GUI

test.. 2
pts.

Login 5 pts
boss

8 pts
Backend GUI design

Clarify Req

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

Admin 5 pts
2014 Scrum Inc.

114
Sprint Backlog: After First Meeting
Sprint Goal:
Kaizen
Daily Clean
Code
Burndown
3pts
100
90
Buffer 80
33 70
60
Points
code 50
cleanup. 2
pts write a failing DB Design

Deposit
40
test.. 2 pts.
3pts

Integration
DAO
30
test

3pts

2 pts
20
10
GUI spec
Migration 2 pts code write a failing
test.. 2 pts.

0
cleanup. 2
Tool Tapestry ry
spike

pts Miigration 8
8 pts
pts Days
Backend write a failing

Integrate w//
boss
Implement
test.. 2 pts.

Login 8 pts GUI

5 pts
Backend GUI design

Clarify Req

5 ptsImplement 3 pts
User write a failing
GUI

test.. 2 pts.

Admin 5 pts
2014 Scrum Inc.

115
Sprint Backlog: Day X
Sprint Goal:
Kaizen
Daily Clean
Code
Burndown
3pts
100
Buffer Sales Support

Fix Bug
White Paper

90
80
23 3pts 2 pts 5 pts

70
60
Points
code
write a failing cleanup. 2 50
test.. 2 pts.
pts
DB Design
40
Deposit 3pts
Integration
test

DAO
30
3pts

2 pts
20
10
Migration code write a failing Tapestry ry

GUI spec
0
cleanup. 2 test.. 2 pts.

spike

Tool pts Miigration 8 8 pts
2 pts
pts Days
Integrate w//
Backend boss
Implement
Miigration 8 pts GUI

write a failing
test.. 2 pts.

8 pts
Login 5 pts
GUI design
Clarify Req

Backend 5 ptsImplement 3 pts
write a failing
User test.. 2 pts.
GUI

Admin 5 pts
2014 Scrum Inc.

116
Scrum Board Warning Signs
2014 Scrum Inc.

117
Warning Sign #1
Sprint Goal:
Kaizen
Daily Clean
Code
Burndown
100
90
Buffer 80
33 70
60
Points
code 50
cleanup. 2
write a failing
pts 40
Deposit Integration
DB Design
test.. 2 pts.

3pts
DAO
30
test

3pts

2 pts
20
10
Migration GUI spec

2 pts
write a failing
test.. 2 pts.

0
Tapestry ry code
Tool spike
cleanup. 2
Miigration 8
pts
8 pts pts Days
Backend Implement
GUI

Integrate w//
boss

write a failing
test.. 2 pts.

Login 5 ots 8 pts
GUI design
Clarify Req

Backend write a failing 5 ptsImplement 3 pts
User test.. 2 pts.
GUI

5 ots
Admin
2014 Scrum Inc.

Warning Sign #2
Sprint Goal:
Kaizen Daily Clean

Code
Burndown
100
90
Buffer Sales Support

Marketing
Demo

Fix Bug
Fix Bug
White Paper
Customer 80
Down!

3
3pts 2 pts 2 pts 5 pts
5 pts 13 pts 70
60
Points
code 50
cleanup. 2
write a failing
pts 40
Deposit Integration
DB Design
test.. 2 pts.

3pts
DAO
30
test

3pts

2 pts
20
10
GUI spec
Migration 2 pts
code
write a failing
test.. 2 pts.

0
Tool Tapestry ry
spike

cleanup. 2 Miigration 8
8 pts
pts pts Days
Backend Integrate w//

boss
8 pts
Miigration
write a failing
Implement
GUI
test.. 2 pts.

Login 8 pts 5 ots
Backend GUI design

Clarify Req

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

Admin 5 ots
2014 Scrum Inc.

119
Warning Sign #3
Sprint Goal:
Kaizen
Daily Clean
Code Burndown
100
90
Buffer Buffer Fix Bug
White Paper

Customer
Down!
80
2 pts 5 pts
12 33 Points
13 pts
70
60
Points
50
write a
DB Design

failing test.. 2 code 40
Deposit Integration
test

3pts

DAO
pts.

3pts

cleanup. 2
pts 30
2 pts
20
GUI spec 10
write a 2 pts
Migration code failing test.. 2
Miigration 8 pts.
Tapestry ry
0
cleanup. 2
Tool pts
pts spike

8 pts
Days
Backend Miigration 8 pts

Implement
GUI

write a
failing test.. 2
Integrate
Login 5 ots pts.

w//boss

8 pts
Backend GUI design

5 ptsImplement Clarify write
Req
a failing
User GUI
3 pts test.. 2 pts.

Admin 5 ots
2014 Scrum Inc.

120
Swimlane Scrum
2014 Scrum Inc.

Source: Jim Coplien 121
Build Party Video- 3 Minutes
Scrum Board on Steroids
2014 Scrum Inc.

122
Teams That Finish Early Accelerate Faster
scrumplop.org
Daily
Meeting
Sprint R
E
T
R D R
E O O
S
A Remove N P
E
D Impediments
E C
T
Y I
Value V
E
Velocity
2014 Scrum Inc.

123
Product Backlog and User Stories
2014 Scrum Inc.

124
Product Backlog
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.
2014 Scrum Inc.

125
User Story
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
2014 Scrum Inc.

126
User Story Templates
As a <role> I would like to be able to <action> to
achieve <business value>
2014 Scrum Inc.

127
Whats Wrong with This Story?
2014 Scrum Inc.

128
Break Epics into Stories
As a frequent flyer I want

to book a trip using
As a frequent miles so that I can save
flyer I want to money
book flights As a frequent flyer I want

customized to to easily book a trip I
take often So that I can
my save time
preferences,
As a premium frequent
so I save time flyer I want to request an
upgrade So I can be more
comfortable
2014 Scrum Inc.

129
User Story - Guidelines
Product vision
Immediately actionable
Product
Backlog
Negotiable
A Valuable
B
Estimable
Sized to fit
C Testable
Modified from Bill Wake www.xp123.com
A B C
User Stories slice through all GUI
layers
!
Client
Customer facing value
delivered every sprint Server Stuff not
2014 Scrum Inc.

!
Slices accumulate in value needed
DB schema
130
One Companys Definition of Ready!
User Story, Acceptance Tests, Examples, Wire frame
2014 Scrum Inc.

131
Communication Effectiveness
2 people at
Effective whiteboard
2 people on
phone er)
sw
n
Communication d -a
Video an
effectiveness n-
recording t i o
es
( Qu
2 people
on email
er)
w
ans
Audio n-
tio
recording ues
o q
( N
Document
Ineffective
Cold Richness (temperature) of Hot

communication channel
2014 Scrum Inc.

Source: research from McCarthy and Monk (1994)
132
Irrelevant Information
Spec 1 Same spec
A
+ irrelevant details
B
A
C
B
C
20 hrs
39 hrs
SM
SM
Source: How to avoid impact from irrelevant and misleading
2014 Scrum Inc.

info on your cost estimates, Simula research labs estimation
seminar, Oslo, Norway, 2006
133
Enabling Specification
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
2014 Scrum Inc.

134
Use the Definition of Ready to Improve
Team Performance
Daily
Meeting
Sprint R
E
T
R D R
E O O
S
A Remove N P
E
D Impediments
E C
T
Y I
Value V
E
Velocity
2014 Scrum Inc.

135
Create User Stories Exercise
2014 Scrum Inc.

136
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 access to a pilot customer a conference center!
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 today.
2014 Scrum Inc.

Source: Henrik Kniberg 137
Bookmeeting.com
Product Vision Roles
Welcome to Booker
bookmeeting.com! It doesnt Creates and administrates the
get any simpler than this. meeting booking, invites
Getting started guide: participants
Create an account at Participant
bookmeeting.com Attends meetings. Receives
Set up rooms invitations & updates.
Your company can now surf Admin
to bookmeeting.com and Sets up rooms and users.
book meetings! Buyer
Payment Buys the service and pays for its
Pay per month (rate may use.
vary depending on number Seller
of rooms) Hosts the service and charges
for it use. Initially
greatsoftware.com.
2014 Scrum Inc.

Exercise
Create product backlog Write on sticky notes.
Use a thick pen.
Goal: Pile of users stories Use the story template.
Acceptance criteria for one story
As a X
! I want Y
so that Z As a X
Time: 10 minutes 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
As a X so that Z I want Y
I want Y so that Z
so that Z As a X
I want Y
so that Z
2014 Scrum Inc.

139
As a Scrum Master I need to know how to
Rescue a Failed Scrum
in order to do my job
2014 Scrum Inc.

140
Case Study
Stopping a Death March
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
2014 Scrum Inc.

141
Symptom: Waterfall process (under Scrum banner)
2006 2007
Requirements
Coding
Release
Testing?
Q1 Q2 Q3 Q4 Q1 Q2
We are here
2014 Scrum Inc.

142
Symptom: Long, detailed requirements
specifications
2014 Scrum Inc.

143
Symptom: Lack of trust & commitment
2014 Scrum Inc.

144
Strategy: Implement Scrum
Create product backlog
Estimate product backlog

Execute 2 sprints, measure velocity
Show us where we stand

Help us move faster
2007
Jan Feb
We are here
2014 Scrum Inc.

145
Step 1: Change Definition of Done
Old definition of done:
Code checked in
New definition of done:
Releasable
Tester added to team
2014 Scrum Inc.

146
Step 2: Create a product backlog
Features left to implement Features implemented but not tested & integrated
Test/integr
feature X feature X feature Y Test/integr
feature X feature X feature Y
Test/integr
feature Y
Test/integr Test/integr
feature X feature Y feature Y Test/integr
feature X feature X feature Y
feature X Test/integr
feature Y
feature X feature X Test/integr feature Y Test/integr
feature X feature Y feature Y
Test/integr
feature Y
feature X Test/integr Test/integr Test/integr
feature X feature X Test/integr
feature Y feature Y feature Y
feature X feature Y
feature X feature Y
feature X Test/integr Test/integr
feature X feature Y feature Y
feature X feature Y
PO
2014 Scrum Inc.

147
Software Estimation Error
2014 Scrum Inc.

Barry Boehm. Cost Estimation with COCOMO II. CS 577a, University of Southern California, Center for Software Engineering. Fall 2006!
148
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
RAND called it the Delphi technique
2014 Scrum Inc.

149
Why Points are Better Than Hours
Cone of Uncertainty
Gray Line - Hours

Red Line - Points
2014 Scrum Inc.

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.
150
Anchoring
Spec Same spec Same spec
500 hrs 50 hrs

456 hrs Never mind me Never mind me
PO PO
555 hrs 99 hrs

SM
SM
SM
2014 Scrum Inc.

Source: How to avoid impact from irrelevant and misleading
info on your cost estimates, Simula research labs estimation
seminar, Oslo, Norway, 2006
151
The Fibonacci Sequence
Barry Boehme called it the Wideband Delphi Technique for software
http://www.youtube.com/watch?v=ahXIMUkSXX0
2014 Scrum Inc.

152
As a Scrum Master I need to know how to
Estimate Stories
in order to know velocity and pull the right !
amount of work into a sprint
2014 Scrum Inc.

153
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
Estimate continuously during the project, not all

up front
Prefer verbal communication over detailed,
written specifications
2014 Scrum Inc.

154
As a X
I want Y 8
Exercise so that Z
As a X
I want Y 2
so that Z
Estimate stories
As a X
Pick smallest story and give it 3 story I want Y 3
points so that Z
Estimate relative size of other stories As a X

I want Y 5
Discuss outliers and vote again until so that Z
all numbers are within 3 cards, then
As a X
average. 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
2014 Scrum Inc.

so that Z
155
Case Study Continued
2014 Scrum Inc.

156
Step 3: Estimate product backlog
Features left to implement Features implemented but not tested & integrated
Total: Total:
180 points 70 points
2 2
2 5
? 3
2014 Scrum Inc.

157
Step 4: Execute 2 sprints
Estimated Actual
Velocity Velocity
Sprint 1 30 9
Sprint 2 25 10
2014 Scrum Inc.

158
Step 5: Face reality & Revise the
plan
Backlog = 250 points
25 sprints > 1 year until release!
Velocity = 10 points/sprint
2007 2008 Earliest

Promised likely
release release
Q1 Q2 Q3 Q4 Q1 Q2
We are here
2014 Scrum Inc.

159
Step 6: Act
Overall priorities !
1. Operations !
Reduce total scope 2. Project X !
Reduce 3. Anything else
Incremental releases
Backlog = 250 points
Velocity = 10 points/sprint
Fix impediments
Increase Pressure on team
Ineffective build & test environment
Lack of teamwork, discipline & motivation
Disruptions & context switching
Unrealistic expectations
ROOT CAUSE: Company not focused
2014 Scrum Inc.

160
Result Originally promised
2008
Earliest likely release if
2007 release process hadnt
(big-bang) changed
(big-bang)
Q1 Q2 Q3 Q4 Q1 Q2
Actual release Actual release

(incremental) (incremental)
Velocity
30
estimated 25-30
20
actual
10
9-10
Q1 Q2 Q3
2007
2014 Scrum Inc.

161
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.
2014 Scrum Inc.

162
As a Scrum Master I Need My Team to
Work with the Product Owner to
Refine the Product Baclog
2014 Scrum Inc.

163
Register new Register new
Product Backlog user user
Edit existing Edit existing

user user
Administrate
users View Invoice in
Find user HTML, PDF, or
Excel format
View Invoice in As a helpdesk
HTML, PDF, or Delete user operator I want
Excel format to see who is
logged in
As a helpdesk View Invoice in
operator I want HTML, PDF, or
to see who is Excel format Find user
logged in
As a helpdesk Operations
operator I want
Operations to see who is manual
manual logged in
100
Operations simultaneous
100 manual users
simultaneous
users 100
simultaneous Delete user
2014 Scrum Inc.

users

Splitting Stories and Breaking
Out Tasks Break into tasks
(normally during sprint planning meeting)
Split stories
Write failing Create DB Write form
test schema validation
User admin 5
REgister new
user Write server- Do integration
Do GUI design
side logic test
User admin 3
Find user
13
Administrate
users User admin 2
Edit existing
user
User admin 8
Delete user
2014 Scrum Inc.

Definition of Done
Default Definition of Done

Acceptance tested

Release notes written

Releasable Releasable

No increased technical debt

Unit/Integration tested
= I havent messed up
Ready for acceptance test
the codebase
Deployed on demo server
Whats else must be done before shipping the code?

- For example customer acceptance test + user documentation
2014 Scrum Inc.

Why not? Who does it? When? What happens if a problem turns up?
Burn up this work in release burndown!
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
practice
2014 Scrum Inc.

167
As a Scrum Master I Need to Know How to Do
Release Planning
to Deliver Working Product to End Users
2014 Scrum Inc.

168
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
Customers can be briefed on company strategy
2014 Scrum Inc.

169
Release Cycles
Goal: every sprint results in potentially releasable product increment.
Product owner decides when to release.
Release 1 Release 2 Release 3 Release 4 Release 5 Release 6

(Alpha) (Beta) (Live) (maintenance)(maintenance) (maintenance)
Sprint # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
2014 Scrum Inc.

Backlog Maintenance V
V V
V
2009
Apr
2008
May
2008
June
2008
2010
Q3
2008
Q4
2008 2011
2009
2012
2014 Scrum Inc.

T
171
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
If historical data is not available, velocity,
emerging requirements, and undone work must
be estimated after the first few sprints
2014 Scrum Inc.

172
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
Could be half a day for small release with Ready
backlog
Could be multiple days for large release or
backlog that needs refinement
2014 Scrum Inc.

173
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
Team interactions (Dev teams)
Scrum of Scrums
Special handling of multi-team Sprint Planning, Sprint Reviews
Multi-team retrospectives
2014 Scrum Inc.

Tentative schedule (PO)
174
Measuring Velocity
Beginning of sprint End of sprint
Product
Backlog Sprint
Sprint
Backlog
Backlog
8 Done! Actual
8 velocity =
8 Estimated 18
5 velocity = Done!
26 5
5 5 Done!
3 5
5 Almost done
5 3
3 Not started
5
5 5
5
3
5
2014 Scrum Inc.

175
Release Burndown Chart Key to
On Time Project Delivery
Answers the key
question Will we be Work
remaining
done on time? (story points)
!
400
Useful for what if?
analysis and
managing tradeoffs 300
of Scope, Velocity
and Time 200
!
Vital for identifying 100
and addressing
unreasonable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
expectations Sprint
176

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
Release plan must be updated based on real data
after every sprint
2014 Scrum Inc.

177
Acceptance Tests
2014 Scrum Inc.

178
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
Acceptance Criteria - further refined
Examples - actual scenarios or data
Executable Examples - Executable Spec
2014 Scrum Inc.

179
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:
Register
2014 Scrum Inc.

180
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:
2014 Scrum Inc.

Password:
Register
181
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)
The PO works closely with a tester,

developer, and business stakeholder to
define these criteria
2014 Scrum Inc.

Email Address:
Password:
Register
182
Acceptance
Examples Make It Real
Actual examples are the ultimate way to
communicate requirements:
Password Expected Expected Message Comment
!
abc123 Invalid Your password must be at least 8 characters
!
and no more than 12 charcters long
abcdefghi
! Invalid Your password must contain at least one
character and one number
1aaaaaaaa
! Valid Why valid?
ajx972dab
! Valid
The PO works closely with a tester, developer,

and business stakeholder to define these
criteria
2014 Scrum Inc.

183
Acceptance Test Driven Development (ATDD)
Tools: Fit and Cucumber
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
In order to ensure my account is correct

Cucumber As a Registered User
New tool for natural language scenarios 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
numerator denominator quotient 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
10 2 5
!
Scenario: No Recent Account Activity
Given I am a registered user Jsmith
12.6 3 4.2 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
100 4 25 expected When I click the Recent Activity button
2014 Scrum Inc.

Then I should see the Select Account Activity Period Page
24 returned And I should get a message: You had no activity in the last
45 days, please select a time frame to review
184
Prince 2
2014 Scrum Inc.

185
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
At the end of each stage, verify if business case is still valid
If not: terminate
2014 Scrum Inc.

Source: Marco Mulder
186
187
Rev. 2013 - 01 Rev. 2013 08 10 September 2013
188
9
189
SCRUM FLOW AND PRINCE2
Stage
Plan
PID
Project
Brief
Project
Mandate
Notification Highlight
Next Stage Report
190
12
Velocity and Technical Debt
2014 Scrum Inc.

191
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 void woof(Person woofCaller) {

Connection connection = null;
PreparedStatement statement = null;
try {
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");
public class Dog { b = a.prepareStatement("select * from Dog where name = '" + name + "'");
c = b.executeQuery();
public static void main(String[] args) { if (c.next()) {
String foundName = c.getString("name");
System.out.println("WOOF 1!"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(woofCount"));
Person person = new Person(foundName, phoneNumber);
System.out.println("WOOF 2!"); return person;
} else {
}
} !
}
return new Person("", null);
} catch (SQLException e) {
return null;
} catch (IllegalArgumentException x) {
throw x;
!
}
}
public List<Person> getAll() {

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
!
Simple is hard!
2014 Scrum Inc.

Velocity Calibration
Estimated Actual
Velocity Velocity Estimated Actual
40 30 40 30
30 28 40 30
30 31 40 30
30 30
Estimated Actual Estimated Actual

40 30 30 40 35
50 30 25 35 30
60 30 20 30 25
2014 Scrum Inc.

Technical Debt & Release
Planning
Remaining
story points
400
Well be
done by
300 sprint 10!
Sorry, were late!

We should definitely by
200 done by sprint 12! Um... were done
when were done!
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Sprint
2014 Scrum Inc.

Technical Debt
Definition of Done!
.... bla bla ....!
No increased technical debt
Code duplication
Test coverage
Code readability
Vmax Vmax
Vactual
Vactual
Sustainable pace!
velocity
velocity
time time
2014 Scrum Inc.

Dealing with Technical Debt
Definition of Done Definition of Done

.... bla bla .... .... bla bla ....
No increased technical debt Technical debt decreased
Vmax
Vactual
Ro
ad
to
velocity
he
ll
ac e!
g p
eas in
Sustainable pace Incr
Second step
First step (optional)
Slow down Slow down even more
Stop accumulating debt Start repaying debt
2014 Scrum Inc.

time
Gartner - Technical Professional Advice
2012 Planning Guide: Application Delivery Strategies
Business users are losing patience with old-

school 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.
2014 Scrum Inc.

197
2014 Scrum Inc.
198
2014 Scrum Inc.
199
Sprint Planning
2014 Scrum Inc.

200
Sprint Planning Meeting
Goal: xyz
Product Sprint 1
Jackass team, sprint 15
Backlog Backlog !
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%)
2014 Scrum Inc.

- Niklas
- Eva
- John 201
Why is it important that the team AND product
owner attend the sprint planning meeting?
PO
Scope
As a helpdesk
operator I want
to see who is
logged in
Cost Priority PO
SM
2014 Scrum Inc.

202
Sprint Planning Meeting -
Example
Goal
More important Less important
Present product backlog
Migration
Reprioritize,
i t B a ck o f
re-estimate,f i ceB a c k o f fi ce Withdraw
split/combine stories
Dep o s T P e r f T e st Encrypted
T
tool logTin User aTdmin T Password
8 Break out 13 tasks 3 13 8 20
testEstimate
Write failing
User velocity, draw the line
T
8h T
Transaction
Migration T
Migration
T 5 tool 5 tool
Impl.
T
DB
DAO
12h design
2h
Integr
T
Test
8h T
4h
Refact. GOAL: Beta-ready release!
2014 Scrum Inc.

203
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.
2014 Scrum Inc.

204
Sprint Demo
What have we accomplished?
Team demonstrates working code to stakeholders
Only 100% completed stories are demonstrated
Partially complete stories are ignored
Direct feedback from stakeholders
Feedback incorporated into the product backlog
2014 Scrum Inc.

205
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
2014 Scrum Inc.

206
Testing Ideal Case
End users
v1.0.0 v1.1.0
Scrum team Sprint 1 Sprint 2
Timeline
2014 Scrum Inc.

Testing Common Alternative
End users
v1.0.1
Acceptance test team 1.0 acceptance test
Bug!
v1.0.0 v1.0.1 v1.1.0
Scrum team Sprint 1 Sprint 2
Timeline
2014 Scrum Inc.

208
Scaling
2014 Scrum Inc.

209
Microsoft Scrum - 3000 people!
Deploys live at end of every sprint
Product Owner
Engineering
Practices
2014 Scrum Inc.

210
Linear Scalability
2014 Scrum Inc.

211
Engineering Practices and Scrum
2014 Scrum Inc.

212
Scrum
Scrum & XP
Team
Daily Scrum
XP
Sprint
backlog
Whole
team
Coding Burndown
Collective chart
ownership TDD standard
Product
backlog
Customer
tests Pair Refactoring Planning Sprint
Product programming game Planning
owner meeting
Continuous Simple Sustainable

Integration design Pace
Metaphor
Small
Scrum Master releases
Sprint
2014 Scrum Inc.

Review
213
Feedback Cycles
Sprint demo
Daily Scrum
Continuous
integration
Unit test
Pair
programming
2014 Scrum Inc.

214
2014 Scrum Inc.
215
Scrum Team Exercise
As a class group we need a

Course Review
in order to retain knowledge
2014 Scrum Inc.

216
2014 Scrum Inc.
217
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
Teams estimates how many cards can get done in
sprint
2014 Scrum Inc.

218
Agile DC ScrumInc Build Party 2013
2014 Scrum Inc.

219
Next Steps
As a class group we need a

Course Retrospective
in order to wrap up effectively
2014 Scrum Inc.

220
For those who want certification ...
!
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.
2014 Scrum Inc.

221
Motivate your teams
2014 Scrum Inc.

http://www.youtube.com/watch?v=u6XAPnuFjJc
222
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+
2014 Scrum Inc.

@jeffsutherland, scrum and scrum inc.
223

Scrum PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Scrum PDF

Încărcat de

Drepturi de autor:

Formate disponibile

SCRUM

THE ART OF DOING TWICE THE WORK IN HALF THE TIME

2014 Scrum Inc.

Christine Hegarty Product Owner, Scrum Inc.!

2014 Scrum Inc.

2014 Scrum Inc.

Whos in your group?

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

Far from Agreement

Simple Defined Process

Close to Certainty Far from Certainty

2014 Scrum Inc.

Adapted from Snowdens Cynefin Framework - see Wikipedia

2014 Scrum Inc.

2014 Scrum Inc.

Individuals and interactions over processes and tools!

That is, while there is value in the items on

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

Ready Done Kaizen

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

Scrum Master owns the process

2014 Scrum Inc.

2014 Scrum Inc.

Responds dynamically to change faster than competitors

The Product Owner is ultimately accountable for

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.

2014 Scrum Inc.