Scrum: Its All About

Common Sense
Jim Coplien & Jens stergaard
Scrum Training Institute
cope@gertrudandcope.com
jeos12@gmail.com
G&C
About this Course
This course is:
Much the same as most ScrumMaster
certication courses
The start of your journey, or a good
waypoint on a journey that has already
begun
This seminar materials are Copyright 2008, 2009 by James O. Coplien. All
rights reserved. Permission granted to reproduce these materials for non-
instructional use, provided the source is cited and that this Copyright notice
appears.
Many thanks to Jens stergaard, whose original SCM deck inspired much of the
content here. Jens! deck in turn gives homage to Ken Schwaber, whose contribution
is also gratefully acknowledged. Likewise, some of Jeff Sutherland!s own materials
have made it into this deck.
Certied Scrum Trainer is a certication mark, and Scrum AllianceSM is a service
mark, of
Scrum Alliance, Inc. Any unauthorized use is strictly prohibited.
Welcome to Scrum! This course is a two-day Scrum immersion. It is patterned after
many other ScrumMaster Certication (CSM) courses and covers the topics
necessary for ScrumMaster certication. Though this is a certication course, a
course alone cannot make you an effective ScrumMaster: it requires the right
personal touch and experience. Certication should be a gate that qualies one to
practice or to excellence; no such gate exists for the core notions of
ScrumMastering.
However, well-controlled studies at Systematic in Denmark show that there is value
in exactly the kind of training that you will receive in this course. Today starts a
journey for you. Let!s go!
G&C
A quick lexicon
English Danish Hebrew
impediment forhindring !"#$%&
agile
adrt eller
smidig
'()*'
G&C
Course Outline
0. What is Scrum?
1. Scrum History
2. Scrum Theory, Concepts, Practices
3. Release Planning
4. Production and Sprints
5. Velocity Game
6. Overcoming Impediments
7. Management, Distribution and Scaling
8. Engineering Tools and Practices
I spend quite a bit of time on history in this course, because understanding the
foundations makes it easier to understand some of the techniques. But most of the
course will focus on two areas: Scrum Theory, Concepts and Practices, and
Production and Sprints. The theory is important for you to understand why you do
what you do: Scrum is rst and foremost about thinking: inspecting and adapting.
The Production and Sprints are important because the Agile Manifesto values
working software.
We also talk about Release Planning and the Product Owner, but this is not a
product owner course.
The Velocity Game is graduation: an intense learning exercise where you will use
many of the tools you learn over the next two days. At the end we cover
miscellaneous but important topics: process improvement, and management issues
including distribution and scaling. Finally, we!ll look at the engineering practices,
and warn about some that recent research calls into doubt.
G&C
0. What is Scrum?
It is not a method
It does not tell you what to do, nor how
It is not about software it works for any
endeavor concerned about building a product
It is a product management framework that
you ll in, that allows you to inspect and adapt
It promises only that the team will work on
the most important things rst
It tends to be fun
G&C
1. Scrum History
In fact, Agile is old 1950s, 1960s in
software
We focus on recent history since about 1990
The Pattern / OO / Agile community
Agile Manifesto
Manufacturing Inuences
Lean
Scrum is not a method. It promises only that the team is always working on the
most important thing.
Scrum is only a framework. In most cases it doesn!t tell you what to do, nor how to
do things. It is a project management framework that you ll in, within which you
inspect and adapt to optimize ROI.
Scrum principles apply to companies ranging from automobile manufacturing to
churches. Here we will focus on the software perspective on Scrum.
Much software practice was Agile before Agile was cool. The Hacker culture at MIT
in the 1960s was practicing much of what we would call Agile today. Agile isn!t so
much something new as it is a stripping off of bad management practices that have
strangled software over the years.
Here, we focus on the past decade or two of software development history and
sprinkle in insights that came from manufacturing and Lean. The Agile Manifesto is
a key landmark in this progression.
G&C
A Bit of History
SCRUM
Easel, 1993
Pasteur Project
(1990-3)
Hillside: Org
Patterns
(aug. 1993)
XP
(1997?) Beck: Organizational
patterns are one of the
three influences on XP
Sutherland:
Dr. Dobbs article
was the final key
Cockburn
Patterns
(1995-6)
Highsmith:
Agile
(feb. 2001)
Dr. Dobb;s
Article,
okt. 1994
PLoP1: Org
Patterns
(aug. 1994)
QPW Study
maj 1993
WYCASH Way,
Borland
1991-2
Agile
Manifesto
aug. 2001
Takeuchi
The New New
Development
Game, 1986
G&C
The Agile Manifesto
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.
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert Cecil Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Kent Beck
Mike Beedle
Arie van Bennekun
Alistair Cockburn
Ward Cunningham
Martin Fowler
2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.
Here is a personal perspective on Agile historybut a personal history that has
been ratied by Alistair Cockburn, Jeff Sutherland and others.
Agile is old. Many people were Agile before Agile was cool, adhering to its values
back in the 1950s and 1960s. As software became a management nightmare
managers used more and more approaches with roots in manufacturing line
management and applied them to software. Agile is trying to strip those off and
return us to the good old days.
Agile is not about software; its roots are in the Lean movement in Honda and Toyota
in Japan, and in a management paper by Takeuchi rooted in Honda!s manufacturing
culture. Software started articulating its use of these practices, and their
importance, in the 1990s. Ward Cunningham!s company Wycash, which did
nancial software, was one of the early arrivals.
Jim Coplien started an empirical research project at Bell Labs in connection with
their ISO 9000 improvement effort. After studying 120 organizations and ten years
later, it would culminate in the Organizational Patterns. Some of its early fruits were
a Dr. Dobb!s magazine article on practice at Borland, which to this day sets the
standard for Agile development.
Most of you have seen the Agile Manifesto. It is a brilliant document, and we let it
speak for itself here. Let me ask you a couple of things about the Manifesto:
What does it say about iteration?
What does it say about customer satisfaction with the product?
What new things does it tell you to do that you are not already doing?
What are the consequences of using processes, tools, documentation, contracts,
and plans?
You get the idea. The Manifesto is a framework for thinking about what you value; it
is not a framework that you can ll in according to your needs.
It is nonetheless a rm starting point for Scrumwhich itself is a framework that
guides you and you can ll in. However, don!t leave your brains behind: you will
need your wits just as much as a Scrum practitioner as an Agile fan.
G&C
Origins of Scrum
9
The New, New
Product
Development Game*
Borland QPW
Iterative,
Incremental
Development,
Timeboxes
Smalltalk Engineering Tools
Scrum
*Harvard Business Review, Jan. 1986, Takeuchi and Nonaka
G&C
Toyota Motor
Manufacturing
1. As an American company, contribute to the
economic growth of the community and the
United States.
2. As an independent company, contribute to the
stability and well-being of team members.
3. As a Toyota group company, contribute to the
overall growth of Toyota by adding value to
our customers.
This is how things came together within Easel. They used some Smalltalk
engineering tools. This came together in 1993.
The rst Scrum took place at the Easel corporation in 1993, some four years before
XP would appear. The foundations of Scrum include the paper by Hirotaka Takeuchi
and Ikujiro Nonaka in Harvard Business Review that talked about issues related to
knowledge management. Lean principles are also a major foundation, as are
Iterative and Incremental development and time boxing.
Easel used a Smalltalk tool set. All of this, combined with the concept of morning
Scrums that came from the Borland Quattro Pro for Windows Project, cooked
together into Scrum.
Toyota!s North America Mission. Gets to some of the values of Scrum. Most
companies would say: To be the most protable. The heart of Scrum is about
people, not about technology.
What does your company mission say?
G&C
Lean
Reduce waste! How?
Dont let mistakes propagate into the
process
Find problems early
Dont build something for which there isnt
a customer
Minimize on-hand inventory: optimize
material ow
G&C
History of Lean
Originally, Toyoda looms
Popularized in Toyota car manufacturing
(esp. the Prius line)
Also draws on Taylors application of Scientic
Method to manufacturing (1911)
Lean isn!t so much about minimalism as it is about being as efcient as possible by
reducing waste, eliminating inconsistencies in systems, and reducing stress. How
can we achieve these goals?
By catching errors before they propagate into the process where they do more
harm
By nding problems early, reducing the amount of work to undo them, and limiting
their scope of impact
By not wasting work building something for which there is no customer
By avoiding inventory-building: optimizing the ow so there is no build-up or
bunching along the way, and the ow is smooth
Scrum draws heavily on Lean principles
Lean dates back to Kiichiro Toyoda!s ideas for just-in-time delivery in his Japanese
loom company. As the company moved into automobiles later in its history, Toyoda!s
ideas would be rened to encompass what we now know as the Kaizen (continuous
process improvement) that was a large part of Japanese automobile excellence in
the 1970s. The ideas also have roots in Taylor!s ideas.
G&C
Lean: Ba / Mudha Mura
Muri
Source: Taiichi Ohno, Executive Vice President of Toyota
The Three Ms of inefciency
Muda: waste
Mura: inconsistencies
Muri: unharmonizing strain, disruptions in ow
Characteristics of Kaizen (continuous improvement) management
philosophy
Solution: communication (Kanban) and problem isolation (Andon)
The Andon cord
and the Andon
Board at Toyota
G&C
Muda Mura Muri in Scrum
The Andon Board
Kaizen: learn by doing
We do not master plan but
inspect and adapt
Muda (ichi)
No time-worked sheets, no
write-only documentation, no
shelfware
Mura (ni)
Short feedback loops to ensure
everyone is on the same page
Muri (san) Things are done when they are done;
no date or time itself denes DONE.
Focus on teams, not individuals, for
accountability and improvement.
Smooth out ow.
Lean concepts have their roots in the Toyoda company that made looms: just-in-
time delivery. But during the War, Japan became inefcient and in 1945, the Toyota
car company was stressed to the limit. Kiichiro Toyoda!s Just-In-Time system had
collapsed.
Taiichi Ohno was running Toyota!s nal assembly activity at the time, and it was his
Muda-Mura-Muri system that again brought prosperity to the lines. This was a form
of Kaizenan orientation to continuous process improvement.
His means to xing these problems? Communication (Kanban) and problem
isolation (Andon, using factory-wide Andon boards)
Lean is a conscious foundation of Scrum. The Andon board that opens project
status to the whole enterprise nds its counterpart in Task Boards. These are not a
way to do master planning but a way to deal with problems in real time as they arise
Kaizen. Scrum eliminates Muda (waste) by eliminating useless artefacts. It
eliminates Mura (inconsistencies) using short feedback loops. It addresses Muri by
driving towards certainty: done means done, and there is no tension that can arise
by putting different team members on different levels.
G&C
The result: Ba
Creative ow of innovation
Without inefciency, you get:
Process Improvement
Observation
Use of new Paradigms
Short time
Zero investment
Human Development
Prots & Savings
The system is a system, not a collection of individual, de-coupled
activities
Ba comes from:
Kanban: a framework for effective communication
Total elimination of mura, muri, muda
G&C
A Short History of XP
From: Kent Beck
To: Jeff Sutherland <jsutherland>
Reply: 70761.1216@compuserve.com
Date: Mon, 15 May 1995 18:01:15 -0400 (EDT)
Subj: HBR paper
_________________________
Is there a good place to get reprints of the SCRUM
paper from HBR? I've written patterns for something
very similar and I want to make sure I steal as many
ideas as possible.
Kent
This Kaizen approach of eliminating muda / mura muri leads to an emergent
propery called Ba. Ba is a kind of emergent energy that arises from perfect
harmony. The main drivers behind Ba are communication and the fact that systems
thinking comes to bear.
XP arrived late in the Agile story, in about 1997. It pretended to be a novel
integration of parts that t curiously well together, but was never proven to be such.
In fact, XP has rarely offers homage to any of its sources but changes allegiance
when it does so. In the proceedings of the fourth XP and Agile conference in 2003,
Beck ascribes XP to foundations provided by Coplien and Cunningham Coplien!s
contributions being the Organizational Patterns which, at the time, Beck discounted
as irrelevant.
G&C
Another short History of
XP
2. Scrum Theory,
Concepts, Practices
Motivation and basics of Scrum and Agile
Scrum as a viable framework
Scrum as 3 roles, 3 meetings, and 3 lists
Time Boxing
Poker Planning
Source: Fraser, Steven, Kent Beck, Bill Caputo, Tim Mackinnon, James Newkirk
and Charlie Pool. Test Driven Development (TDD). In M. Marchesi and G. Succi,
eds., XP 2003, LNCS 2675, pp. 459462, 2003. Springer-Verlag, Berlin and
Heidelberg, 2003.
In this section we look at some basic foundations and building blocks of Scrum.
This material motivates Scrum from a process perspective, argues why it might be
useful, and describes its major components at a high level. Scrum can be quickly
described as comprising four roles (the canonical three plus the customer), four
meetings, and three lists. To these we add the crucial components of estimation and
time boxing, and that denes the major parts of Scrum.
G&C
Why Scrum?
Be careful about prediciting, particularly if it
involves the future Niels Bohr
Traditional process (waterfall, Microsoft
Project) depend on prediction over long
time scales
They guess wrong about what is needed
They miss the mark about when it will be
done
G&C
What is Agile?
Agile lays out a vision and then nurtures
project resources to do the best possible to
achieve the plan
Agile is the art of the possible
The Agile Heart is self-organization
Niels Bohr, the Danish scientist, is reported to have said that we should be careful
about predicting things, particularly if it involves the future. Traditional development
depends on prediction. The longer the interval being estimated, the less certain
uncertain durations will be.
Why? The main reason is emergent requirements. We in fact cannot predict
everything we need to do because new requirements will arise as a side effect of
development. That causes us to miss the mark about when we will be done.
By reducing the prediction targets to short intervals, we limit how far astray we can
go.
Agile: What is possible? in the direction of the user desire rather than what we
must do. The heart of Agile is self-organization. This leads to radical practices: no
pre-dened roles within the team; no manager within the sphere of development
process.
G&C
How does Agile work?
Frequent inspection and adaptation
Emergence of requirements, technology, and
team capabilities
Self-organization and adaptation in response
to what emerges using feedback
Incremental emergence
Dealing with reality, not internal artifacts;
abstraction is evil; God is in the details
Mutual coordination
G&C
Game: Self-Organization
A game to illustrate self-organization
We use frequent course corrections to avoid wasting time off-track. We also
recognize that we can!t master plan, but that new requirements and technologies
emerge as a result of design. Technology changesoften improvesover time,
and our team learns to learn or may occasionally lose a member. We deal with
emergence one incremental step at a time.
A single point of control creates a bottleneck and makes it impossible for every
team member to leverage his or her talents at every moment. So we self-organize,
and every team member takes part in adapting to the ever-changing environment,
coordinating with those around him or her to ensure the team moves forward in the
same direction.
Artifacts here means internal artifacts such as UML diagrams and specications.
We are lean. Artifacts usually have heavy inertia inertia stronger than that of the
software itself. It is difcult to be Agile while dragging artifacts around.
G&C
How do we support it?
Maximized Communication
Effective, regular (daily!) meetings
Collocation and true small-team dynamics
Time-boxing: give the team space and
uninterrupted time to do work
We expect the team only to do their best: it
is easier to ask forgiveness than ask
permission
G&C
The Glossy Brochure
Empirical management & control processes
Complex projects since 1990
Deliver business functionality in 30 days
Wraps existing engineering practices
Adaptable to large, distributed, and long
projects
CMMI Level 3 and ISO 9001 compliant
Very simple but very hard
Effective communication connects us with our environment so we nd opportunities
to react, and so we can quickly self-organize to draw on the resources around us to
rise to problems and opportunity. We have frequentdailyformal interactions;
both the frequency and regularity are key. Because communication costs go up
geometrically with team size, we keep teams small and focused.
Time boxing honors the market reality that customers like things on time, for many
suitable denitions of thing. We honor the team by allowing them to commit to a
delivery and giving them uninterrupted time to deliver.
Scrum doesn!t promise anything. We can!t promise a delivery date or any
functionality because of emergence. We can only promise that the team will try their
best, and that we give the team an environment that best optimizes their chances to
do their best. There is no failure; only feedback. For this perspective to work, the
customer must be on board to the Scrum approach.
In a nutshell, for managers: Scrum is an empirical approach based on frequent
measurement and feedback, rather than a method. It has been used on complex
projects since 1990 and has been used on a large scale in enterprises such as
Yahoo, which has about 150 Scrum teams. It has no limitations for long-duration
projects.
Because it is focused on incremental delivery, it channels work programs to deliver
early and often. A typical sprint is about 20 working days (30 calendar days) and
today most sprints are half that long.
Scrum is CMMI level 3 compliant and, with a manager role, aspires to be level 5
compliant. It has been successfully embedded in a CMMI level 5 project where it
doubled productivity and cut error rates in half.
Scrum is very simple to describe. We will now move into a simple description of
Scrum. Though easy to describe, it is in fact very hard to do: it requires focus and
discipline. There is no free lunch.
G&C
Scrum as Org Patterns
NAMED STABLE
BASES
TAKE NO
SMALL SLIPS
COMPLETION
HEADROOM
RECOMMITMENT
MEETING
WORK
QUEUE
INFORMAL
LABOR PLAN
PROGRAMMING
EPISODE
DEVELOPER CON-
TROLS PROCESS
SOMEONE ALWAYS
MAKES PROGRESS
INTERRUPTS
UNJAM BLOCKING
SIZE THE
ORGANIZATION
ENGAGE
CUSTOMERS
SURROGATE
CUSTOMER
SCENARIOS
DEFINE PROBLEM
FIREWALLS
SELF SELECTING
TEAM
UNITY OF
PURPOSE
TEAM
PRIDE
PATRON ROLE
HOLISTIC
DIVERSITY
ENGAGE
QUALITY
ASSURANCE
GROUP
VALIDATION
COMMUNITY
OF TRUST
FEW ROLES
PRODUCER
ROLES
PRODUCERS IN
THE MIDDLE
ORGANIZATION
FOLLOWS LOCATION
SHAPING CIRCULA-
TION REALMS
DISTRIBUTE
WORK EVENLY
RESPONSIBILITES
ENGAGE
MOVE
RESPONSIBILITIES
3 TO 7 HELPERS
PER ROLE
COUPLING
DECREASES
LATENCY
Scrum Broken Down
Three Roles Three Meetings Three Lists
Product Owner
ScrumMaster
Development
Team
Sprint Planning
Part 1 (release)
Sprint Planning
Part 2 (sprint)
Daily Scrum
Sprint Review
Product Backlog
Sprint Backlog
Impediment List
Scrum is, in fact, very complex! Here is a breakdown of Scrum into the
Organizational Patterns it comprises. This graph shows one set of paths to
implementing Scrum in a low-risk way, one organizational pattern at a time. These
patterns go to the deep structure of Scrum that make it work.
However, we can view Scrum from another perspective, which is closer to the
process perspective more commonly adopted by process formalists and managers.
That perspective is easier to understand but tends to hide the fact that Scrum is
hard. We!ll start with the simpler description so we have a shared model of
understanding and then will come back to some of the difcult points.
We can summarize the structure of Scrum as four roles (the Scrum dogma says
three, but we include the customer here), four meetings, and three lists. Most
properties of Scrum relate either to these, or to the concepts of estimation and time
boxing. Over the next few hours we will cover these areas in detail and you will
have most of the head knowledge about Agile that you need.
Product Owner

