Scrum Reference Card

by Michael James and Luke Walter

About Scrum Scrum Team

An Empirical Framework Team
Scrum is a framework for product development using cross-functional • Sometimes called “developers” but intended to be cross-functional,
teams. It emphasizes empirical (real world) feedback and team self e.g. including members with testing skills, designers, domain
management. experts, data scientists, business analysts, etc.
Scrum provides a structure of roles, events, rules, and artifacts. In this • Self-organizing / self-managing, without externally assigned roles.
framework, teams must create and adapt their own ways of working. • Plans one Sprint at a time with the Product Owner, and other teams
if applicable.
Scrum uses fixed-length iterations, called Sprints. Sprints can be no
longer than a month, and preferably a week or two. Teams try to • Owns how to develop the increment.
develop a usable, potentially shippable, properly tested product • Owns both internal collaboration and external collaboration (e.g.
increment every Sprint. An increment that is shippable to its end user working with other teams, clarifying details with end users, etc.).
– not just handed off internally – closes the Sprint’s feedback loop. • More successful when located in one team room, particularly for the
first few Sprints.
An Alternative to Waterfall
• More successful with long-term, full-time membership. Scrum moves
Scrum’s incremental, iterative approach trades the traditional phases of work to a flexible learning team and avoids moving people or
"waterfall" development for the ability to deliver small features first, splitting them between teams.
then to revise plans based on ongoing discovery. • Around six members, give or take a few.
Requirements
Analysis
• No appointed lead. On a healthy team, leadership emerges and shifts
naturally.
Design

Product Owner
Code
• Maximizes the value of the development effort by declaring vision
Integration and priorities.
Test
• Only one per product, even with multiple teams.
• Constantly re-prioritizes the Product Backlog, adjusting any long-
Deploy term expectations such as release plans.
Figure 1: Traditional “waterfall” development depends on a perfect understanding of the product • Final arbiter of requirements questions.
requirements at the outset and minimal errors executing each phase.
• Decides whether to release the product.
• Decides whether to continue developing the product.

Scrum Master
• Works with the organization to make Scrum possible.
• Ensures Scrum is understood and can be 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.
• Serves the team, the Product Owner, and the organization.
• See also https://scrummasterchecklist.org

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

Scrum is for complex work involving knowledge creation and

collaboration such as 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 reality checks expose harmful constraints in individuals,
teams, and organizations. Many people claiming to do Scrum modify
the parts that require breaking through organizational impediments Figure 3: The Scrum Master’s focus shifts over time.
and end up robbing themselves of most of the benefits.

© Copyright 2010-2021 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 con g le

get of cial
certi cate from I.T. install certi cate

Sprint Planning Account lockout

Meeting update deploy

target in build.xml
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 5: 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 team spends 15 minutes
inspecting their Sprint in progress and creating a shared plan for the
Sprint day.
Retrospective
Meeting Standing up at the Daily Scrum helps keep it short. Topics that require
additional attention may be discussed after the event by whomever is
interested.
Teams find it useful to gather around information radiators such as a
physical task-board.
Figure 4: Scrum flow.
During Sprint execution, it is common to discover additional work
Sprint Planning necessary to achieve the Sprint goal.

At the beginning of each Sprint, the Product Owner and team(s) plan The Daily Scrum was intended to disrupt old habits of working
which Product Backlog Items they’ll try to convert to working product separately, but by itself has not proven sufficient. Teams can increase
during the Sprint. The Product Owner declares which items are the collaboration further with techniques such as mob programming.
most important to the business. The development team is responsible During the Sprint, the team strives for a rigorous definition of done. For
for selecting the amount of work they feel they can implement without example, a software item that is merely “code complete” is not done
accruing technical debt. The team selects work from the Product because untested software isn’t shippable. Incomplete items are
Backlog for the Sprint Backlog. returned to the Product Backlog and ranked according to the Product
Declaring a Sprint Goal can increase focus on the big picture. Owner’s revised priorities as candidates for future Sprints.

