Scrum Reference Card

by Michael James and Luke Walter

About Scrum Scrum Roles

A Management Framework Scrum Development Team
Scrum is a management framework for incremental product • Cross-functional (e.g., includes members with testing skills, and
development using one or more cross-functional, self-organizing teams others not traditionally called developers: business analysts,
of about seven people each. designers, domain experts, etc.)
It provides a structure of roles, events, rules, and artifacts. Teams are • Self-organizing / self-managing, without externally assigned roles
responsible for creating and adapting their processes within this • Plans one Sprint at a time with the Product Owner
framework. • Has autonomy regarding how to develop the increment
Scrum uses fixed-length iterations, called Sprints. Sprints are no more • Intensely collaborative
than 30 days long, preferably shorter. Scrum teams try to develop a • Most successful when located in one team room, particularly for the
potentially releasable (properly tested) product increment every Sprint. first few Sprints
An Alternative to Waterfall • Most successful with long-term, full-time membership. Scrum moves
work to a flexible learning team and avoids moving people or
Scrum’s incremental, iterative approach trades the traditional phases of splitting them between teams.
"waterfall" development for the ability to develop a subset of high-value • 6 ± 3 members
features first, incorporating feedback sooner.
• Has a leadership role
Requirements
Analysis
Product Owner
Design
• Single person responsible for maximizing the return on investment
Code (ROI) of the development effort
• Responsible for product vision
Integration
• Constantly re-prioritizes the Product Backlog, adjusting any long-
Test term expectations such as release plans
• Final arbiter of requirements questions
Deploy
• Decides whether to release
Figure 1: Traditional “waterfall” development depends on a perfect understanding of the product
requirements at the outset and minimal errors executing each phase. • Decides whether to continue development
• Considers stakeholder interests
• Has a leadership role

Scrum Master
• Works with the organization to make Scrum possible
• Ensures Scrum is understood and enacted
• Creates an environment conducive to team self-organization
• Shields the team from external interference and distractions to keep
it in group flow (a.k.a. the zone)
• Promotes improved engineering practices
• Has no management authority over the team
• Helps resolve impediments
• Has a leadership role

Figure 2: Scrum blends all development activities into each iteration, adapting to discovered
realities at fixed intervals.

The greatest potential benefit of Scrum is for complex work involving

knowledge creation and collaboration, such as new product
development. Scrum is usually associated with object-oriented software
development. Its use has also spread to the development of products
such as semiconductors, mortgages, and wheelchairs.

Doing Scrum, or Pretending to Do Scrum?

Scrum’s relentless reality checks expose dysfunctional constraints in
individuals, teams, and organizations. Many people claiming to do
Scrum modify the parts that require breaking through organizational
impediments and end up robbing themselves of most of the benefits.

© Copyright 2010-2020 Michael James and Luke Walter. All rights reserved.
 Scrum Events Product Backlog Sprint Backlog
User login

User login determine requirements for password

policy
page layout
(design)
get latest JBoss
running

Selected
SSL enable

Product choose persistence

strategy
(Hibernate?)
write code (using
test-driven
development)
exploratory
testing

Increment
Reset lost password

SSL enable analyze example config file

get official
certificate from I.T. install certificate

Sprint Planning Account lockout

Meeting update deploy

target in [Link]
exploratory
testing (3
browsers)
update installation
document

LDAP integration

Reset lost password agree on best algorithm for

randomizing passwords
decide where to
put the link
code (using test-
driven
development)

Register a new login

add screenshot
and text to user exploratory
manual testing

Backlog
Edit registration

Daily Scrum Refinement Admin reporting

Account lockout
after three
code (using test-driven development)
update migration
tool to include new
row for locked
account
manual test (try
to break in with
policy installed)

Meeting attempts

update documents
User-managed