Establishes, nurtures and communicates the product

vision

Manages ROI against an investment vision

Manages the product backlog

Makes release readiness decision

The Development Team + Product Owner is sometimes

called the Scrum Team
Scrum Development Team

Selects and develops highest items on product backlog

Splits up work into easily estimated, small tasks

Manages the development iteration to its commitments

Develops the product in time-boxed intervals called

Sprints
You will nd slide in this format scattered throughout the talk. A slide in this format
provides information about one of more of the Scrum roles.
The Product Owner is a key role in Scrum. His or her job is to optimize ROI for the
enterprise. ROI comes from progress towards a vision of products for the
enterprise; the Product Owner owns and embodies this vision.
While the Product Owner is often the rst point of contact from the Team to the
Customer, the Product Owner is not the customer representative. He or she
represents the Customer interests to the degree that it is in line with the interests of
the enterprise.
The Team is a differentiated collection of people, representing multiple disciplines
such as design, usability, programming, testing, and administration, that produces
product. No one can tell the team how much it should develop by a certain date; it
chooses items from an ordered stack of Product Backlog Items.
The Team splits up each item into small, easily estimated tasks, each one of which
takes two hours to two days.
Most important, the team is self-organized. When the team commits to delivering
some functionality in some period of time, they start developing. Once they start,
they are self-managing: no one can change their direction or tell them what to do.
They are committed to the delivery. They manage themselves to meet that
commitment.
The xed development interval that bounds the team!s commitment is called a
Sprint. The team produces potentially shippable product at the end of a Sprint.
G&C
Chickens and Pigs
Scrum meetings have Chickens and Pigs:
A Chicken and a Pig decided to go into business
to open a restaurant. The Pig asked the
Chicken: What should we name it? The Chicken
responded, How about, Ham and Eggs? The
Pig responded, No, thank-you: while youd be
involved, Id be committed.
In Scrum, Pigs may talk; Chickens may not
The ScrumMaster

