Scrum Basics

Scrum Basics
June 22, 2010

John Chapman
© Andover Design 2007 - 2010

Agenda
• Scrum Overview
• Scrum Framework
• Agile Requirements

Scrum Overview
• Who uses Scrum and what do they use it
for?
• A brief history of Scrum
• Empirical process control
• Traditional vs Scrum development
• Scrum in a nut shell

Agile Scrum has been used by:
• EMC • Intuit
• Microsoft
• Yahoo • Nielsen Media
• Google • First American Real Estate
• Electronic Arts • BMC Software
• Lockheed Martin
• Philips • Ipswitch
• Siemens • John Deere
• Nokia
• Salesforce.com
• IBM
• Capital One • National Public Radio
• BBC • Turner Broadcasting

Agile Scrum has been used for:
• Commercial software • Video game development
• In-house development • FDA-approved, life-critical
• Contract development systems
• Fixed-price projects • Satellite-control software
• Financial applications • Websites
• ISO 9001-certified applications • Handheld software
• Embedded systems • Mobile phones
• 24x7 systems with 99.999% • Network switching applications
uptime requirements • ISV applications
• the Joint Strike Fighter • Some of the largest
applications in use

A brief history of Scrum
1986 The New New Product Development Game, by Takeuchi and
Nonaka. Harvard Business Review
1990 Wicked Problems, Righteous Solutions: A Catalog of Modern
Engineering Paradigms, by DeGrace and Stahl
1993 Scrum developed and used at Advanced Development Methods
(Schwaber) and Easel Corp (Sutherland)
1995 Paper on Scrum at OOPSLA ’95 in Austin, TX, by Sutherland and
Schwaber
1999 First XP book, Extreme Programming Explained, Kent Beck
2001 Agile Manifesto, including Schwaber, Sutherland and Beedle
2001 First Scrum book, Agile Software Development with Scrum,
Schwaber and Beedle
2002 Scrum Alliance founded by Schwaber, Cohn, and Derby

What is Scrum? A brief history of Scrum
Defined vs Empirical Process Control
• Defined process control is used in manufacturing

to repeatedly produce acceptable quality output
• Phased “waterfall” development attempts to
apply defined process control to software
development
• Complex systems require empirical process
control
• Empirical process relies on visibility,
inspection, and adaption

Agile Project Management with Scrum, Ken Schwaber (2004)
Traditional vs Scrum Development
Requirements Design Code Test
Rather than doing all of one

thing at a time...
...Scrum teams do a little of
everything all the time
© Andover Design 2007 - 2010 The New New Product Development Game, by Takeuchi and Nonaka.
Harvard Business Review, January 1986
Moving from Traditional to Agile Scrum
Project man
We can plan
Coaching Agile Teams, Lyssa Adkins (2010)
Moving from Traditional to Agile Scrum
Project man
Scope can b
Coaching Agile Teams, Lyssa Adkins (2010)
Scrum in a nut shell
“Scrum is an agile software development
framework.”
• It allows us to focus on delivering the highest business
value in the shortest time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize to
determine the best way to deliver the highest priority
features.
• Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint.

scrumalliance.org
Agile Scrum
Values
Principles
Agile
Framework
Scrum
XP
Practices

Scrum Framework
• Values
• Essence
• Flow
• Roles
• Ceremonies
• Artifacts
• Rules

Scrum Values
• Commitment
– Be willing to commit to a goal. Scrum provides people all the authority
they need to meet their commitments.
• Focus
– Do your job. Focus all your efforts and skills on doing the work that
you've committed to doing. Don't worry about anything else.
• Openness
– Scrum keeps everything about a project visible to everyone.
• Respect
– Individuals are shaped by their background and their experiences. It is
important to respect the different people who comprise a team.
• Courage
– Have the courage to commit, to act, to be open, and to expect respect.

Agile Software Development with Scrum, Ken Schwaber and Mike Beedle (2002)
The Essence of Scrum
• Give the team clear goals
• Let the team self-organize around the work
• The team works at as sustainable pace
• The team regularly delivers the most valuable features
• The team receives feedback from people outside the team
• The team regularly reflects on ways to improve
• Stakeholders have tangible visibility into the team’s
progress
• The team and management honestly communicate about
progress and risks

Scrum Flow

Scrum Framework
Roles
• Product Owner
• ScrumMaster
• Team Time-Boxes
• Sprint planning
• Sprint
• Daily scrum
• Sprint review
• Sprint retrospective Artifacts
• Product backlog
• Sprint backlog
• Burndown charts
Scrum Framework
Roles
• Product Owner
• ScrumMaster
• Team Time-Boxes
• Sprint planning
• Sprint
• Daily scrum
• Sprint review
• Product backlog
• Sprint backlog
• Burndown charts
Roles - NASCAR

