Core Scrum

Sam Hwang
Sep 2009
Course agenda
Today
• Overview of Agile and Scrum
• Roles on a Scrum Team
• Product Backlog
• Sprint Planning
• Sprint Tracking
• Rules of Scrum
• Stand-up
• Sprint Review
• Sprint Retrospective
Outline 1 of 2
• Overview
• Defined vs Adaptive Process
• Origins of Agile
• Scrum Process Diagram
• Scrum Team Roles
• Product Backlog
• Sprint Planning Meeting
• Sprint Tracking
Outline 2 of 2
• Sprint Planning Meeting Simulation
• Sprint Rules!
• Potentially Shippable
• Done (Again)
• Changes / Termination
• Sprint Length

• Stand-up
• Dysfunctional Standup Exercise
• Sprint Review
• Sprint Retrospective
A defined process

A defined
process

• Every task must be completely understood.When

given a well-defined set of inputs, the same outputs are
generated every time.
Is software development a defined
process?

• Is every task completely understood?

• Given the exact same inputs (including
people)
Will we get the same results every time?
Can we even have the exact same inputs?
Adaptive process control
• Useful when
Process cannot be sufficiently described to
ensure repeatability
• Embrace Change
• Inspect and Adapt
An Iterative Process
Design
Bui
ld
Test

v2.0 v2.1 Innovate v2.3 v2.4

What is Agile?
Origins
• Scrum
• “The New New Product Development Game,” HBR, 1986.
• Schwaber, Beedle, Sutherland on Scrum starting in 1995.

• Extreme Programming
• Kent Beck, Ward Cunningham, Ron Jeffries, 1999

• Others
• Lean
• Feature-Driven Development
The Agile Manifesto
• February 2001
• 17 advocates of “lightweight methodologies”
got together to see what they had in common
• Result was a manifesto of four value
statements
The Agile Manifesto
Individuals
Individuals and
and over Process
Process and
and tools
tools
interactions
interactions

Comprehensive
Comprehensive
Working
Working software
software over
documentation
documentation

Customer
Customer over Contract
Contract negotiation
negotiation
collaboration
collaboration

Responding
Responding to
to change
change over Following
Following aa plan
plan
Agile
Adapt
Embrace change. Give up on
“managing” and “controlling” it
Get Feedback
Show work early and often,
make it visible and get constant
customer involvement
Deliver Value
Work on highest value and
riskiest features first. Release
frequently. Reduce waste.
Collaborate
Whole team thinking, owning
and solving problems with the
customer.
Communicate
Big visible charts, information
radiators, daily meetings.
Regular planning sessions.
…Continuously
Short timeboxed iterations.
This is NOT Agile
• Compress the schedule
• No documentation
• Hack code
• No design or planning
The organization may gain short term
speed at the cost of long term gain.
Course agenda
Today
• Overview of Agile and Scrum
• Roles on a Scrum Team
• Product Backlog
• Sprint Planning
• Sprint Tracking
• Rules of Scrum
• Stand-up
• Sprint Review
• Sprint Retrospective
The Scrum Process
The Scrum Team

Scrum Master

Product Owner

The Stakeholders
Product Owner
• Product visionary

• Maximizes business value

• Prioritizes and clarifies requirements

• Plan Deliver
• Prioritize Value
• Collaborate
Product Owner
• Defines the features of the product, decides
on release date and content
• Is responsible for the profitability of the
product (ROI)
• Prioritizes features according to market
value
• Can change features and priority in the
product backlog
• Accepts or rejects work results
• Communicates with the business
Scrum Master

• Serves the team

• Tracks progress
• Guards the Scrum process
Scrum Master
• Ensures that the team is fully
functional and productive
• Enables close cooperation across all
roles and functions and removes
barriers
• Shields the team from external
interferences
• Ensures that the process is followed.
Participates in daily scrum, sprint
review and planning meetings
The Team Meet Daily

Work

Sprint
Tasks Produce product
increment
The Team

• Cross-functional
• Self-Organizing
Stakeholders