Software development has inherent uncertainty. Teams can really only Sprint Review
guess how much work to select each Sprint, while learning from
previous Sprints. Traditional habits of trying to plan by hourly capacity The purpose of the Sprint Review is to inspect the Product Increment
can make the team pretend to be precise and reduce ownership of the and adapt plans for it. The participation of customers, end users, and
plan. While relative estimation (e.g. “story points”) may help, it’s often other interested parties provides information the Product Owner may
led to the same problem: the over-certainty that numbers imply, an consider acting on.
example of what Luke Walter calls left brain poisoning. Some teams The Scrum Master may help the Product Owner and stakeholders
produce better Sprint plans by ditching quantitative practices. convert their feedback to new Product Backlog Items for prioritization
Until a team has learned how to complete a shippable product by the Product Owner. New scope discovery usually outpaces the team’s
increment each Sprint, it should reduce the feature scope that it plans, rate of development. If the Product Owner feels that the newly
while increasing emphasis on testing, integration, and source code discovered scope is more important than the original expectations, new
understandability. Failure to change old habits leads to technical debt scope displaces old scope in the Product Backlog. Some items will never
and eventual design death, as shown in Figure 16. be done.

A portion of Sprint Planning may be needed to further refine the New products, particularly software products, are hard to visualize in a
selected items. vacuum. Many customers need to be able to react to a piece of
functioning software to discover what they will actually want. Iterative
In the last part of Sprint Planning, the team forecasts how it will development, a value-driven approach, allows the creation of products
accomplish the work. For example, they may break the selected items that couldn’t have been specified up front in a plan-driven approach.
into an initial list of Sprint Tasks.
Sprint Retrospective
The maximum allotted time (a.k.a. timebox) for planning a 30-day
Sprint is eight hours, reduced proportionally for a shorter Sprint. Each Sprint ends with a retrospective. The team, Product Owner, and
Scrum Master reflect on their own way of working together. They
inspect their behavior and take action to adapt it for future Sprints.
Dedicated Scrum Masters will find alternatives to the stale, fearful
meetings everyone has come to expect. In-depth retrospectives can
happen in an environment of psychological safety difficult to create in

© Copyright 2010-2021 Michael James and Luke Walter. All rights reserved.
fi
fi
fi
fi
fi

 most organizations. Practices such as performance appraisals and the Cut/

job title ladder hamper full trust and teamwork. But without safety the paste
plain Cut/
retrospective discussion may either avoid the uncomfortable issues or text paste
deteriorate into blaming and hostility. rich text
Cut/paste rich
A second impediment to insightful retrospectives is our human text and graphics
database
tendency to jump to conclusions and propose actions too quickly. The schema
book Agile Retrospectives suggests steps to slow this down: Set the
stage, gather data, generate insights, decide what to do, close the
retrospective.1 Another useful book The Art of Focused Conversations Figure 6: During Backlog Refinement, large PBIs (often called “epics”) near the top of the Product
suggests focusing on questions in this order: Objective, Reflective, Backlog are split into thin vertical feature slices (“stories”), not horizontal implementation phases.
Interpretive, and Decisional (ORID).2
A third impediment to psychological safety is geographic distribution.
Dislocated teams rarely bond as well as those in team rooms.
Scrum Masters use a variety of techniques to facilitate retrospectives, Scrum Artifacts
such as silent writing, timelines, and satisfaction histograms. The goals
are to gain a common understanding of multiple perspectives and to
develop actions that will take the team and organization to the next Scrum defines three artifacts: Product Backlog, Sprint Backlog, and
level. Increment.

Large Scale Scrum adds an Overall Retrospective to resolve cross-team Product Backlog
problems, and problems with the organization’s structure and policies.
only one item
User login

Backlog Refinement at a time

is top priority
SSL enable

(Note for test takers: This is not an “event” in single-team Scrum.) top items
are more Reset lost password

Product Backlog Items (PBIs) initially need refinement because they granular
are too large or poorly understood. Teams use some of every Sprint (say Account lockout after

10%) to prepare the top of the Product Backlog for upcoming Sprints.
LDAP integration

In Backlog Refinement, large vague items near the top are split and
clarified, considering both business and technical concerns. Sometimes Register a new login