Product Owner Role
• Provide product vision
• Define the features of the product
– As items in the Product Backlog
• Decide on the boundaries
– Release date, responsiveness, cost, etc.
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to business value
• Adjust features and priority every Sprint
• Collaborate with team during development
• Accept or reject work results

ScrumMaster
• Responsible for the Scrum process
• Ensure that the Scrum Team understands the Scrum
values, practices, and rules
• Teach the Scrum Team by coaching and by leading it to
be more productive and produce higher quality products
• Help the Scrum Team understand and use self-
organization and cross-functionality
• Work with the management to remove impediments for
the Scrum Team

Agile Project Management with Scrum, Ken Schwaber (2004)
ScrumMaster
• Responsible for making sure that all of the
pieces of the Scrum framework come together
and work as a whole.
• Act as the sheepdog for the Team
– Responsible for keeping the flock heading in the
same direction and keeping the wolves away

The Team
• Turn Product Backlog items into increments of potentially
shippable functionality every Sprint
• Self-organizing
– Authority to find how to meet the Spring goal within the guidelines,
standards, and conventions of the organization and Scrum
• 7 members plus or minus 2
• Cross-functional
– Team members must have all of the skills necessary
to complete the selected Product Backlog items
• Most members should be full-time
– May be exceptions (e.g., database administrator, systems architect)
• Membership should stay as constant as possible
– Change can lead to temporary loss of productivity

Scrum Framework
Roles
• Product Owner
• ScrumMaster
• Team Time-Boxes
• Sprint planning
• Sprint
• Daily scrum
• Sprint review
• Product backlog
• Sprint backlog
• Burndown charts
Sprint Planning
What?
Product • Analyze and select Product Sprint
Backlog
Backlog items Goal
Team • Select Sprint goal
Capabilities
Business
Conditions
How?
Technology
• Design the work
Stability • Identify the tasks required to turn
each Product Backlog item into Sprint
Current an increment of working product Backlog
Product
• Estimate Sprint Backlog in hours
• Tasks should be 1 day or less

What is a Sprint?
• Scrum projects make progress in a series of “Sprints”
• Contain and consist of the Sprint Planning meeting, the development
work, the Sprint Review, and the Sprint Retrospective
• Occur one after another, with no time between Sprints.
• Sprints can be cancelled before the Sprint time-box is over
– Only the Product Owner has the authority to cancel the Sprint, although
he or she may do so under influence from the stakeholders, the Team, or
the ScrumMaster
• Typical duration is 2 - 4 weeks; a calendar month at most
• A constant duration leads to a better rhythm
• Product is designed, coded, and tested during the Sprint
• Ideally, selected work does not change during a Sprint

Daily Scrum
• 15 minute daily stand-up meeting to inspect and adapt
• Each member quickly summarizes
– What did I get done since the last stand-up?
– What will I do before the next stand-up?
– What are the impediments blocking me or slowing me
down?
• Not for problem solving
• Only the team can speak

Why meet face-to-face?
“Scrum meetings do much more than just
capturing information. They don’t only make
everyone capture what they did, but it makes
everyone say in front of everybody else. That way
everyone listens to what others are doing and
they can offer to help them later.
It also makes everyone promise in front of
everyone else what you will be working on next,
so it puts everyone’s credibility and trust to the
test. Scrum is about deep social interactions that
build trust among team members.”

Agile Software Development with Scrum, Ken Schwaber and Mike Beedle (2002)
Sprint Review
• Team presents what it accomplished during the sprint
– …and not done
• Typically takes the form of a demo of new features or
underlying architecture
• Informal collaboration
• 2-hour prep time rule
• No slides shows
• Whole team participates
• Invite stakeholders and management
• 4-hour time-box for one month Sprints

Sprint Retrospective
• ScrumMaster encourages the Scrum Team to revise, within the
Scrum process framework and practices, its development process to
make it more effective and enjoyable for the next Sprint
• Inspect how the last Sprint went in regards to people, relationships,
process and tools
• Identify actionable improvement measures for the Team to
implement in the next Sprint
• Whole team participates
– ScrumMaster
– Product Owner
– Team
– Possibly stakeholders
• 3-hour time-box for one month sprints