• Prioritize Review
• Collaborate
• Serve
Course agenda
Today
• Overview of Agile and Scrum
• Roles on a Scrum Team
• Product Backlog
• Sprint Planning
• Sprint Tracking
• Rules of Scrum
• Stand-up
• Sprint Review
• Sprint Retrospective
Product backlog

A prioritized list of requirements

• Items of highest value at

the top
• Prioritized by the
product owner
This
This is
product
is the
the
product backlog
backlog • Estimated by the team
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 reports
8
(revenue-per-available-room)
Improve exception handling 8
Bug #4334 – Improve error handling with… 1
Investigate PayPal integration 9
Common product backlog
estimating units

Ideal Time

Calendar Time
Ideal Time -or- Calendar Time
Ideal time
• The amount of time something is likely to take one
person if they aren’t disrupted or distracted
• If two people will work on it, their time is added
• Often expressed in days (including ½ day, etc.)

Calendar Time
• Just old-fashioned guessing at the hours or days
something will take
Estimating the Product Backlog
• Use coarse-grained estimates for the
Product Backlog
• Think: “Days” or “Weeks”
Course agenda
Today
• Overview of Agile and Scrum
• Roles on a Scrum Team
• Product Backlog
• Sprint Planning
• Sprint Tracking
• Rules of Scrum
• Stand-up
• Sprint Review
• Sprint Retrospective
The Scrum Process

Sprint Planning Meeting Sprint Review/

Sprint Retrospective
Sprint Planning

Team takes a subset of the product backlog

and commits to delivering it for the sprint.
Sprint Planning
Objective
In Sprint Planning, the Team determines a list of features to be
developed in the current sprint.

Victory Conditions
They’ve defined a clear goals for the sprint
They’ve come up with a task-driven plan for achieving it
They can make a commitment to completing that plan

Sprint Planning

Description Equipment Players Rules: 1 Rules: 2

Sprint Planning

Equipment

1.5 to 2 sprint's worth of Product Backlog

Post-it notes / Whiteboard

Sprint Planning

Description Equipment Players Rules: 1 Rules: 2

Sprint Planning
Players
Team Members
Product Owner

Sprint Planning

Description Equipment Players Rules: 1 Rules: 2

Sprint Planning
Rules
• Determine the
team’s initial
capacity
• Get velocity using
yesterday’s weather
• Multiply by the
number of days in
the sprint
• Adjust for known
contingencies

Sprint Planning

Description Equipment Players Rules: 1 Rules: 2

Sprint Planning

Name Base Less Vacations, Holidays, Etc Total

Hours
Anne 3 hours 1 day 27 hours
Rita 3 hours 1 day 27 hours
Michael 3 hours 3 day 21 hours
Eduardo 3 hours 1 day 27 hours

Based on Yesterday’s Weather

Sprint Planning

Description Equipment Players Rules: 1 Rules: 2

Sprint Planning
Rules
• Select an item from the product backlog and
discuss
• Break down into tasks to complete the item
• Estimate amount of work for each task
• If team has capacity left, proceed with next
item; otherwise, stop – sprint planning is done

Sprint Planning

Description Equipment Players Rules: 1 Rules: 2

Sprint Planning
Rules
• Players volunteer for task
• Volunteer estimates task
• Estimate is subtracted from their bandwidth
• Don’t know enough to estimate? Spike
• Estimates are in hours, typically 2-4 hour tasks

Sprint Planning

Description Equipment Players Rules: 1 Rules: 2

Sprint Tasks: Yahoo! Example
Sprint Planning: Done
Definition of “DONE” helps clarify goal
• Mockups, schemas to review
• Usability results
• Fully tested and staged code
Sprint Planning Values and
Insights
• Volunteering
• “Done”
• Yesterday’s Weather
• Improved predictability

• Humane work

• Team Commitment => taking a stance

• Who is involved / who is the team
• Declaring personal availability before accepting work so that you don’t feel like a bad-
guy when you turn down work
• Self-empowerment
• Team alignment
• Time boxing
• Fixed : resource and time

• Estimate: Requirement/Value
Course agenda
Today
• Overview of Agile and Scrum
• Roles on a Scrum Team
• Product Backlog
• Sprint Planning
• Sprint Tracking
• Rules of Scrum
• Stand-up
• Sprint Review
• Sprint Retrospective
1,000