Figure 4: Sprint Planning outcome is selected Product Backlog Items (PBIs) and subordinate
Sprint Review Sprint Tasks.
Meeting
Daily Scrum and Sprint Execution
Every day at the same time and place, the Scrum Development Team
members spend a total of 15 minutes inspecting their progress toward
Sprint the Sprint goal and creating a plan for the day. Team members may
Retrospective share with each other what they did the previous day to help meet the
Meeting
Sprint goal, what they’ll do today, and what impediments they face.
Standing up at the Daily Scrum will help keep it short. Topics that
require additional attention may be discussed by whoever is interested
after every team member has spoken.
Figure 3: Scrum flow. The team may find it useful to maintain a current Sprint Task List and a
Sprint Burndown Chart. During Sprint execution, it is common to
Sprint Planning discover additional tasks necessary to achieve the Sprint goals.
Impediments caused by issues beyond the team’s control are
At the beginning of each Sprint, the Product Owner and team plan
considered organizational impediments.
which Product Backlog Items they will attempt to convert to working
product during the Sprint. The Product Owner is responsible for The Daily Scrum is intended to disrupt old habits of working
declaring which items are the most important to the business. The separately. Members should remain vigilant for signs of the old
Development Team is responsible for selecting the amount of work they approach. For example, looking only at the Scrum Master when
feel they can implement without accruing technical debt. The team speaking is one symptom that the team hasn’t learned to operate as a
“pulls” work from the Product Backlog to the Sprint Backlog. self-organizing entity.
When teams are given complex work that has inherent uncertainty,
Sprint Review
they must work together to intuitively gauge how much work to pull
into a Sprint, while learning from previous Sprints. Planning their At the end of the Sprint, the Scrum Team holds Sprint Review to
hourly capacity and comparing their estimates to actuals makes the inspect and adapt the product as it emerges. They demonstrate a
team pretend to be precise and reduces ownership. Unless the work is working product increment to everyone who is interested, particularly
truly predictable, they should discard such practices within the first few customers and end users, and get their feedback.
Sprints or avoid them altogether.
The team reviews the items selected during Sprint Planning and
Until a team has learned how to complete a potentially releasable explains which items are considered done. For example, a software item
product increment each Sprint, it should reduce the amount of that is merely “code complete” is considered not done because untested
functionality it plans. Failure to change old habits leads to technical software isn’t shippable. Incomplete items are returned to the Product
debt and eventual design death, as shown in Figure 14. Backlog and ranked according to the Product Owner’s revised priorities
as candidates for future Sprints.
If the top of the Product Backlog has not been refined, a portion of the
event might be spent doing this. The Scrum Master may help the Product Owner and stakeholders
convert their feedback to new Product Backlog Items for prioritization
Toward the end of the Sprint Planning Event, the team determines how
by the Product Owner. Often, new scope discovery outpaces the team’s
it will accomplish the work. For example, they may break the selected
rate of development. If the Product Owner feels that the newly
items into an initial list of Sprint Tasks.
discovered scope is more important than the original expectations, new
The maximum allotted time (a.k.a. timebox) for planning a 30-day scope displaces old scope in the Product Backlog. Some items will never
Sprint is eight hours, reduced proportionally for a shorter Sprint. be done.
External stakeholders and end users should participate. New products,
particularly software products, are hard to visualize in a vacuum. Many
customers need to be able to react to a piece of functioning software to
discover what they will actually want. Iterative development, a value-
driven approach, allows the creation of products that couldn’t have
been specified up front in a plan-driven approach.