Sustains culture and environment to optimize ROI

Organizes and runs Sprint Planning Meeting

Calls the Sprint Review Meeting

Runs brief daily Scrum meetings

Shields the team from outside disturbances

Removes obstacles to progress

May not direct the team nor tell them what to do

In many forums, including the morning Scrum, there is a distinction between
stakeholders and observers. Stakeholders are called pigs and may contribute to
discussion. Others may observe communication is a good thing but because
they don!t have a stake in the outcome, they may not contribute at that time.
At the morning Scrum, the discussions regard the development process: the
building of the product. Anyone not directly involved in building the product may not
speak.

The ScrumMaster is the team!s servant leader. His or her job is to do anything and
everything necessary to help the team achieve its ROI. The ScrumMaster is part
coach, part psychologist, part bodyguard, part clerk, part facilitator... and many
more. It is an extremely hard job and requires a special person.
Among the ScrumMaster!s duties are to organize and run the meetings: Sprint
Planning, Daily Scrums, and Sprint Reviews. The ScrumMaster keeps away those
who want to help the team, so the team isn!t distracted during a Sprint.
The ScrumMaster collects obstacles (called impediments in Scrum) and works to
remove them through whatever mechanism available. The ScrumMaster will
often appeal to line management and to other organizations to acquire resources,
smooth communication, or otherwise support the team.
The ScrumMaster may not give technical input to the team nor direct their decisions
in any way.
Customer

