SCRUM

SCRUM
WITH ACKNOWLEDGEMENT TO MIKE COHN FROM MOUNTAIN GOAT
SOFTWARE, LLC
We’re losing the relay race
“The… ‘relay race’ approach to product
development…may conflict with the goals of
maximum speed and flexibility. Instead a
holistic or ‘rugby’ approach—where a team
tries to go the distance as a unit, passing the
ball back and forth—may better serve today’s
competitive requirements.”
Hirotaka Takeuchi and Ikujiro Nonaka, “
The New New Product Development Game”,
Harvard Business Review, January 1986.
Scrum in 100 words

• Scrum is an agile process that 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.
Scrum origins
• Jeff Sutherland
• Initial scrums at Easel Corp in 1993
• Ken Schwaber
• Scrum presented at OOPSLA 95 with
Sutherland
• Mike Beedle
• Scrum patterns in PLOPD4
• Ken Schwaber and Mike Cohn
• Co-founded Scrum Alliance in 2002
SCRUM has been used

 Microsoft  Embedded systems

 Yahoo  24x7 systems
 Google  Video games
 EA  FDA approved systems
 Siemens  Websites
 Nokia  Mobile phones
 Intuit  Network switching
 Saleforce.com  Joint Strike Fighter
Characteristics
Self-organizing teams
Product progresses in a series of month-long
“sprints”
Requirements captured in “product backlog”
No specific engineering practices prescribed
Uses generative rules to create an agile environment
for delivering projects
Project noise level
Far from
Agreement

Anarchy

Requirements
Complex
Co
mp
li
ca
te Source: Strategic Management and
Organizational Dynamics by Ralph Stacey
d in Agile Software Development with

Simple
Scrum by Ken Schwaber and Mike Beedle.
Close to
Agreement
Technology
Close to
Certainty

Far from
Certainty
Mountain Goat Software, LLC
The Process

© www.mountaingoatsoftware.com/scrum
Sprints

 Scrum projects make progress in a series of “sprints”

 Typical duration is 2–4 weeks or a calendar month at most
 A constant duration leads to a better rhythm
 Product is designed, coded, and tested during the sprint
Sequential vs. overlapping 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

Source: “The New New Product Development Game” by Takeuchi

and Nonaka. Harvard Business Review, January 1986.
Unified (Software Development) Process
Iterationswithin phases
4 phases and core workflows for each
Inception Elaboration Construction Transition

Requirements

Analysis

Design

Implementation

Test
No changes during a sprint

Change

Plan sprint durations around how long you can commit

to keeping change out of the sprint
 Scrum framework
Roles
•Product owner
•ScrumMaster
•Team Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts
Product owner

 Define the features of the product

 Decide on release date and content
 Be responsible for the profitability of the product (ROI)
 Prioritize features according to market value
 Adjust features and priority every iteration, as needed
 Accept or reject work results
The ScrumMaster

• Represents management to the project

• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
The team
Typically5-9 people
Cross-functional:
Programmers, testers, user experience designers, …
 Members should be full-time
May be exceptions (e.g., database administrator )
• Teams are self-organizing
• Membership should change only between sprints
Team
Sprint planning meeting
capacity
Sprint prioritization
Product • Analyze and evaluate product Sprint
backlog backlog goal
• Select sprint goal

Business
conditions Sprint planning
• Decide how to achieve sprint goal
Current (design)
Sprint
product • Create sprint backlog (tasks) from backlog
product backlog items (user
stories / features)
Technology • Estimate sprint backlog in hours
Sprint planning
 Team selects items from product backlog they can commit to
 Sprint backlog is created
 Tasks are identified and each is estimated (1-16 hours)
 Collaboratively, not done alone by the ScrumMaster
 High-level design is considered

As a vacation Code the middle tier (8 hours)

Code the user interface (4)
planner, I want to Write test fixtures (4)
see photos of the Code the foo class (6)
hotels. Update performance tests (4)
The daily scrum
Daily
15-minutes
Stand-up

 Not for problem solving

 Whole world is invited
 Only team members, Scrum Master, product owner talk
 Helps avoid other unnecessary meetings
Everyone answers 3 questions
1
What did you do yesterday?

2
What will you do today?

3
Is anything in your way?

not status for the ScrumMaster

commitments in front of peers
A sample product backlog
Backlog item Estimate
Allow a guest to make a reservation 3

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a

3
reservation.
As a hotel employee, I can run RevPAR
8
reports (revenue-per-available-room)
Improve exception handling 8
... 30
... 50
Tasks Mon Tues Wed Thur Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 7
Test the middle tier 8 16 16 11 8
Write online help 12

50
40
30
20
10
Hours

0
Mon Tue Wed Thu Fri
Scaling through the Scrum of scrums