a subset of the team and others (e,g. customers, end users) will draft
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 7: 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
It is common to think of a Product Backlog Item as a User Story.4 In • Visible to all stakeholders
this approach, oversized PBIs may be called epics.
• Anyone can suggest items
Traditional approaches break features into sequential tasks (resembling • Constantly re-prioritized by the Product Owner
waterfall phases) that cannot be prioritized independently and lack
• Constantly refined by teamwork
business value from the customer’s perspective. This habit is hard to
break. • Items at top should be smaller (e.g., smaller than 1/4 of a Sprint)
than items at bottom
A skilled Scrum Master can help the team identify thin vertical slices of
work that still have business value, while promoting a rigorous Product Backlog Item (PBI)
definition of “done” that includes proper testing and refactoring.
• Describes the what (more than the how) of a customer-centric
Agility requires learning to carve out small product features. For feature
example, in a medical records application, the epic “display the entire
• Often considered a User Story
contents of a patient’s allergy records to a doctor” yielded the story
“display whether or not any allergy records exist.” While the engineers • Has a product-wide definition of done to prevent technical debt
anticipated significant technical challenges in parsing the internal • May have item-specific acceptance criteria
aspects of the allergy records, the presence or absence of any allergy
• Time/effort estimate, if used, is provided by the team, ideally in
was the most important thing the doctors needed to know. relative units (e.g., story points)
Collaboration between business people and technical people to split
this epic yielded a story representing 80% of the business value for 20%
Account lockout after
of the effort of the original epic.
three attempts
Slicing large items shortens the end-to-end cycle time with users,
accelerating the discovery of their real needs. Acceptance Criteria: ....

Small

Figure 8: A PBI represents a customer-centric feature, usually requiring several tasks to achieve
definition of done.

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-2021 Michael James and Luke Walter. All rights reserved.

 Sprint Backlog Sprint Task (optional)

• PBIs selected by the team during Sprint Planning, plus their • Describes how to achieve the PBI’s what
continuously-updated plan to accomplish them (e.g. Sprint Tasks) • Typically involves one day or less of work
• Initial tasks are identified by the team during Sprint Planning • Owned by the team; collaboration is expected
• Team will discover additional work needed to meet the Sprint Goal
during Sprint execution determine
requirements get latest
page layout
• No changes are made during the Sprint that would endanger the for password (design)
JBoss
running
policy
Sprint Goal
• Visible to the team
• Referenced during the Daily Scrum
choose write code
persistence (using test- exploratory
strategy driven testing
Forecasted Tasks Not Tasks In Tasks development
(Hibernate?) )
PBIs Started Progress Completed

determine get latest

User login requirements
for password
page layout
(design)
JBoss
running
policy

Acceptance Criteria: ....

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

Figure 11: Sprint tasks required to complete one backlog item require a mix of activities no longer
SSL enable done in separate phases (e.g., requirements elicitation, analysis, design, implementation,
analyze get official
example config
file
certificate
from I.T.
install
certificate deployment, testing).
Acceptance Criteria: ....

Sprint Burndown Chart (optional)

update
S update
installation
document
deploy
target in
exploratory
testing (3
browsers)
build.xml

Reset lost password agree on best code (using

• Summation of total team work remaining within one Sprint

decide
algorithm for where to test-driven
randomizing put the link development
passwords )
Acceptance Criteria: ....

M
add
screenshot
and text to
user manual
exploratory
testing
• Updated daily
Lock account after code (using
update
migration
manual test
(try to
• May go up before going down
test-driven tool to break in
three attempts
• Intended to help team self-management, not as a report
development) include new with policy
row for installed)
Acceptance Criteria: ....

S
• Fancy variations, such as itemizing by point person or adding trend
update
documents

lines, tend to reduce effectiveness at encouraging collaboration

Figure 9: Sprint Backlog is best represented with an “information radiator” such as a physical
taskboard.
• Seemed like a good idea in the early days of Scrum, but in practice
often misused as a management report, inviting intervention.
Discontinue use of this chart if it reduces team self-management.
(Potentially Shippable Product) Increment
250
• The product capabilities completed during the Sprints.
200
• Brought to a usable, shippable state at least by the end of each Sprint,
or more frequently than that. 150

• Released as often as the Product Owner wishes. 100

• Inspected during every Sprint Review. 50

• Definition of Done is a standard applied to all PBIs from all 0