Not ofcially part of Scrum, but we talk about the

Customer a lot

Customers are common in software

End users are even more important, given a true Agile

focus

Gives feedback on results of every sprint

May request Product Backlog changes every sprint

The Basic Scrum Flow
The Customer is the stakeholder who receives the product: the end of our vision. In
most cases, the Product Owner acts on behalf of the customer as seen from the
perspective of the Team and the ScrumMaster. From the Product Owner!s
perspective, the Customer base is the source of corporate revenues.
So much for the roles: what is Scrum in its totality? Scrum is a process, and this
diagram exemplies the Scrum Flow.
The ow starts at the bottom left with a product vision, conceived by the Product
Owner. The vision encompasses products or a product line that will generate ROI
according to envisioned releases and milestones. The Product Owner articulates
this vision as Product Backlog Items (PBIs): work items, products, features, and
issues to be operated on by the Team.
The Product Backlog is a stack that is ordered to optimize ROI. The ordering takes
place at a Release Planning Meeting in the center of the picture. All roles are
involved in this meeting, where cost, business value, and all other relevant factors
come to the table.
The team takes PBIs from the top of the Product Backlog until they have one
Sprint!s worth of work. A Sprint is a major cycle that recurs once every two weeks to
once a month, more or less, and it is driven from the Sprint Backlog. The circle at
the top center represents a single Sprint cycle. The Sprint Backlog contains Tasks
that are broken down from the PBIs; a Task is two hours to two days. During a
Sprint all the project resources are available to the Team, but the Team is not
Three Lists
Impediment
List
G&C
The Impediment List
The ScrumMasters Product Backlog
Updated daily
Open, visible, and honest
Team should rst try to solve its own
impediments: ScrumMasters should push back
ScrumMaster takes ownership of
impediments that the team cant solve
Management is the last level of escalation
There are three lists in Scrum: the Product Backlog, the Sprint Backlog, and the
Impediment List.
The Product Backlog lists the features, products, and issues (Product Backlog
Items, or PBIs) that need to be worked by the team. The near-term items are at the
top and the more deferred items are at the bottom. Items become more elaborated
and rened as they move within a two-Sprint window at the top of the backlog. Each
PBI is ascribed with an effort estimate (only an estimatenot a commitment) and a
business value estimate. The Product Owner is responsible for maintaining the
Product Backlog, but any stakeholder may add an item to it at any time.
The Sprint Backlog contains Tasks that are broken down by the team from PBIs.
The Sprint Backlog is owned completely by the Team: only the Team may add or
delete items from the Sprint Backlog. The Team commits to delivering the entire
Sprint Backlog at the end of a Sprint; a given Sprint Backlog is extant only for one
Sprint.
The Impediment List is the ScrumMaster!s own private Product Backlog. It is a list
of obstacles and impediments for which the ScrumMaster is responsible. Removing
these impediments helps the team achieve its goals, improve its velocity, and enjoy
The Impediment List is the ScrumMaster!s priority-ordered product backlog. He or
she updates it constantly. It is shared in the Scrum of Scrums and, in general, is
available to anyone wishing to know.
What goes on the impediment list? Anything that can help the team meet its
commitments, or have more comfort or fun in meeting its commitments.
The ScrumMaster spends much of his or her time working the issues on the
Impediment List.
Three Meetings
G&C
Time Boxing
Time for the team to work undisturbed
Establishes project rhythms
The Sprint is the main unit of time boxing
A Sprint represents a Team commitment
During a Sprint,
priorities may not change
there may be no new external
requirements
Keeps feedback loops tight
Scrum is four meetings.
First is the Product Planning Meeting, where all the stakeholders come together
with their input for the Product Backlog. This usually happens between Sprints, or at
the end of Sprint iteration n - 1 in preparation for sprint n.
The Sprint Planning Meeting requires the Team, ScrumMaster and Product Owner.
At this meeting the Team selects PBIs from the top of the product backlog, counting
effort numbers as they go, until one Sprint!s worth of effort is exhausted. The Team
then breaks down those PBIs into Tasks of two to 16 hours and puts them on the
Sprint Backlog. The Sprint Backlog may be ordered but since all items must be
done at the end of the sprint, the ordering is only an optimization.
During the Sprint, there is a daily meeting called a Daily Scrum. This meeting
requires the entire Team and the ScrumMaster. Product Owners may attend, but
may not speak (they are Chickens).
At the end of the Sprint is a Sprint Review meeting, with the Product Owner, Team,
ScrumMaster, and potentially the Customer. This is where the team receives
feedback on the match between desired functionality and what the team delivered.
After meetings, roles, and lists, Time boxing is the next central Scrum concept. In
Scrum, the development activity is time-boxed to a unit called a Sprint, which is
usually two weeks to a month. If it is longer, people start asking for Microsoft
Project, and that suggests that people are guessing too much.
During a Sprint, the project resources are available to the Team but the Team is
isolated so it can get work done undisturbed. Having xed time boxes establishes a
project rhythm which helps set expectations over time not only of the team, but of
the customer, product owner and management as well.
At the beginning of a Sprint, the team commits to complete a list of Tasks which
they dene. By complete we mean absolutely complete at the level of the Team!s
consensus, and we mean complete by the end of the time box. To improve
chances that the Team can keep its commitment, Scrum promises that no one will
change work priorities during a Sprint, and that they no one external to the team will
give them more work to do. Of course, because of emergent requirements, the
team may give itself more work during a Sprint as they discover poor estimation or
surprises in the requirements.
Sprints are short the shorter they are, the less likely that estimates will be
G&C
Poker Planning
The Delphi technique brought up-to-date
Visibility of differences
Drive to consensus
Breaks down linear thinking
G&C
Why Planning Poker?
It ensures everybody participates in the
estimation
It avoids 'coloring' of the estimates by a few
key members of the team
It speeds up the estimation process
Its pigs, not chickens
It is fun!
Scrum is fun, so estimation is a game. It is a curiously effective game that brings out
the best in a team in its ability to estimate. Poker Planning is just the Delphi
technique brought up-to-date. It!s a way of making differences of opinion visible and
of using the ensuing feedback to drive to consensus. The game is played with a
deck of cards with Fibonacci numbers (or a variant thereof) on them. Using
Fibonacci numbers breaks down linear thinking.
References:
Mike Cohn, Agile Estimating and Planning, Prentice Hall PTR, Upper Saddle River,
NJ, 2005. Read Chapter 6: Techniques for Estimating online.
J. W. Grenning, Planning Poker, 2002, http://www.objectmentor.com/resources/
articles/PlanningPoker.zip.
An Empirical Study of Using Planning Poker for User Story Estimation Proceedings
of AGILE 2006 Conference (AGILE!06), Nils C. Haugen, Objectnet as
Planning poker is better than long, detailed planning meetings that spend ten times
as long as they should with results only 5% or 10% better than if one spent a half
hour or so. Why? Because you bring everyone!s perspective to the table. What if it
will take ten times as long to test as the developer knows? The tester has the
chance to contribute that understanding to the estimate. If everyone has an
opportunity to contribute, the estimates aren!t stilted by a single member.
Alsoit!s fast and fun. Most of the time, planning poker is done by pigs rather than
chickens. This avoids the too-common problem of one group telling another what
their schedule is. People can only commit for themselves, not for anyone else.
G&C
Story Points
How far from here to that distant landmark?
How you give the answer depends on the next question...
Relative to that distance, how far is it to the
nearer landmark?
Given that, if you can answer either of these
for either object, you can answer both for
both:
How long would it take in a car?
How long would it take to walk
G&C
Units of Estimation
Ideally, story points: relative estimation
Alternatively, ideal hours
For Sprints, it eventually comes down to
hours
However, try to learn how many story
points you can do per Sprint.
This ratio is called the teams velocity
Story Points are a form of relative estimation. Relative estimation distances us from
master-planning tasks onto individual days (should we plan this work around
National Day?) They also remain stable as the team becomes more effective and
increases its velocity. If we estimate in units like this, we can observe increases in
team velocity if we estimate in hours or days, it!s harder to observe improvement.
As an example, consider how far it is to a distant landmark. You may ask: in
meters? In seconds of walking time? My answer is that I don!t care: the answer
should be unitless. It should make sense only in comparison to the measurement
for another landmark.
Once we have relative estimation done, we can use sparse data on individual tasks
to estimate many tasks.
Not only are the units non-linear (Fibonacci numbers) but they are meant to
represent abstract, unitless chunks of work. We ideally do relative estimation.
Estimation units are used in two places: as input to the product owner to assess the
ordering of Product Backlog Items, and for the team in committing to Tasks for a
sprint. Product Backlog items don!t represent a commitment. The Product Owner
may ask how to convert points to hours, and the team can relate its current
understanding of the mapping between these two numbers.
Relative estimation is a challenge for teams that are new to it: they too easily
degenerate into using days and hours. If your team is like this, then use ideal
hours (days are not a ne enough level of granularity).
Eventually, for Sprints, these numbers turn into hours and the temptation remains to
use hours instead of story points. Instead, each team should learn how many story
points it can do per Sprint. One Scrum failure modes arises when teams become
too enamored with hour-based estimation instead of story-point estimation for
Sprints.
G&C
Simple Rules of the
Game
Each participant gets a deck of estimation cards.
The moderator (usually the product owner or an analyst), presents
one user story at a time
The product owner answers any questions the team might have.
Each participant privately selects a card representing his or her
estimate.
When everybody is ready with an estimate, all cards are presented
simultaneously.
In the (very likely) event that the estimates differ, the high and
low estimators defend their estimates.
The group briey debates the arguments.
Make a new round of estimation.
Continue until consensus has been reached.
The moderator notes the estimate, and the group continues with
the next user story.
G&C
Planning Poker Tips
Baseline the rating system by scanning all user stories and
assigning the estimate value of "1" to the simplest story
The cards reect a moderately narrow range of numbers ranging
about one order of magnitude. Overly large user estimates suggest
that the PBI/task be split into multiple items.
Consider time boxing the debate period. The goal is that the
technique be simple and lightweight
The technique works best with three to ve participants
representing architecture, development, testing, and deployment.
Work from a list that has already been sorted by business value,
and avoid focusing on business value during the work queue priority
ordering.
Use the three-nger test as an audit on the condence of whether
the team will accomplish all Tasks during a spring
The rules are self-explanatory. The goals are to generate consensus in a low-cost
way.
Some tips:
Baseline your estimation by assigning the value of 1 or 2 to the simplest item or to a
very simple item on your list.
If an estimate is too far out of range, split the item up.
Try time-boxing the estimation period to a half-hour, or an hour, or maybe a half day.
Time spent estimating is waste. Government contractors sometimes spend as much
of 20% of their budget on estimation and contract preparation; we want instead to
be agile.
Keep the estimation team small. Go for consensus, but it!s good enough if you get
80% of the cards in agreement with the rest one card away.
Don!t let business value change your focus or fascination for the feature stick to
the effort required. The Product Owner will sort out the question of effort and
business value later.
At the end, make sure there is buy-in and enthusiasm for the estimation using the
G&C
Exercise: Kitchen
Remodeling
Install new hardwood oor
Renish (remove, sand, repaint) the cabinets
Install granite countertop instead of tile
Repaint entire kitchen
Lay shelf paper
Install recessed lighting
Replace electric stove
Install built-in refrigerator
Install a new oven
Plumb the island and add sink
Replace simple window with a bay window
G&C
3. Release Planning and
the Product Backlog
Product Planning Meeting
Meeting to produce the initial Product
Backlog and update it over time
All stakeholders present: developers,
Product Owner, ScrumMaster, the Team,
maybe some customers
The Product Owner runs the meeting
The ScrumMaster makes sure the meeting
happens
Assignment: Build a product backlog from these items.
Acknowledgments to Mike Cohn for this exercise!
The rst step of a brand new project is a product vision. The Product Owner breaks
the product down into deliverables over time. At the very start, the vision can extend
6 to 18 months into the future.
The Product Backlog is the central project management artifact. It is created and
owned by the Product Owner with input from marketing and/or customers and from
the Team that will implement it. There is an initial meeting to build the initial Product
Backlog. The more perspectives that are brought to bear, the more likely we will be
to build the right thing and to match schedule expectations.
The ScrumMaster is likely to call this meeting, but the Product Owner runs the
meetings.
A smaller version of this meeting recurs periodically once near or at the end of
each Sprint to update the Product Backlog. We do this to reect changes in the
market, emergent requirements learned by the team, and any change including
any customer change that the Product Owner wants to put on the backlog. We
embrace change.
The Product Owner