© Copyright 2010-2020 Michael James and Luke Walter. All rights reserved.
Sprint Retrospective any allergy records exist.” While the engineers anticipated significant
technical challenges in parsing the internal aspects of the allergy
Each Sprint ends with a retrospective. The team reflects on its own records, the presence or absence of any allergy was the most important
process. They inspect their behavior and take action to adapt it for thing the doctors needed to know. Collaboration between business
future Sprints. people and technical people to split this epic yielded a story
Dedicated Scrum Masters will find alternatives to the stale, fearful representing 80% of the business value for 20% of the effort of the
meetings everyone has come to expect. An in-depth retrospective original epic.
requires an environment of psychological safety not found in most Since most customers don’t use most features of most products, it’s
organizations. Without safety, the retrospective discussion will either wise to split epics to deliver the most valuable stories first. While
avoid the uncomfortable issues or deteriorate into blaming and delivering lower-value features later is likely to involve some rework,
hostility. rework is better than no work.
A common impediment to full transparency on the team is the presence This activity has also been called “Backlog Grooming.”
of people who conduct performance appraisals.
Cut/
Another impediment to an insightful retrospective is the human paste
tendency to jump to conclusions and propose actions too quickly. Agile plain Cut/
text paste
Retrospectives, the most popular book on this topic, describes a series rich text
of steps to slow this process down: Set the stage, gather data, generate Cut/paste rich
text and graphics
insights, decide what to do, close the retrospective.1 Another guide database
recommended for Scrum Masters, The Art of Focused Conversations, schema

breaks the process into similar steps: Objective, reflective, interpretive,

and decisional (ORID).2
A third impediment to psychological safety is geographic distribution.
Geographically dispersed teams usually do not collaborate as well as Figure 5: During Backlog Refinement, large PBIs (often called “epics”) near the top of the Product
Backlog are split into thin vertical feature slices (“stories”), not horizontal implementation phases.
those in team rooms.
Retrospectives often expose organizational impediments. Once a team
has resolved the impediments within its immediate influence, the
Scrum Master should work to expand that influence, chipping away at
the organizational impediments. Scrum Artifacts
Scrum Masters should use a variety of techniques to facilitate
retrospectives, including silent writing, timelines, and satisfaction
Scrum defines three artifacts: Product Backlog, Sprint Backlog, and
histograms. In all cases, the goals are to gain a common understanding
Increment.
of multiple perspectives and to develop actions that will take the team
and organization to the next level.
Product Backlog
Backlog Refinement
only one item
User login

Most Product Backlog Items (PBIs) initially need refinement because at a time
is top priority
SSL enable

they are too large and poorly understood. While Backlog Refinement is top items
not a required event, it is a required activity. Most Scrum Teams find it are more Reset lost password

useful to take a short time out of every Sprint for this activity. They get granular
together to prepare the Product Backlog for upcoming Sprints. Account lockout after

In Backlog Refinement, large vague items are split and clarified, LDAP integration

considering both business and technical concerns. Sometimes a subset

of the team, in conjunction with the Product Owner and other Register a new login

stakeholders, will compose and split Product Backlog Items before

involving the entire team. Admin reporting

While refining items, the team may estimate the amount of effort they Figure 6: Product Backlog
would expend to complete items in the Product Backlog and provide
other technical information to help the Product Owner prioritize them.3
• Force-ranked (prioritized) list of desired functionality
A skilled Scrum Master can help the team identify thin vertical slices of • Visible to all stakeholders
work that still have business value, while promoting a rigorous
• Any stakeholder (including the Team) can add items
definition of “done” that includes proper testing and refactoring.
• Constantly re-prioritized by the Product Owner
It is common to write Product Backlog Items in User Story form.4 In
• Constantly refined by the Scrum Team
this approach, oversized PBIs are called epics. Traditional development
breaks features into horizontal tasks (resembling waterfall phases) that • Items at top should be smaller (e.g., smaller than 1/4 of a Sprint)
cannot be prioritized independently and lack business value from the than items at bottom
customer’s perspective. This habit is hard to break.
Agility requires learning to split large epics into user stories
representing very small product features. For example, in a medical
records application, the epic “display the entire contents of a patient’s
allergy records to a doctor” yielded the story “display whether or not

1 Agile Retrospectives, Pragmatic Bookshelf, Derby/Larson (2006)

2 The Art of Focused Conversations, New Society Publishers (2000)
3 The team should collaborate to produce a jointly-owned estimate for an item.
4 User Stories Applied: For Agile Software Development, Addison Wesley, Cohn (2004)