contributing teams. For example, all new changes should: 24-Jul 26-Jul 28-Jul 30-Jul 1-Aug 3-Aug 5-Aug 7-Aug 9-Aug 11-Aug 13-Aug

Figure 12: Sprint Burndown Chart

• Be properly tested.
• Be fully integrated.
• Be peer reviewed or developed by pair/mob programming. Product / Release Burndown Chart (optional)
• Be documented (when applicable). • Tracks the remaining Product Backlog effort from one Sprint to the
• Maintain or improve source code understandability. next
• X axis is time in Sprints
• May use relative units such as story points for Y axis
Sprint Sprint Sprint Sprint
• Depicts historical trends to adjust forecasts
Acme Rocket Sled Enhanced Product Burndown
Projected completion in 1 - 5 sprints
WIP WIP WIP WIP
7/5/06

400
7/21/06

300
8/14/06

8/29/06

9/14/06

200
Effort units: story points

Stuff we procrastinated:
9/29/06

10/17/06

100
refactoring
11/2/06

11/19/06

load testing 0
12/4/06

12/18/06

security testing -100

1/1/07

user documentation -200

technical debt
integration… -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
Shippable Effort Remaining Backlog w/ unestimated items Velocity Trendline Work Added/Removed Trendline New Baseline
Product?
When? Figure 13: A Release Burndown Chart variation popularized by Mike Cohn. 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.

Figure 10: Un-done work causes risk and delay.

© Copyright 2010-2021 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.5 Successful adoptions of approaches such as the Toyota Production System.7
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 emerge over time, subject to
architectural components (a.k.a. component teams) makes things continuous reconsideration and refinement, instead of being “finalized”
worse. at the beginning, when we know almost 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 14: 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 to end Waterfall
users. In a large 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 16: 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.8

User Interface Layer

Business Logic Layer

informal
working
Persistence Layer group

Figure 15: 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.6 As in single-team Scrum, they attempt to
develop one properly tested, integrated, shippable product increment
every Sprint.

5 “Seven Obstacles to Enterprise Agility,” Gantthead, James (2010) http://scrumreferencecard.com/7-obstacles-to-enterprise-agility/

6 See http://less.works to learn about Large Scale Scrum
7 Agile movement defined at http://agilemanifesto.org
8 Graph inspired by discussions with Ronald E. Jeffries

© Copyright 2010-2021 Michael James and Luke Walter. All rights reserved.

 Team Self-Management 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 many workers. Allowing a team to become self- When the process

Technology

c
is too complex for

h
propelled, rather than manipulated through extrinsic punishments and

y
C
rewards, contradicts years of habit for many managers.9 The Scrum the defined

h
approach, the

ao
Master’s observation and persuasion skills increase the probability of
empirical approach

P
success, 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 17: Scrum, an empirical framework, is appropriate for work with uncertain requirements and
uncertain technology issues.1516
Psychologist Bruce Tuckman describes modes of group development as
“forming, storming, norming, performing.”10 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.11 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.12 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 self-
violating important interpersonal norms”13) can disproportionately organizing teams.
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 [email protected] or
full-time Scrum Master who works hard to mitigate these kinds of
http://twitter.com/michaeldotjames
impediments.14

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 [email protected].

For help with Agility, please see https://seattlescrum.com.

9 Intrinsic motivation is linked to mastery, autonomy, and purpose. “Rewards” harm this http://www.youtube.com/watch?v=u6XAPnuFjJc
10 “Developmental Sequence in Small Groups.” Psychological Bulletin, 63 (6): 384-99 Tuckman, referenced repeatedly by Schwaber.
11 The Wisdom of Teams: Creating the High-Performance Organization, Katzenbach, Harper Business (1994)
12 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.)
13 “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)
14 An example detailed list of full-time Scrum Master responsibilities: http://ScrumMasterChecklist.org
15 Extensively modified version of a graph in Strategic Management and Organizational Dynamics, Stacey (1993), referenced in Agile Software Development with Scrum, Schwaber/Beedle (2001).
16 Process Dynamics, Modeling, and Control, Ogunnaike, Oxford University Press, 1992.

Updated 2021-3-25
© Copyright 2010-2021 Michael James and Luke Walter. All rights reserved.