One person

Maximizes ROI accountable for value and ROI

The Answer Man to the team during a Sprint

Establishes and sustains product funding

Decides which Sprints are releasable

Ensures:

one set of requirements drives development

no confusion from multiple bosses, different

opinions, and interference from the outside
The Product Owner

Develops and maintains the Product Backlog

Orders the Product Backlog

Empowered to make decisions for all customers

and users

Attends Sprint planning meetings and Sprint review

meetings

Presents and explains Product Backlog to the team

Manages the vision, ROI, and releases

The rst responsibility of the Product Owner is to maximize ROI. The Product
Owner does this by managing the Product Backlog. The backlog can change at any
time, but the team takes a snapshot of it and works on the most imminent issues
during a sprint, without being interrupted. At every Sprint the Product Owner works
with the team to re-order the Product Backlog before the Team takes items from the
top. The ordering should be designed to optimize value.
The Product Owner is probably the rst point of contact to answer the Team!s
questions during a Sprint; however, the Product Owner may not interfere with the
team during a Sprint. Only in the case of an emergency (Stop the Line) can a
Product Owner stop the Sprint.
Product Managers are used to throwing the requirements over the wall and
making delivery the problem of developers. In Scrum, the Product Owner is the
one, single, wrenchable neck for ROIthat is why it is one person. Of course, the
function can be lled by a Product Owner team, but there must be a single,
accountable Product Owner among them.
The Sprint Review is a crucial point of feedback for the Team and the Product
Owner.
The Product Owner owns and maintains the Product Backlog. The Team and others
help, but the Product Owner has the last say about the Product Backlog content.
The Product Owner has the last word on business requirements, and can represent
all customers and end users from a business perspective.
The Product Owner represents business interests at the Sprint planning meetings
and is a key reviewer at Sprint reviews. The Product Owner presents the Product
Back at a Release Planning meeting. During Sprint planning the Product Owner
claries issues for the team. In a good Scrum, the Product Owner and Team work
as partners with a warm working relationship.
As the bottom line, the Product Owner!s job is to manage the vision, ROI, and
releases.
The Product Owner may not:

act as a Project Manager

demotivate the team its all about trust

tell what and when something must be

done
The product owner may:

talk at the daily Scrum (if very experienced)

clarify issues

deliver the latest business value

inspire the team value

terminate a Sprint in an emergency

The Product Owner may not drive the project to completion by telling the team what
to do. He or she may only set the ordering of Product Backlog items; the team
chooses them in the order prescribed by the Product Owner but takes as many or
as few as it thinks it can handle during a sprint. The Product Owner may not
override this.
The Product Owner must trust the team and defer to its members! judgment. The
Team and the Product Owner should have a partnership relationship, not an
adversarial relationship.
The product owner may not ne-tune priorities during a Sprint.
An experienced Product Owner can speak at the daily Scrum. He or she is there to
clarify issues to the team during planning and during a Sprint.
The Product Owner can deliver the latest business value to the enterprise. He or
she can inspire the team to increase value.
In case of an emergency a radical business environment change, major
requirement change, or a short-term opportunitythe Product Owner may
terminate a Sprint. A new Product Backlog is built and a new Sprint starts thereafter.
G&C
The Product Backlog
List of functionality, technology, issues
Issues are placeholders that are later dened as
work
Emergent, ordered, estimated
More detail on highest backlog items
One list for multiple teams
Product Owner responsible for ordering
Any stakeholder can contribute
Maintained and posted visibly
G&C
Sprint Planning
Product Owner presents the Product Backlog to the
team
Re-evaluate ordering of top 20% of Product Backlog
every Sprint and reorder
Granularize and estimate probable Product Backlog for
next Sprint
Have team allocate 5% of their Sprint time for this
activity, which should be compartmentalized to
minimize interruption, and
Never allow the Product Owner to go into the Sprint
Planning meeting with an inadequate Product Backlog
A product backlog can contain different things, but it is good for a given project (or
perhaps a given sprint) to use items of like kind so they can be compared with each
other. For example, during architecture development on early sprints, the backlog
may be a list of domains; during feature development, it is likely to be user stories
or use cases. These items are placeholders for work programs that will be dened
later.
When developing a product backlog the product owner will order *all* items. Of
course, there is more attentiveness and detail accorded to lower items. The product
owner is responsible (one single wrenchable neck) for this list; however, inputs for
this list can come from any constituency. The Business Plan or Vision Statement
may be a source for some of these considerations.
In a Scrum of Scrums development that builds an integrated functionality, there is
one list for multiple teams.
The list is posted visibly -- there are no secrets
The Product Backlog presents the backlog to the team, emphasizing the top 20% of
the items, or the items for the next two Sprints. The team will focus on the effort
required to implement those and the Product Owner may react by re-ordering items.
This activity should be accounted in developers! time about 5% of their time,
depending on the length of a Sprint.
At the end of the meeting, all items in the top two Sprints! worth of Product Backlog
Items should be enabling specications.
G&C
4. Production and
Sprints
The ScrumMaster
The Sprint Goal
Sprint Planning and Task Boards
The Daily Scrum
Burndown Charts
Done
Sprint Signatures
Surprises and Aborting the Sprint
Architecture
The ScrumMaster Role