© Copyright 2010-2020 Michael James and Luke Walter. All rights reserved.
Product Backlog Item (PBI) Sprint Task (optional)
• Describes the what (more than the how) of a customer-centric • Describes how to achieve the PBI’s what
feature • Typically involves one day or less of work
• Often written in User Story form • During Sprint Execution, a point person may volunteer to be
• Has a product-wide definition of done to prevent technical debt primarily responsible for a task
• May have item-specific acceptance criteria • Owned by the entire team; collaboration is expected
• Effort is estimated by the Development Team, ideally in relative units
(e.g., story points) determine get latest
requirements page layout JBoss
for password (design) running
policy
Account lockout after three
attempts

Acceptance Criteria: .... write code

choose (using test-
persistence exploratory
strategy driven testing
(Hibernate?) development
)
Small

Figure 7: A PBI represents a customer-centric feature, usually requiring several tasks to achieve
definition of done. Figure 9: Sprint tasks required to complete one backlog item require a mix of activities no longer
done in separate phases (e.g., requirements elicitation, analysis, design, implementation,
deployment, testing).
Sprint Backlog
• Consists of selected PBIs negotiated between the team and the Sprint Burndown Chart (optional)
Product Owner during Sprint Planning
• Summation of total team work remaining within one Sprint
• No changes are made during the Sprint that would endanger the
Sprint Goal • Updated daily
• May go up before going down
• Initial tasks are identified by the team during Sprint Planning
• Intended to facilitate team self-organization
• Team will discover additional tasks needed to meet the Sprint Goal
during Sprint execution • Fancy variations, such as itemizing by point person or adding trend
lines, tend to reduce effectiveness at encouraging collaboration
• Visible to the team
• Seemed like a good idea in the early days of Scrum, but in practice
• Referenced during the Daily Scrum often misused as a management report, inviting intervention. The
Scrum Master should discontinue use of this chart if it becomes an
Forecasted Tasks Not Tasks In Tasks
PBIs Started Progress Completed impediment to team self-organization.
determine get latest
User login requirements
for password
page layout
(design)
JBoss
running
250
policy

Acceptance Criteria: ....

choose
persistence
write code
using test- exploratory 200
S strategy
(Hibernate?)
driven
development
testing

150
SSL enable analyze get official install
example config certificate
file from I.T. certificate

Acceptance Criteria: .... 100

update
S update
installation
document
deploy
target in
exploratory
testing (3
browsers)
[Link] 50

Reset lost password agree on best

algorithm for
decide code (using
test-driven
randomizing where to
put the link development 0
passwords )
Acceptance Criteria: .... 24-Jul 26-Jul 28-Jul 30-Jul 1-Aug 3-Aug 5-Aug 7-Aug 9-Aug 11-Aug 13-Aug
add
M screenshot
and text to
exploratory
testing
Figure 10: Sprint Burndown Chart
user manual

update manual test

Lock account after code (using migration (try to
test-driven tool to break in
three attempts development) include new with policy

Product / Release Burndown Chart (optional)

row for installed)
Acceptance Criteria: ....

S update
documents

• Tracks the remaining Product Backlog effort from one Sprint to the
Figure 8: Sprint Backlog is best represented with an “information radiator” such as a physical next
taskboard.
• May use relative units such as Story Points for Y axis
• Depicts historical trends to adjust forecasts
Increment Acme Rocket Sled Enhanced Product Burndown
Projected completion in 1 - 5 sprints

• The product capabilities completed during the Sprints

7/5/06

400
7/21/06

• Brought to a usable, releasable state by the end of each Sprint

300
8/14/06

8/29/06

9/14/06

200
Effort units: story points

9/29/06

• Released as often as the Product Owner wishes

10/17/06

100
11/2/06

11/19/06

• Inspected during every Sprint Review

12/4/06

12/18/06

-100
1/1/07

-200

-300

-400

-500

1 2 3 4 5 6 7 8 9 10 11 (12) (13) (14) (15) (16) (17)

Sprint -- Average Velocity: 47.36 story points/sprint

Effort Remaining Backlog w/ unestimated items Velocity Trendline Work Added/Removed Trendline New Baseline