Product Backlog Grooming
• Teams need to allocate 5-10% of their time
during the Sprint to preparing for the next Sprint
or two
• Improves productivity by smoothing out the flow
of work
• One 2-hour meeting per week suggested
• Chaired by the Product Owner and attended by
the full Scrum Team, and possibly, stakeholders

Scrum Framework
Roles
• Product Owner
• ScrumMaster
• Team Time-Boxes
• Sprint planning
• Sprint
• Daily scrum
• Sprint review
• Product backlog
• Sprint backlog
• Burndown charts
Product Backlog
• The requirements
• A list of all desired work on the
project
• Ideally expressed such that each
item has value to the users or
customers of the product
• Usually written as user stories
• Estimated by the Team
• Prioritized by the Product Owner
• Reprioritized at the start of each
Sprint
Product
Backlog
Example Product Backlog
Item #
Scop
Must Have
CHR-101 Creat
Sprint Backlog
• If work is unclear during Sprint
Planning, define a Sprint Backlog
item with a larger amount of time
and break it down later
• Individuals sign up for work of their
own choosing
• Focus on completing stories
• Estimated work remaining is
updated daily
• Any team member can add, delete
or change the Sprint Backlog
• Work for the Sprint emerges
Sprint • Update work remaining as more
becomes known
Backlog
Sample Sprint Backlog
Story ID
10 Fetch one day
Make our serve
Release Burndown Chart
The Release Burndown
200
chart records the sum of
remaining Product
150 Backlog estimated effort
Story Points
across Sprints.
100
50
0 1 2 3 4 5 6 7 8
Sprint
Sprint Burndown Chart
The Sprint Burndown
400
chart records the sum of
remaining Task
300 estimated effort across
days in the Sprint.
Hours
200
150
1 2 3 4 5 6 7 8 9 10

Day
Impediment Backlog
• A prioritized list of impediments
– Things that are preventing the team from progressing
or improving
• Updated at Sprint Retrospectives
• Managed by ScrumMaster
• May include things that the Team can do
themselves, or things that require action by the
organization

Scrum Rules
• A Sprint Planning Meeting is held at the start of each Sprint
• Each Sprint must deliver working and fully tested code that demonstrates
something of value to end-users or the customer
• The Product Owner prioritizes the Product Backlog
• The Team collectively selects the amount of work brought into the sprint
• Once a Sprint begins, only the Team may add to the Sprint Backlog
• The Product Backlog may be added to or reprioritized at any time
• A short Daily Scrum is held every day and each team member states what
has been done since the last meeting, what will be done, and any
obstacles in the way; only team members my speak
• The result of a Sprint is demonstrated at a Sprint Review; max 2 hr
preparation, no slides
• A Sprint Retrospective is held at the end of each Sprint

Agile Requirements
• DEEP Product Backlog
• Emergent Requirements
• Imperfect Schedules
• User Stories
• Acceptance Criteria
• Process Flow of User Stories

DEEP Product Backlog
• D Detailed Appropriately
• Higher-priority items are described in more detail than lower-priority ones.
• E Estimated
• The estimates are coarse-grained and often expressed in Story Points. Knowing
the size of the items helps prioritize them and plan the release.
• E Emergent
• The Product Backlog has an organic quality. It evolves, and its contents change
frequently. New items emerge based on customer and user feedback, and they
are added to the Product Backlog. Existing items are modified, reprioritized,
refined, or removed on an ongoing basis.
• P Prioritized
• Forced ranking of all User Stories. The most important and highest-priority items
are at the top of the Product Backlog and implemented first.

Making the Product Backlog DEEP
Emergent Requirements
• It is impossible to know all requirements in advance
• “Thinking harder” and “thinking longer” can uncover some
requirements, but…
Every project has some emergent requirements
 Emergent requirements are those that users cannot identify in advance

So what do we do?
• We talk more, write less
– But write some if you need to
• Show software to users
• Acknowledge that requirements emerge
• Progressively refine our understanding of the
product
– And express this progressive refinement in the
product backlog

Imperfect Schedules
• We can’t perfectly predict a software schedule
– As users see the software, they come up with
new ideas
– Too many intangibles
– Developers can’t perfectly predict time to
complete tasks
• If we can’t perfectly predict a schedule, we can’t
perfectly say what will be delivered.

So what do we do?
We make decisions
based on the information …but we do it often
we have
Rather than make one …we spread decision-

all-encompassing set of making across the project
decisions
This is where user stories come in…

What is a user story?
A user story is a short, simple description

of a feature told from the perspective
of the person who desires the new capability,
usually a user or customer of the system.

Succeeding with Agile, Software Development Using Scrum – Mike Cohn
User Story Template
“As a <type of user>,