Servant Leader and Facilitator:

Removing the barriers between development and the

product owner so the product owner directly drives
development

Teaching the product owner how to maximize ROI and

meet their objectives through Scrum

Improving the lives of the development team by facilitating

creativity and empowerment

Improving the productivity of the development team in

any way possible, and

Improving the engineering practices and tools so each

increment of functionality is potentially shippable
Most of this seminar relates to Sprints where the production takes place, the
software is written. This is the domain of the Team and its number one helper the
ScrumMaster.
The ScrumMaster is the Team!s best friend.
His or her job is to remove barriers so that the customer and Team truly work as a
Team, subject to Scrum provisions. The ScrumMaster is often the change agent
who carries the torch for Scrum in the organization.
Day-to-day, the ScrumMaster is an administrator: organizing meetings (e.g. Daily
Scrums), getting resources, etc. His or her main job is to support the Team. It is the
ScrumMaster!s job to make sure the Team succeeds by removing impediments and
supporting productive work.
Note that it says in any way possible. We don!t tell you how. Of course you must
meet corporate standards.
Why the ScrumMaster?

Scrum makes problems visible

Project managers too often help hide

problems

ScrumMasters help keep problems visible

Resolving problems relieves stress on the

team

The team gets better and better

ScrumMaster Etiquette

Do what it takes, but...

A dead ScrumMaster is a useless

ScrumMaster

The team hires and res the ScrumMaster

Powerless, except:

May remove a disruptive person from the team

The ScrumMaster is instrumental in making problems visible. Too often, in
conventional projects, the Project Manager tries to keep problems inside the
group. This leads to a deep dysfunction called organizational incest.
If problems are visible it reduces stress on the Team and makes it possible for the
Team to improve.
Note that the ScrumMaster keeps his or her own backlog of problems, the
Impediment List, which is ordered.
The ScrumMaster is there to break the rules. The ScrumMaster does what it takes.
This means getting in the face of management. This means doing anything that
does not demoralize the team or drive the customer away.
The ScrumMaster makes unpopular decisions. It is important for the ScrumMaster
to sustain a good relationship with all stakeholders, Team members, and particularly
with the Product Owner. If the ScrumMaster is too hard on the team or too
demanding, the Team may re him or her. Management may re the ScrumMaster
just because they make uncomfortable truths visible.
As a ScrumMaster, you should make truth visible. However, remember that the cost
of truth might be your job and that a dead ScrumMaster is a useless
ScrumMaster. It is important to learn the political landscape and to do everything
that best increases value in the long term including support of the human value
system of the organization.
The only power that a ScrumMaster has is to remove a disruptive Team member
from the Team.
Single Wrenchable Neck

