A brief overview of the Scrum Framework for managing project-based development cycles.

1. Implementing the Scrum Framework
Pictures and outline by Eric Figueroa
Observed at Moving Player, November 2011

2. Scrum Terminology
 Sprint = name for a project (instills a sense of
urgency – it’s a race!)
 Product Owner = one team member who
represents the product’s stakeholders or users
 Scrum Team = team assigned to project
 Scrum Master = handles the administration of
the Sprint (not necessarily a “project leader”)
 Product Backlog = list of all the User Stories
necessary to achieve the Sprint goal
 User Story = product elements written from the
user’s perspective (not tasks!)

3. STEP 1: Sprint Meeting
 Build a new CROSS-FUNCTIONAL Scrum Team
 For each new project, choose a Product Owner
 Meet all together to discuss the project
 During the meeting create the Product Backlog
of User Stories
 Decide on a Sprint length and goal

4. STEP 2: Planning Poker
 Each team member gets a deck of cards and
rates the “Complexity” of each User Story
 The team comes to a consensus on each story’s
complexity
 Complexity, not time, is the basis for the
performance metrics – why?
 Because in developing certain projects (like
software), time often cannot be predicted
accurately

5. Planning Poker Deck
Use a non-linear scale (i.e. Fibonacci sequence)
X = the User Story is impossible
? = I have no clue

6. STEP 3: Daily Scrum
 Daily meeting timeboxed at 15 minutes
 Each team member has:
1 minute to say what they did yesterday,
1 minute to say what they did today
 The Scrum Master can identify problems early,
because Friday is too late
 As a manager you can engage with your
employees, keep them informed about the state
of the business, etc.

7. Daily Scrum

8. STEP 4: Weekly Sprint
Each week the team
selects tasks from the
Product Backlog and
puts them into that
week’s “Cold Room”
Throughout the week
they move from TO DO
to IN PROGRESS to
DONE
This process is repeated
until the Sprint goal is
reached Scrum Board

9. STEP 5: Weekly Release
 Release a beta or demonstrate a project element
to the client or Product Owner EVERY FRIDAY
NO EXCEPTIONS!
 You can’t wait until the end of the project to
know you’re on the wrong track or that your
product doesn’t work
 Clients rarely know what they want, know
everything they want at the beginning, or know
how to articulate it even if they do

10. STEP 6: Retrospective
 At the end of the sprint, meet with the whole
team to discuss what went right and what went
wrong
 Everyone gets a chance to speak
 Agree on ONE major problem to correct for the
next Sprint
 Schedule a new Sprint Meeting for the next
project or product development cycle

11. Accountability, part i
 After the first week of executing Scrum, you will
have the following figures:
 Average Complexity Points each individual can
execute daily
 Average Complexity Points the team as a whole
can execute daily and weekly
 How long it will take the team to complete all
the Sprint’s User Stories based on these figures

12. Accountability, part ii
 In successive weeks, you can compare
individual and team performance with previous
weeks to identify productivity issues in REAL-
TIME
 Compare the Sprint deadline with the expected
completion date based on your team’s actual
performance
 You can use Excel templates to graph all this
data visually and keep track of User Stories
 Post them all next to the Scrum Board

13. Results
 Most teams begin to report drastic
improvement within 3 months
 There IS quite a lot of ritual but it can provide
the necessary structure
 Easy to start, difficult to master
 This is just the beginning . . .