The Art of Doing Twice The Work in Half The Time (PDFDrive)

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 today’s 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 she’s 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
• Who’s 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 Ray’s 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 Snowden’s 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 people’s 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 aren’t 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
It’s 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
• Yesterday’s 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 aren’t 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 Ohno’s 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 Master’s 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 shouldn’t 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 it’s 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
I’m 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
1993-2014 Jeff Sutherland
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, let’s 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 why’s,
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
1993-2014 Jeff Sutherland
© 2014 Scrum Inc.

SCRUM: WAY TEAMS WORK
© 2014 Scrum Inc.

THE
Sébastien 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 they’re leading troops on the battlefield or in the marketplace.
The challenges of today’s world don’t 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 who’ll 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
!
“Engaging…Sutherland tackles the problem of the perennially late, over-budget project—and 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 Scrum’s
© 2014 Scrum Inc.

impact. If you don’t get three times the results in one-third the time, you aren’t 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
What’s 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 Company’s 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 doesn’t 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 1940’s to determine best way to
estimate tough projects
• Discovered estimation in hours has high error rate and wide variance
• Found people could put things in relative size piles best
• 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
• Don’t 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 hadn’t
(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.
• Don’t 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
• Don’t postpone test & integration, that gives a false velocity.
• Having good people isn’t 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 haven’t messed up
• Ready for acceptance test
the codebase
• Deployed on demo server
What’s 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
We’ll be
done by
300 sprint 10!
Sorry, we’re late! 

We should definitely by
200 done by sprint 12! Um... we’re done
when we’re 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
• Team’s 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

The Art of Doing Twice The Work in Half The Time (PDFDrive)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Art of Doing Twice The Work in Half The Time (PDFDrive)

Uploaded by

Copyright:

Available Formats

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.

• Who’s 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 Snowden’s 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.

That is, while there is value in the items on  