Figure 11: A Release Burndown Chart variation popularized by Mike Cohn.5 The red line tracks
PBIs completed over time (velocity), while the blue line tracks new PBIs added (new scope
discovery). The intersection projects release completion date from empirical trends.

5 Agile Estimation and Planning, Cohn, Addison Wesley (2006)

© Copyright 2010-2020 Michael James and Luke Walter. All rights reserved.
 Multiple Teams Related Practices
Your Organization is Designed to Impede Agility Lean
Introducing Scrum without simplifying the organization's structure and Scrum is a general framework coinciding with the Agile movement in
policies leads to change theater and no real improvement. Large software development, which is partly inspired by Lean manufacturing
organizations are usually just pretending.6 Successful adoptions of approaches such as the Toyota Production System.8
Large Scale Scrum are both top down and bottom up.
eXtreme Programming (XP)
Scrum addresses uncertain requirements and technology risks by
grouping people from multiple disciplines into one team — in one team While Scrum does not prescribe specific engineering practices, Scrum
room — to increase bandwidth, visibility, and trust. Masters are responsible for promoting increased rigor in the definition
of done. Items that are called “done” should stay done. Automated
Adding too many people to a team makes things worse. Grouping regression testing prevents vampire stories that leap out of the grave.
people by specialty also makes things worse. Grouping people by Design, architecture, and infrastructure must emerge over time, subject
architectural components (a.k.a. component teams) makes things to continuous reconsideration and refinement, instead of being
worse. “finalized” at the beginning, when we know nothing.
The Scrum Master can inspire the team to learn engineering practices
associated with XP: Continuous Integration (continuous automated
testing), Test-Driven Development (TDD), constant merciless
refactoring, pair programming, mob programming, frequent check-ins,
etc. Informed application of these practices prevents technical debt.

Running (and Tested) Features

Robust “done”

=Technical
debt
Figure 12: Communication pathways increase as a square of team size.

Feature Teams Weak “done”

Fully cross-functional “feature teams” are able to operate at all layers of

the architecture in order to deliver customer-centric features. In a large Waterfall
system, this requires learning new skills.
Time
As teams focus on learning — rather than short-term micro-efficiencies
— they can help create a learning organization.
Figure 14: The straight green line represents the general goal of Agile methods: early and
Team 1 Team 2 Team 3 sustainable delivery of valuable features. Doing Scrum properly entails learning to satisfy a
rigorous definition of “done” to prevent technical debt.9

User Interface Layer

Business Logic Layer

informal
working
Persistence Layer group

Figure 13: Feature teams learn to span architectural components.

One Product Backlog, One Product Owner

In Large Scale Scrum, multiple teams share a single Product Backlog
prioritized by a single Product Owner. They share the responsibility of
maintaining this backlog. To avoid asynchronous dependencies, they
collaborate across teams in one shared Sprint, using overall and multi-
team versions of the events described in this card, often with team-
appointed representatives.7 As in single-team Scrum, they attempt to
develop one properly tested, integrated, shippable product increment
every Sprint.

6 “Seven Obstacles to Enterprise Agility,” Gantthead, James (2010) [Link]

7 See [Link] to learn about Large Scale Scrum
8 Agile movement defined at [Link]
9 Graph inspired by discussions with Ronald E. Jeffries

© Copyright 2010-2020 Michael James and Luke Walter. All rights reserved.
 Team Self-Organization When is Scrum Appropriate?
Engaged Teams Outperform Manipulated Teams

unknown
During Sprint execution, team members develop an intrinsic interest in

A
shared goals and learn to manage each other to achieve them. The

n
natural human tendency to be accountable to a peer group contradicts

ar
years of habit for workers. Allowing a team to become self-propelled, When the process

Technology

c
is too complex for

h
rather than manipulated through extrinsic punishments and rewards,

y
C
contradicts years of habit for managers.10 The Scrum Master’s the defined

h
approach, the

ao
observation and persuasion skills increase the probability of success,
empirical approach