800

600

400
Tracking Progress
200

0
4/29

5/13
Tracking Progress
Description
In Task Tracking, the Builders provide incremental
information about their progress, which is then
converted into a global picture of how well the team
is progressing.
Victory Conditions:
They know whether or not they can fulfill their sprint
commitments
A sprint burndown chart
Hours
Course agenda
Today
• Overview of Agile and Scrum
• Roles on a Scrum Team
• Product Backlog
• Sprint Planning
• Sprint Tracking
• Rules of Scrum
• Stand-up
• Sprint Review
• Sprint Retrospective
Sprints
Sprints

During the sprint:

• Analysis
• Design
• Code
• Test
This
This is
is the
the
sprint
sprint
Always deliver
• Always deliver a potentially shippable
product increment at the end of each sprint
• Do not miss the end of the sprint
The deadline is sacred
Potentially shippable product
increment

• High quality
• Tested
• “Done”
Potentially shippable ≠ shippable
The scope of “done”
Planning
!
Planning Extend the scope of
Analysis
Analysis “Done” as far as possible
Design
Design
Coding
Coding
Testing
Testing
Performance
Performance
User
User Acceptance
Acceptance
Pilot
Pilot
Live
Live
 Defining “Done”
Pair with someone you don’t know.
Turn to each other and share short
answers to the following for 5 minutes:
1
What does ““Done”
Done” mean in your current project?

2
What issues do you see with this definition of done?
How would you address them?

3
What engineering problems do you see with this
approach?
How would you rectify them?
Sequential vs. overlapping
development

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.
Queuing theory

Cycle Time as a Function of Utilization and Batch Size*

45

40
Large Batches
Cycle Time (hours)

35
Medium Batches
30 Small Batches

25

20

15

10

0
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Queuing Theory 101

*This assumes batch size is proportional to variability.
Little’s Law
• The long-term average number of customers in
a stable system N, is equal to the long-term
average arrival rate, λ, multiplied by the long-
term average time a customer spends in the
system, T
N=λT
• In other words:
Total Cycle Time = Number of Things in Process
Average Completion Rate
Exercise 1
• Make teams of 5 people
• 4 will operate
• 1 will measure (using chronometer)
• Put 20 cards face up in front of you
• Start the chronometer
• Move all cards to your neighbor and flip down all of the
20 cards (one by one)
• When the 20 cards are moved, your neighbor move all
cards to his neighbor and flip up all the cards
• Do it again … till the last member of the team
• Stop the chronometer
Exercise 2
• Make teams of 5 people
• 4 will operate
• 1 will measure (using chronometer)
• Put 20 cards face up in front of you
• Start the chronometer
• Move 1 card to your neighbor and flip down this card
• When 1 card is available for your neighbor, he takes it
and moves it to its neighbor and flip up this card
• Do it again … till the last member of the team and the
last card
• Stop the chronometer
Discussion
• Compare the 2 results (duration)
• What is the fastest organization
• Could you explain why?
• Don’t forget to use mathematics ☺
Large Batch generates long period of waiting

Average completion rate is similar (time to flip 4

times a card) but the number of things in process is
reduced
Deliver Fast
• Now, you know how to deliver fast
• Reduce Number of things in the Process
• Use SCRUM approach (short iterations)

• Reduce size of requirements

• Use MMF approach (see next section)
Reciprocal commitments

The business commits to leave

priorities alone during the sprint
No changes during a sprint
• What the team commits to—and what the
product owner agrees to—during sprint
planning should be what is delivered

However, keep in mind that...

• We start with vague requirements. Our
understanding of those requirements is
refined during the sprint.
Abnormal Terminations

• If change cannot be kept out of a sprint...

The sprint may be abnormally terminated
• An extreme circumstance, not done very often
• Raises visibility of priority changes
 Average time to implementation

A change that is …gets planned into this

identified here… sprint…

Week 1 Week 2 Week 3 Week 4

Sprint 1 Sprint 2

…and delivered here.

Average change is delivered 1½

The Lesson sprints after being discovered.

Reproduced with kind permission by