The ScrumMaster is the single point of

accountability for the Teams Sprint delivery

The Product Owner is the single point of

accountability for the companys ROI
G&C
ScrumMaster: Origins
Scrum is about commitment, and commitment goes along with responsibility,
authority, accountability, and control. Who is accountable if the Team fails its
commitment? Discussions of this nature are between management (or the
customer) and the ScrumMaster. If the team regularly misses its commitment, the
ScrumMaster is the rst place to look. Maybe the ScrumMaster would make a better
Team member, line manager, sales person, or Product Owner.
If the enterprise does not deliver on its ROI, the product owner is the point of
accountability.
The point of accountability in Scrum is called, colorfully enough, the one single
wrenchable neck.
Here is an entertaining view of perhaps what a ScrumMaster should not be like.
G&C
The Sprint Goal
An optional motivator to draw the team
together
However, remember that the Product Owner
controls the raw materials for a Sprint
Upshot: Take a Sprint Goal when you can get
it but dont be limited when you cant
G&C
Sprint Planning Meeting
1 Day
1 - 4 hours to break down the Product
Backlog
1 - 4 hours for team to dene Sprint Backlog
Anyone can attend, but primary conversation
and work is between the team and the
Product Owner
A team denes an optional Sprint goal at the beginning of a Sprint. If a Sprint is a
disjointed collection of goals, then you lose team productivity. While individual
productivity might vary two orders of magnitude, team productivity can improve by a
factor of 4000. The more that a team feels like a team, the better for everyone. A
sprint goal helps bring the team together.
Sometimes all that the Product Owner can offer the team is a duke!s mixture of
product backlog items. Sometimes a Sprint Goal isn!t reasonable or possible.
The Sprint Planning meeting is one of the four important meetings in Scrum. It is
really two half-day meetings; it should never last longer than a day. That wouldn!t be
lean.
The goal of this meeting is to break down and estimate the top items on the Product
Backlog, and to rene them into tasks that are placed in a freshly created Sprint
Backlog.
Anyone may attend the Sprint Planning meeting, but the main work takes place
between the Team and the Product Owner. The Team and the Product Owner are
pigs at this meeting, and the rest are just chickens.
G&C
Sprint Planning Meeting
Product Backlog
Team Capabilities
Business Conditions
Technology Stability
Executable Product
Increment
Review,
Consider,
Organize
Next Sprint Goal
Product Backlog
Sprint Backlog
G&C
Sprint Planning Meeting
Part 1
Team denes a Sprint Goal
Team selects as much Product Backlog as it
believes it can develop during the next Sprint
Estimates may be revised after review
Lower backlog items may be included if
appropriate and Product Owner agrees
Estimated effort/cost for selected Product Backlog
Items is a budget that team manages to; negotiate
with Product Owner before exceeding
This is a two half-day meetings, usually in the morning and afternoon, between
sprints. The rst meeting deals with the product backlog; the second, with a sprint
backlog.
Note the optional concept of a sprint goal.
The Sprint Planning Meeting has two parts. The rst part focuses on the Product
Backlog items. The Team denes an optional Sprint Goal that leads the team
forward. The team estimates each Product Backlog Item (many of these will have
estimates from previous Release Planning Meetings; the top two Sprints! worth
should be updated). The Product Owner orders the items in a way that capitalizes
on the current resources, state of the market, effort estimations and business value,
to optimize ROI. The team can further iterate these estimates in Part 2 of the
meeting.
Sometimes the team sees an opportunity for low-hanging fruit: an item further down
in the backlog may be easily completed if combined with higher priority work. That!s
ne, but the nal decision lies with the Product Owner.
The Product Owner may evaluate ROI on a per-item basis. No single item!s cost
may exceed the Product Owner!s development budget for it. Such costs are an item
of negotiation.
G&C
Sprint Planning Meeting
Part 2
Four hours maximum
Denes how to build the product functionality into a
product increment in the next Sprint. This is called the
Sprint Backlog
Attended by the Product Owner, Scrum Team,
development management
The team extends design
Team denes Sprint Backlog all items to be completed
during the Sprint
Team member sign up for work and estimate their tasks
Tasks are 1 - 16 hours long; if longer, break down
G&C
The Wednesday Meeting
Schedule weekly Product Backlog Meetings
Allows Feature Analysis and Release Planning
updates more frequently than once per
sprint
Product Owner discusses new ideas with the
team
The team estimates new PBI items
Can make the Sprint planning meeting (Part
I) a no-brainer
In Part 2 of the planning meeting we focus on the Sprint Backlog. This is the list that
the Team works on during the Sprint. The Product Owner attends to help clarify
requirements; the Team puts together the backlog; and development management
is present to provide resources as needed.
During Part 2 the team extends the design into more detail; that helps them rene
estimation. All this in hand, the team can build a Sprint Backlog the items to be
completed during the Sprint.
An ideal Scrum team is undifferentiated: team members sign up only for the rst
task they will work on. When team members complete a task, they take another one
from the backlog and start working on it. In a more practical sense the team can
build on team members! specializations and wishes, with the understanding that
Task ownership can change any time during the Sprint.
If you estimate a task at more than two days, you!re probably guessing. Long tasks
should be split up into short ones.
G&C
A Sprint Backlog
G&C
Taking it to the Task
Board
Here is an example Sprint backlog. The backlog tracks remaining work over the
Sprint. We never track hours worked; only hours remaining. Such data are at the
core of the burn-down chart.
What kinds of tasks do you see on the backlog?
It is a great idea to have a visible task board in the developer area. Progress should
be visible to the entire Team, to the Product Owner, to Management, and to other
Teams. There are many ways to do a Task Board and Scrum does not tell you how
to do it.
How would you modify this task board for your use?