I want <some goal>
so that <some reason>.”

Succeeding with Agile, Software Development Using Scrum, by Mike Cohn
Sample User Story
As a user, I want to cancel a

reservation so that I don’t
have to pay for a room I
won’t use

Conditions of Acceptance
As a user, I want to cancel a
reservation so that I don’t
have to pay for a room I will
not use
• Written by the product owner (or delegate) prior to sprint planning

• “I’ll know this is done when”
• These are essentially high-level test descriptions
I’ll know this is done when:

- Premium member can cancel the
same day without a fee
- Non-premium member is charged
10% for same day cancellation
- Hotel is notified of any cancellation
- Registered members receive a
cancellation confirmation email
Important!
The story text we write on
the cards is less
important than the
conversations that we
have.

"People always know more than
they can tell, and can tell more
than they can write."
- David J Snowden, knowledge management expert

How do we develop a Product Backlog?
• Develop user roles

• Determine goals for each role
• Write user stories to document actions to fulfill
goals
• Estimate the size of the effort for each story
• Force rank the user stories
• Estimate what stories will go in each Sprint until
the next release

Process Flow of User Stories
New Preparing Ready Sprint Done
• Qualified by • Work-in- • Target 2x • Only Ready • Designed,

PO Progress Team items Coded,
• Prioritized • Max 5 Velocity brought into Tested, etc.
backlog • User story Sprint • Meets
items at a with • Convert to Definition of
time acceptance potentially Done
• PO leads criteria shippable • Accepted
effort, • Meets product by PO
supported Definition of increment
by Team Ready

Story Flow
Don’t let anything into
your sprint that is not
Ready and don’t let
anything escape your
Sprint that’s not Done.
Sprint
Ready
Done
Product
Backlog Completed
Features
Features (User Stories)

Questions?

Additional Resources
• Being an Effective Product Owner – Roman Pichlar (2007)
• Product Owner Anti Patterns – Monica Yap (2010)
– Common anti patterns & why they made your project fail
• Kicking Scrumbut – Rowan Bunning (2009)
– ScrumButs are reasons why you can’t take full advantage of Scrum to solve the problems and
realize the benefits
• Scrum Guide – Ken Schwaber, Jeff Sutherland (2007)
– High level overview of Scrum from two of the founders
• The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process – Ken Schwaber, Jeff
Sutherland (2007)
• Definition of Done (DoD) – Dhaval Panchal
• Self-Organization: The Secret Sauce for Improving your Scrum team – Jeff Southerland
(2008)

Scrum Tools
• VersionOne www.versionone.net
– Team Edition’s simple spreadsheet- and whiteboard-style user interfaces help you
centralize all of your current documents, emails, defects, and spreadsheets in a single,
web-based tool built from the ground up to support agile development.
• Axosoft OnTime www.axosoft.com/ontime
– Comprehensive Agile Scrum project tracking software. Winner of numerous industry
awards. Customizable workflow.
• Banana Scrum www.bananascrum.com
– Banana Scrum is a very simple Scrum tool. Designed to help your team keep track of
things, but never meant to replace your daily human interactions. A tool to know where
you are, but not so complex as to blur the picture.
• XPlanner www.xplanner.org
– XPlanner is a project planning and tracking tool for eXtreme Programming (XP) teams.
• SeeNowDo www.seenowdo.com
– Simple and free online task board.

Recommended Reading

Click book to view details
Copyright
• Overview information adapted under
Creative Commons license from materials
provided by Mountain Goat Software, LLC
– For more information see
http://creativecommons.org/licenses/by/3.0/
• Other sources acknowledged on individual
pages

Scrum Basics

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Scrum Basics

Uploaded by

Copyright:

Available Formats

Scrum Basics

June 22, 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

• Defined process control is used in manufacturing

© Andover Design 2007 - 2010

Rather than doing all of one

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

Every project has some emergent requirements

 Emergent requirements are those that users cannot identify in advance

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

Rather than make one …we spread decision-

This is where user stories come in…

A user story is a short, simple description

© Andover Design 2007 - 2010

“As a <type of user>,

© Andover Design 2007 - 2010

As a user, I want to cancel a

© Andover Design 2007 - 2010

• Written by the product owner (or delegate) prior to sprint planning

I’ll know this is done when:

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

• Develop user roles

© Andover Design 2007 - 2010

New Preparing Ready Sprint Done

• Qualified by • Work-in- • Target 2x • Only Ready • Designed,

© Andover Design 2007 - 2010

Features (User Stories)

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010

© Andover Design 2007 - 2010