Mike Cohn mountaingoatsoftware.com
Sprint length
• Most common lengths:
• 2-weeks, 4-weeks
Factors to consider…
•How long the business can go without changing its mind
•Pick a length that spreads intensity appropriately
•Ability to reliably predict effort on tasks four weeks out
•Length of the overall release
•Amount of uncertainty on the project
•The overhead of iterating
Sprint Length
• Keep the same sprint length for all your sprints.
• Don’t change length arbitrarily from one sprint to
another
• Be sure to run sprints back to back.
• Always end the sprint on time
These Policies

• Promote regularity
• Establish a heartbeat
Intensity varies over time
Waterfall
Intensity

Scrum

Months
Sprints
1 Is there such a thing as an ““analysis
analysis sprint
sprint”” where
requirements are pulled together?

2 Is there such a thing as a ““testing

testing sprint”?
sprint”?

3 If a project requires a lot of infrastructure and

architecture work that will take eight weeks to
complete, should the first sprint be eight weeks long?
Is the architecture an adequate deliverable?
Release Sprints
• Always target a potentially-shippable
product increment
• But, some polishing can occur in a release
sprint
Some stress, performance or usability testing
Compliance
Documentation touchups (final screen shots)
A Sprint Warning

Don’t let work slop over from

sprint to sprint and build up
 50
100
150
200
250
300
350

0
Monday

Tuesday

Wednesday

Thursday

Friday

Monday

Tuesday

Wednesday

Thursday
Will this sprint finish on time?

Friday
Course agenda
Today
• Overview of Agile and Scrum
• Roles on a Scrum Team
• Product Backlog
• Sprint Planning
• Sprint Tracking
• Rules of Scrum
• Stand-up
• Sprint Review
• Sprint Retrospective
Stand-Up
Stand-Up
The stand-up is..
• A 15 minute meeting
• A forum for team members to
answer
• What I did
• What I plan to do today
• What is blocking me
Why Stand-ups?
• Understand what is in play
• Increase Collaboration

Good Stand-ups:
• Allows for efficient collaboration
• Demonstrate respect
Sprint Review
Course agenda
Today
• Overview of Agile and Scrum
• Roles on a Scrum Team
• Product Backlog
• Sprint Planning
• Sprint Tracking
• Rules of Scrum
• Stand-up
• Sprint Review
• Sprint Retrospective
Sprint Review

Description
In the Sprint Review, the team demos the completed
features (and other products of the sprint) to all
interested parties.
Victory Conditions
• Everyone understands where the product is and
what it can do at this point in time
• Valuable feedback is acquired from Stakeholders
• Everyone has fun
Sprint Review

Equipment
• A functional product that was finished at the end of
the sprint
• Demonstrable on a staging server
• Other work artifacts to demonstrate
Sprint Review

Players
• The Whole Team
• Developers, Testers, UED, etc
• Product Owner
• Any Stakeholder who is interested
Sprint Review

Rules
• Hold a 30 minute informal presentation
• Limit the prep time to 2 hours total
• Be careful not to do additional work just
for the review!
Course agenda
Today
• Overview of Agile and Scrum
• Roles on a Scrum Team
• Product Backlog
• Sprint Planning
• Sprint Tracking
• Rules of Scrum
• Stand-up
• Sprint Review
• Sprint Retrospective
Sprint Retrospective
Sprint Retrospective
Description
In the Sprint Retrospective, the Team takes
stock of what did and didn’t work during the
last sprint, and comes up with strategies to
improve their processes and development
methods.
Victory Conditions
Inspect & Adapt
Sprint Retrospective
Players
• Team Members
• Builders
• Product Owner

• No Other Stakeholders!
Sprint Retrospective
Rules
• Typically 30-60 minutes
• Done after every sprint
Sprint Retrospective
• Whole team gathers to discuss:

Progress

What ’s working
What’s

Improvements
Sprint Retrospective
Start
• Showing the software to customers early
• Specifying acceptance tests early and with
customers
• Doing code inspections
• Getting FitNesse into the nightly builds
• Trying to finish one story before moving to the
next
Stop
• Being disrespectful of QA
Continue
• Making progress with the canonical database
• Emphasizing test automation
Thank You!