P
despite the initial discomfort.

ti
re
is the appropriate

c
di
Challenges and Opportunities choice.*

ct
ab
Self-organizing teams can radically outperform larger, traditionally

known
managed teams. Family-sized groups naturally self-organize when the

le
right conditions are met: known unknown
Requirements
• members are committed to clear, short-term goals
• members can gauge the group’s progress It is typical to adopt the defined (theoretical) modeling
approach when the underlying mechanisms by which a
• members can observe each other’s contribution process operates are reasonably well understood.

• members feel safe to give each other unvarnished feedback Figure 15: Scrum, an empirical framework, is appropriate for work with uncertain requirements
and/or uncertain technology issues.1617
Psychologist Bruce Tuckman describes stages of group development as
“forming, storming, norming, performing.”11 Optimal self-organization Scrum is intended for the kinds of work people have found
takes time. The team may perform worse during early iterations than it unmanageable using defined processes — uncertain requirements
would have performed as a traditionally managed working group.12 combined with unpredictable technology implementation risks. When
deciding whether to apply Scrum, as opposed to plan-driven
Heterogeneous teams outperform homogeneous teams at complex approaches such as those described by the PMBOK® Guide, consider
work. They also experience more conflict.13 Disagreements are normal whether the underlying mechanisms are well-understood or whether
and healthy on an engaged team; team performance will be determined the work depends on knowledge creation and collaboration. For
by how well the team handles these conflicts. example, Scrum was not originally intended for repeatable types of
Bad apple theory suggests that a single negative individual production and services.
(“withholding effort from the group, expressing negative affect, or Also consider whether there is sufficient commitment to grow a self-
violating important interpersonal norms”14) can disproportionately organizing team.
reduce the performance of an entire group. Such individuals are rare,
but their impact is magnified by a team’s reluctance to remove them.
This can be partly mitigated by giving teams greater influence over who
joins them. About the Authors
Other individuals who underperform in a boss/worker situation (due to Michael James learned to program many years
being under-challenged or micromanaged) will shine on a Scrum team. ago. He worked directly with Ken Schwaber to
become a Scrum trainer. He coaches technical
Self-organization is hampered by conditions such as geographic
folks, managers, and executives on optimizing
distribution, boss/worker dynamics, part-time team members, and
businesses to deliver value. Please send
interruptions unrelated to Sprint goals. Most teams will benefit from a
feedback to mj@[Link] or
full-time Scrum Master who works hard to mitigate these kinds of
[Link]
impediments.15

Luke Walter learned empirical product

development many years ago as an industrial
designer. He encountered Scrum on a
development team with Michael James, before
they both became Scrum trainers. He coaches
businesses to recognize wasteful practices and
organize around customer value. Please send
feedback to lwalter@[Link].

For help with Agility, please see [Link]

10 Intrinsic motivation is linked to mastery, autonomy, and purpose. “Rewards” harm this [Link]
11 “Developmental Sequence in Small Groups.” Psychological Bulletin, 63 (6): 384-99 Tuckman, referenced repeatedly by Schwaber.
12 The Wisdom of Teams: Creating the High-Performance Organization, Katzenbach, Harper Business (1994)
13 Group Genius: The Creative Power of Collaboration, Sawyer, Basic Books (2007). (This book is #2 on Michael James’s list of recommended reading for Scrum Masters.)
14 “How, when, and why bad apples spoil the barrel: Negative group members and dysfunctional groups.” Research in Organizational Behavior, Volume 27, 181–230, Felps/Mitchell/Byington, (2006)
15 An example detailed list of full-time Scrum Master responsibilities: [Link]
16 Extensively modified version of a graph in Strategic Management and Organizational Dynamics, Stacey (1993), referenced in Agile Software Development with Scrum, Schwaber/Beedle (2001).
17 Process Dynamics, Modeling, and Control, Ogunnaike, Oxford University Press, 1992.

© Copyright 2010-2020 Michael James and Luke Walter. All rights reserved. Version 1.5