Intro To Scrum Slides 2.0

Introduction to Scrum
Pete Deemer
CPO, Yahoo! India R&D
The Origins of Scrum
Pete Deemer
Defined Processes
Inputα Outputα
Inputβ Defined Process Outputβ
Inputγ Outputγ
Assuming every step is understood, a

given well-defined set of inputs produces
the same set of outputs every time.
Predictability is key.
The Waterfall
Job Function A Job Function B Job Function C Job Function D Job Function E
Requirements
Gathering
Design
Documentation, Development
Signoffs, Handoff
Documentation, Testing
Signoffs, Handoff
Launch &
Documentation,
Signoffs, Handoff Maintain
Documentation,
Advantage: Highly Logical Signoffs, Handoff
Disadvantage: People are involved

Empirical Processes
“It is typical to adopt the defined (theoretical) modeling approach when the
underlying mechanisms by which a process operates are reasonably well
understood. When the process is too complicated for the defined approach,
the empirical approach is the appropriate choice.”
Process Dynamics, Modeling, and Control,
Ogunnaike and Ray, Oxford University Press, 1992
Translation into English: Inspect and Adapt
Inputα Outputβ
Process
Inspect & Adapt

Iterative Incremental Development
Iterative Development
Project is structured as multiple short cycles in
sequence, versus one long cycle
Incremental Development
Each iteration produces a usable increment of
finished product, with actual customer value
The Emergence of Scrum
Scrum formalized in 1996 by Ken Schwaber

“The Origins of Scrum”, OOPSLA 1996
Now in use at a growing list of big companies:

Google Yahoo!
Sun SAP
Siemens HP
Nokia Motorola
Philips TransUnion
BBC BT / British Telecom
IBM CapitalOne
What Is Scrum Being Used For?
US FDA-approved software for X-Rays, MRIs

High availability systems (99.9999% uptime)
Financial payment applications
Large database applications
Embedded systems
CMMi organizations
Multi-location development
Non-software projects
Scrum at Yahoo!
4 pilot teams migrated to Scrum in early 2005

Since then, >200 Yahoo! projects (>2000 people) around
the globe have migrated to Scrum
Consumer-facing projects
Major infrastructure projects
Distributed Projects
New Products
Maintenance Products
Policy is 100% voluntary adoption
Teams hear about or observe the experiences of other teams using
Scrum and decide to learn more
Scrum Disadvantages
It’s hard!
Makes all dysfunction visible
Scrum doesn’t fix anything: the team has to do it
Feels like things are worse at the beginning
Bad products will be delivered sooner, and doomed
projects will fail faster
Some teams and organizations are not right or ready for it
Team willingness, capabilities
Management buy-in
Risk of turnover during adoption
Some people will refuse to stay on a Scrum team
Some people will refuse to stay if Scrum is abandoned
Partial adoption may be worse than none at all
If adoption fails, time will have been wasted, and some
people may leave
Scrum Basics
Pete Deemer
The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
Product Owner The Team
1 1
2 2
3 3 Commitment
4 4
5 Potentially
6
7 No Changes Shippable
8
9 (in Duration or Deliverable) Product
10
11
12
13
Retrospective
The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Retrospective
Product Owner
Responsible for the overall project vision and goals

Responsible for managing project ROI vs. risk
Responsible for taking all inputs into what the
team should produce, and turning it into a
prioritized list (the Product Backlog)
Participates actively in Sprint Planning and Sprint
Review meetings, and is available to team
throughout the Sprint
Determines release plan and communicates it to
upper management and the customer
The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Retrospective
Team
7 people, + or – 2
Has worked with as high as 15, as few as 3
Can be shared with other teams (but better when not)
Can change between Sprints (but better when they don’t)
Can be distributed (but better when colocated)
Cross-functional
Possesses all the skills necessary to produce an increment
of potentially shippable product
Team takes on tasks based on skills, not just official “role”
Self-managing
Team manages itself to achieve the Sprint commitment
The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Retrospective
The Role of the ScrumMaster
The ScrumMaster does everything in

their power to help the team achieve
success
This includes:
Serving the team
Protecting the team
Guiding the team’s use of Scrum
What the ScrumMaster Does
Serves the team
The ScrumMaster takes action to help remove impediments to the
team’s effectiveness
The ScrumMaster facilitates the team’s group interactions, to help
the team achieve its full potential
The ScrumMaster coaches the team, to help them improve their
practices and effectiveness
Protects the team
The ScrumMaster protects the team from anything that threatens its
effectiveness, such as outside interference or disruption
The ScrumMaster will need to confront uncomfortable issues, both
inside and outside the team
Guiding the team’s use of Scrum
The ScrumMaster teaches Scrum to the team and organization
The ScrumMaster ensures that all standard Scrum rules and practices
are followed
The ScrumMaster organizes all Scrum-related practices
What Does the ScrumMaster NOT Do?
The ScrumMaster does not manage the team

The ScrumMaster does not direct team-
members
The ScrumMaster does not assign tasks
The ScrumMaster does not “drive the team” to
hit its goals
The ScrumMaster does not make decisions for
the team
The ScrumMaster does not overrule team-
members
The ScrumMaster does not direct product
strategy, decide technical issues, etc.
What Happens to the “Manager” in Scrum?
Manager
The Team
What Happens to the “Manager” in Scrum?
?
Scrum Daily Scrum
Master Meeting
Manager
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Retrospective
The New Role of the Manager
4 Possibilities
ScrumMaster
Possible issues?
Product Owner
Possible issues?
Team Member
Possible issues?
“Manager 2.0”
Manager 2.0
Step 1 – Create list of everything the

Manager used to be responsible for (come
up with as many items as possible, at least
10 items)
Step 2 – Cross off this list everything that:
Conflicts with Scrum
Is unnecessary in Scrum
Would undermine the team's self-organization
and self-management
Decide task assignments among the team Provide coaching and mentorship to team-
members and assign them members
Keep track of whether team-members have Surface issues to the team that they might
done the tasks I’ve assigned to them overlook – scaling, performance, security, etc.
Make commitments on behalf of the team Provide input on features, functionality, and
about how much they can get done by X date other aspects of what’s being produced
Give direction to the team on how to do the Do performance evaluations and provide
work, so they can meet the commitment I made feedback to team-members
Convince team that the commitments made on Provide advice and input to the team on
their behalf are attainable difficult technical issues that come up
Plan training for team, and do career-

Monitor the team's progress, to make sure they
development and planning with team-
stay on schedule, and aren't having problems
members
Conduct weekly update and 1:1 meetings with Stay abreast of latest developments in the
team, to surface issues, and provide direction technology their team uses, industry news, etc.
Recruit, interview and hire new members of the Plan and oversee budgets and financials, and
team think about tools, skills and other future needs
Fire team-members who are consistently not Help remove impediments that the team is not
able to perform able or well-placed to resolve themselves
Manager 2.0
Step 3 – Help the manager turn this into a

new job description
Step 4 – Get sign-off / agreement from the
manager’s manager
The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Product Backlog Retrospective

Product Backlog
Product Owner lists

items in descending
order of priority (highest
priority item is listed
first, next-highest is
second, etc.)
Size estimates are rough

estimates (can either be
arbitrary “points”, or
“ideal days”)
Product Backlog
List of everything that could ever be of value to
the business for the team to produce
Ranked in order of priority
Priority is a function of business value versus risk
Product Owner can make any changes they want
before the start of a Sprint Planning Meeting
Items added, changed, removed, reordered
How much documentation is up to the team and
Product Owner to decide
The farther down the list, the bigger and less
defined the items become
~2 Sprints worth are defined in detail
User Stories
User Stories are a good approach for

writing Product Backlog Items
User Stories are a short, plain-language
description of the functionality, in terms of
the customer benefit and need
Good Format
“As a customer, I can place an item
As a… on my wishlist, so that I can
decide later whether or not I want
I want… to buy it”
“As a frequent flyer member, I can
see the number of miles I have
So that… earned in my frequent flyer
account, so that I can decide
whether to redeem them for a
ticket”
“As a new user, I can set up a
profile so that potential
employers can find out more
about my skills and qualifications”
The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Product Backlog Retrospective

Sprint Planning Meeting
Takes place before the start of every Sprint
Team decides how much Product Backlog it will commit
to complete by the end of the Sprint, and comes up with
a plan and list of tasks for how to achieve it
What’s a good commitment?
Clearly understood by all
Shared among the team
Achievable without sacrificing quality
Achievable without sacrificing sustainable pace
Attended by Team, Product Owner, ScrumMaster,
Stakeholders
May require 1-2 hours for each week of Sprint duration
2 week Sprint = 2-4 hours, 4 week Sprint = 4-8 hours
Sprint Planning
Team understands the
details of what the Product
Owner has prioritized on
the Product Backlog
Team decides how
much productive
time it has available
during the Sprint
Team decides how
many Product Backlog
items it can commit
to complete during
the Sprint
Sprint Planning
Team understands the Sprint
details of what the Product Pre-Planning
Meeting
the Product Backlog
Team decides how
much productive
during the Sprint Sprint
Team decides how Planning
many Product Backlog Meeting
items it can commit
to complete during
the Sprint
Sprint Cycle: 2-Week Sprint
Mon Tues Weds Thurs Fri
1 2 3
6 Sprint 7 8 9 10
Planning
Meeting
1 2 3 4
13 14 15 16 17
5 6 7 8 Sprint Review
& Retrospective
20 21 22 23 24
27 28 29 30 31
Sprint Cycle: 4-Week Sprint
Mon Tues Weds Thurs Fri
1 2 3
6 Sprint 7 8 9 10
Planning
Meeting
1 2 3 4
13 14 15 16 17
5 6 7 8 9
20 21 22 23 24
10 11 12 13 14
27 28 29 30 31
15 16 17 18 Sprint Review
& Retrospective
Available Time During Sprint
Sprint Length 2 weeks
Workdays During Sprint 8 days
Avail Days Avail Hours Total Avail Hrs

Team Member
During Sprint* Per Day in Sprint
Tracy 8 4 32 (8 * 4)
Sanjay 7 5 35 (7 * 5)
Phillip 8 3 24 (8 * 3)
Jing 5 5 25 (5 * 5)
*Net of holidays and other

days out of the office
Hours Per Day
time available for productive work
“8-Hour Day”
hacking, reading blogs, playing foosball

lunch and tea breaks
meetings, e-mail
Hours Per Day
“8-Hour Day”
operational responsibilities
meetings, e-mail
Hours Per Day
operational responsibilities
“8-Hour Day”

meetings, e-mail
Hours Per Day
“8-Hour Day” time committed to another team

meetings, e-mail

Team Member
Tracy 8 4 32 (8 * 4)
Sanjay 7 5 35 (7 * 5)
Phillip 8 3 24 (8 * 3)
Jing 5 5 25 (5 * 5)

Another Approach: Quarter Days
1/4 Day
1/4 Day
“1 Day”
1/4 Day
1/4 Day
Available Time in ¼ Days
Avail Days Total Avail ¼

Team Member
During Sprint* Days in Sprint
Tracy 8 32 (8 * 4)
Sanjay 7 28 (7 * 4)
Phillip 8 32 (8 * 4)
Jing 5 20 (5 * 4)

Sprint Planning
Team understands the Sprint
details of what the Product Pre-Planning
Meeting
the Product Backlog
Team decides how
much productive
during the Sprint Sprint
Team decides how Planning
many Product Backlog Meeting
items it can commit
to complete during
the Sprint
Product Backlog
Getting to “Done”
Backlog
Task Owner Estimate
Item
Design business logic Sanjay 4
Design user interface Jing 2
Set up shopping cart module Tracy 2
Enable all
users to place Implement back-end code Tracy 6
book in Implement front-end code Joe 8
shopping cart
Unit testing Philip 4
Regression testing Philip 2
Documentation Tom 3
Upgrade
transaction
processing
module
Getting To “Done”
DESIGN CODE TEST
SPRINT
DESIGN CODE TEST
SPRINT SPRINT SPRINT

DESIGN
CODE
TEST
DESIGN CODE TEST
SPRINT
Creating the Sprint Backlog
Backlog
Task Owner Estimate
Item
Set up shopping cart module Tracy 2
Enable all
users to place Implement back-end code Tracy 6
book in Implement front-end code Joe 8
shopping cart
Documentation Tom 3
Upgrade
transaction
processing
module

Team Member
Tracy 8 4 32 28 25
Sanjay 7 5 35 31
Phillip 8 3 24
Jing 5 5 25

Sprint Planning Ends when…
Team’s available time is mostly committed

Good idea to go through and make sure
there’s full agreement on the commitment
After the meeting, ScrumMaster turns the
task list into the Sprint Backlog
The Sprint Backlog
Day of Sprint
Backlog Initial
Task Owner 1 2 3 4 5 6
Item Est.
Implement back-end
Tracy 2
Enable all code
users to place Implement front-end
Tracy 6
book in code
shopping cart Complete
Joe 8
documentation
Implement back-end
Tracy 5
Upgrade code
transaction Complete
Joe 6
processing documentation
module Unit testing Philip 3
Total 214
And the Sprint Begins!
Pete Deemer
The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Retrospective
Intensity
Intensity
Waterfall
Scrum
Time
The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Retrospective
No Changes During Sprint
No Changes to the Deliverable

Once team has committed, no changes to the
deliverable
If something major comes up, Product Owner
can terminate the Sprint and start new one
Details and clarifications will emerge during
Sprint, but no new work or substantially
changed work
Difference between “change” and
“clarification”
“If there’s any doubt, then it’s a change”
Impact of Change
What happens if the Product Owner gets to add just a small
amount of work, or swap work in & out during the Sprint?
Current Sprint Every Future Sprint

Product PO’s Team’s
Near-term Team’s ability Team’s focus Team’s focus Other teams’
Owner’s discipline in discipline in
Priorities of to deliver on delivering on delivering discipline in
discipline to preparing the following the
Product what it what it what it following the
not request Product other rules of
Owner committed to committed to committed to rules of Scrum
changes Backlog Scrum
What if the Team is Responsible for
“Emergency Response”?
What is “Emergency Response”?

Critical operational issues
P1 (critical) Bugs in a live system
2 approaches that some teams use
“Designated Responder”
“Emergency Response Buffer”
Not Scrum standard!
Proceed at your own risk
Option 1: Designated Responder
“Scrum Work” “Critical Issues”

(items from the (emergency requests
Product Backlog that need to be
that the team has responded to
committed to do) immediately)
Option 1: Designated Responder
Scrum Team D.R.

“Product Backlog Work” “Critical Issues”
(items from the Product (emergency requests
Backlog that the team has that need to be
committed to do) responded to quickly)
Commits in this Sprint to Commits to fix Critical Issues.

complete items 1-13 on May work on items from lower
the Product Backlog on Backlog (items >13)
Option 2: Emergency Response Buffer
“Scrum Work” “Critical Issues”

(items from the (emergency requests
Product Backlog that need to be
that the team has responded to
committed to do) immediately)
productive time available
“8-Hour Day”
meetings, email, lunch, etc.

time available to commit to the Sprint
“8-Hour Day” Emergency Response Buffer
meetings, email, lunch, etc.

To make this work, 3 things are required

Clear definition of what qualifies as a “Emergency
Response” request (these are the only things that team
will work on)
Time spent from ER Buffer must be tracked – when
buffer gets to 0, work on bugs has to stop, or Sprint has
to be terminated
Team must have the discipline to follow first two points
Risks
Becomes a back door for change during the Sprint
Buffer overrun
The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Retrospective
Daily Scrum Meeting
Purpose of Daily Scrum Meeting
Keep team coordinated and up-to-date with each other
Surface impediments daily
How it works
Every weekday
Whole team attends
Team chooses a time that works for everyone
Product Owner can attend, but doesn’t speak
Everyone stands in a circle, facing each other (not facing the SM)
Lasts 15 minutes or less
Everyone reports 3 things only to each other
What was I able to accomplish since last meeting
What will I try to accomplish by next meeting
What are my blocks / problems / difficulties
No discussion or conversation until meeting ends
Table Exercise: Daily Scrum Meeting
Do a Daily Scrum Meeting for your table

One person plays the role of ScrumMaster
The rest of the table are team-members
Each team-member reports to the group:
What I was able to get done since last Daily Standup
Meeting
What I will try to get done by the next Daily Standup
Meeting
What is blocking me? (If nothing, say “No Blocks”)
Follow the instructions on the slips
Updating the Sprint Backlog
After the Daily Scrum, team members

update the hours remaining on the Sprint
Backlog
Updating the Sprint Backlog
Day of Sprint
Backlog Initial
Task Owner 1 2 3 4 5 6
Item Est.
Design business logic Sanjay 4 2 0
Design user interface Jing 2 2 2
Implement back-end
Tracy 2 4 2
Enable all code
users to place Implement front-end
Tracy 6 6 6
book in code
shopping cart Complete
Joe 8 6 6
documentation
Unit testing Philip 4 3 3
Regression testing Philip 2 2 2
Implement back-end
Tracy 5 10 8
Upgrade code
transaction Complete
Joe 6 6 6
processing documentation
module Unit testing Philip 3 3 3
Regression testing Philip 3 2 2
Total 214 210 180

Burndown Chart
Task Board
TO DO IN PROGRESS DONE
Task Board
Task: Configure database

and SpaceIDs for Trac
Owner: Sanjay
Task Board
Task: Configure database Task: Configure database Task: Configure database Task: Configure database
and SpaceIDs for Trac and SpaceIDs for Trac and SpaceIDs for Trac and SpaceIDs for Trac
Owner: Sanjay Owner: Sanjay Owner: Sanjay Owner: Sanjay

Time Remaining: Time Remaining: Time Remaining: Time Remaining:
4 hrs 4 hrs 4 hrs 4 hrs
Task: Configure database Task: Configure database Task: Configure database

and SpaceIDs for Trac and SpaceIDs for Trac and SpaceIDs for Trac
Owner: Sanjay Owner:` Sanjay Owner: Sanjay

Time Remaining: Time Remaining: Time Remaining:
4 hrs 4 hrs 4 hrs
Owner: Sanjay Owner:` Sanjay Owner: Sanjay Owner: Sanjay


Owner: Sanjay Owner: Sanjay Owner: Sanjay

4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs

Task Board



4 hrs 4 hrs 4 hrs



4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs

Task Board



4 hrs 4 hrs 4 hrs



4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs

Task Board



4 hrs 4 hrs 4 hrs
Owner: Sanjay Owner: Sanjay Owner: Sanjay Owner:` Sanjay



4 hrs 4 hrs 4 hrs



Owner: Sanjay Owner: Sanjay Owner:` Sanjay

4 hrs 4 hrs 4 hrs
Owner: Sanjay Owner: Sanjay Owner:` Sanjay Owner: Sanjay

Task Board



4 hrs 4 hrs 4 hrs



4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs

Task Board



4 hrs 4 hrs 4 hrs



4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs

The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Retrospective
Sprint Review
Purpose of the Sprint Review
Demo what the team has built
Make visible whether the team completed what they set out to
Generate feedback, which the Product Owner can incorporate in
the Product Backlog
Attended by Team, Product Owner, ScrumMaster,
functional managers, and any other stakeholders
A demo of what’s been built, not a presentation about
what’s been built
no Powerpoints allowed!
Usually lasts 1-2 hours
Followed by Sprint Retrospective
The Basics of Scrum
Scrum Daily Scrum

Master Meeting
4-Week
Sprint
Review
1
2
3 Commitment
4
5 Potentially
6
8
10
11
12
13
Retrospective
Sprint Retrospective
What is it?
1-2 hour meeting following each Sprint Demo
Attended by Product Owner, Team, ScrumMaster
Usually a neutral person will be invited in to facilitate
What’s working and what could work better
Why does the Retrospective matter?
Accelerates visibility
Accelerates action to improve
Sprint Retrospective – A Good Approach
Part 1
Create 3 large lists (whiteboard or flipchart)
What’s working
What’s could work better
Things to try in the next Sprint
Go around the room, and give each person an
opportunity to add 1 or more items to the 3 lists
If people agree with something already on the lists, put
a tick mark next to them
Select a subset of the “Things to try...” list to try in the
next Sprint (ScrumMaster responsible for tracking this)
WHAT WORKED WHAT DIDN’T WORK
Team felt more focused than before on We didn’t finish what we committed to in the
hitting its goals time available
Sense of commitment for the team was Our estimations were way off
higher We didn’t think through the dependencies
Team had a better sense of where it was in between tasks
the Sprint because of the burndown chart The coordination between developers and
The Daily Scrum Meeting improved Team testers wasn’t very good
communication during the Sprint Our daily Scrum meeting didn’t start on time
Good idea came out during the Sprint Review The food in the cafeteria was really bad
There were a lot of outside distractions
during the Sprint
Blocks didn’t get removed quickly enough by
the ScrumMaster
There were too many bugs yet to be fixed at
the end of the Sprint
Team didn’t really work together as a team –
still felt like a group of individuals
Planning Poker
Getting Started
1. Everyone creates cards with following
values on them: ?, ½, 1, 2, 3, 5, 8, 13, 20, 50
(WRITE LARGE USING MARKER!)
2. Team agrees on a backlog item to use as a
“baseline” or “benchmark”, and gives it a
size of “5” (item should be neither biggest
nor smallest on list)
3. Size = Effort x Complexity x Uncertainty
Planning Poker
For each Product Backlog item:
1. Each person decides their size estimate relative
to the items that have already been estimated,
and privately selects a card
2. Everyone shows their cards at the same time
(ScrumMaster says “1-2-3-Show”)
3. If estimates vary significantly, high and low
estimators briefly explain
4. Repeat steps 3-5 until estimates stop
converging
5. Decide estimate for backlog item
6. Move to next backlog item
The Release Cycle in Scrum
Pete Deemer
Scrum Release Cycle
2 Common Approaches:
Multi-Sprint Release
RELEASE
SPRINT SPRINT SPRINT SPRINT SPRINT SPRINT
Release Every Sprint

RELEASE RELEASE RELEASE RELEASE RELEASE RELEASE
SPRINT SPRINT SPRINT SPRINT SPRINT SPRINT

Multi-Sprint Release – One Approach
RELEASE
“S P R I N T 0” SPRINT SPRINT SPRINT SPRINT PRE-RELEASE

SPRINT
HIGH-LEVEL DESIGN FINAL STABILIZATION,

& ARCHITECTURE, TESTING, RELEASE
INVESTIGATION, PREPARATION
SETUP OF DEV EL
ENVIRONMENT
Multi-Sprint Release – One Approach
RELEASE
“S P R I N T 0” SPRINT SPRINT SPRINT SPRINT
HIGH-LEVEL DESIGN
& ARCHITECTURE,
INVESTIGATION,
SETUP OF DEV EL
ENVIRONMENT
Release Planning and
Estimation in Scrum
Pete Deemer
Estimation and Release Planning
You can continue to use your existing estimation
methods, if they’re working for you
Scrum will almost certainly allow you to get the same
or more done in a given timeframe
However, there are Scrum-specific methods that
many teams find more effective that their
previous approaches
Estimation in Scrum is based on what’s called
Velocity
Velocity is measure of how much Product Backlog the
team can complete in a given amount of time
Product Backlog
Velocity – Based on Historical Data
Team’s Recent Sprints
90 points
120 points
100 points
~105 size points per Sprint

How to Plan a Release in Scrum
Calculate velocity then apply to the Product Backlog:
Team’s velocity is
~105 points per This is 620
Sprint points of
Product
Therefore, in 6 Backlog
Sprints, the team
should be able to
complete 6 x 105
= 630 points worth of
Product Backlog
Velocity Calculation
SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 SPRINT 5
Initial Estimate
Of Velocity at Refinement
Project Start of Estimate Recalculation
based on based on Recalculation
1 Sprint of 2 Sprints of based on Recalculation
Actual Data Actual Data 3 Sprints of based on
Actual Data 4 Sprints of
Actual Data
Release Planning
Product Owner determines whether

It’s a feature-driven release (“launch when features
X, Y, Z can be completed”)
It’s a date-driven release (“launch on April 15 with as
many features as possible”)
It’s date- and feature-driven (“launch on April 15
with features X, Y, Z”)
Using Scrum for Multi-Location
Development
Distributed Scrum Practices
Structure A: Product Owner is in US, team is

in India
One Common Approach
ScrumMaster located with team in India
2-week Sprints
Team holds daily standup meetings in own
location
ScrumMaster emails blocks list to Product Owner for
assistance clearing in US
Sprint Planning
Team has 1 hour real-time meeting with Product Owner to
discuss goals of Sprint, broad review of Product Backlog Items
(example: Weds night IST)
Team spends 1-3 hours doing preliminary analysis and
breakdown of Product Backlog Items (example: Thurs
afternoon IST)
Team spends 1-3 hours real-time with Product Owner
completing analysis and breakdown of Product Backlog Items,
and makes commitment (example: Thurs night IST)
Sprint begins (example: Fri morning IST)
Sprint Review and Retrospective
Videoconference + Webex (example Weds morning IST)
Product Owner in US travels to India for project kickoff
All real-time meetings with Product Owner are visual
Videoconference + Webex
Use a webcam if you have to
Mailing list for Product Owner and all team members,
with most project-related emails cc:ed to this list
Verbose subject lines to emails
At least 1 weekly 1-hour real-time check-in between
Product Owner and team
In-person planning and review regroup in India or US
between Product Owner and team at least once per
quarter
Distributed Team
Stucture B: Team split between two locations
For example, 3 developers, 1 tester, and 1 analyst in US, 5
developers and 1 tester in India
2 ScrumMasters, one in each location
Lighter load than a full ScrumMaster – may be a team-member
2 separate daily standup meetings
Notes from each team’s standup emailed to the other
and read at the beginning of the meeting
(this is in addition to all the previous recommendations)
Scaling Scrum
Scaling Scrum
Team A Team B Team C Team D Team E

Scaling Scrum
Product Owner

Scaling Scrum
Senior Product Owner
PO PO PO PO PO

During the Sprint
Scrum of Scrums
Daily / 2-3 times per week
Coordination, Dependencies Mgt, Block Surfacing

Module: Using Scrum in a Fixed
Bid Environment
Contract Terms
the party in the first part shall remunerate the party in

3.1.1 Vendor will demo potentially shippable software to
Customer every 30 days. There will be no
additional charge for this.
3.1.2 Customer can replace any requirements that Vendor
hasn’t yet started working on with one or more of
equal total size (in the estimate of Vendor) at any
time. There will be no additional charge for this.
3.1.3 Customer may request interim releases at any time,
and will be charged an agreed-upon time and
materials cost.
3.1.4 If Customer’s business goals are satisfied early,
Customer may terminate contract early for 20% of
the remaining unbilled contracted amount.
notwitstanding the foregoing clause, the party in the first
Module: Scrum and Metrics
Scrum and Metrics
Scrum doesn’t prevent you from tracking or
measuring any aspect of the development
process you choose
However, you must be mindful of
unintended consequences of measurement
Example: Individual burndown charts
Recording or reporting measurements will
probably require effort
If this effort comes from team-members, it
should be made visible in their task time
estimates or as Backlog Items
Strategies for Successful
Scrum Adoption in
the Enterprise
The Big Picture
The full and complete adoption of Scrum will
result in a profound transformation of an entire
organization
Very few organizations are willing to change
Change is risky
Change hurts
Change requires work
Change involves loss and waste
Very few organizations are able to successfully
pull it off
1. Start With the Teams That Want To Do It
Scatter the seeds of Scrum widely, then watch

closely where they sprout
One of the requirements for first pilots should be
“everyone on the team had to be open to it
working”
Skepticism is fine and healthy, but no overt
resistance
2. Call It a Pilot Program
Pilots are supposed to be chaotic,

uncertain, bumpy, messy
Keep calling it a “pilot” as long as possible
People will ask “when’s the decision going
to get made to officially adopt Scrum”
Wait to make that decision until there are no
more teams lining up to make the change
Then ask yourself what is it about the
remaining teams?
3. Change is Scary to Many People... and
Scrum is Really Scary to Some People
Some people will be uncomfortable, unhappy, scared

And is it unexpected? How many management fads have
preceded Scrum?
Emphasize the common sense nature of it
We’re not “making a change”… we’re trying a new approach, and
deciding whether it’s better than the old way
Ken Schwaber: “We’re not really using scrum”
Some of those people will get past it, some of them won’t
Just 4 months in, some of the biggest early Scrum skeptics
had evolved into the greatest Scrum evangelists
Give people the room to change
Avoid battle-lines
4. Patience is a Virtue
Err on the side of making fewer teams more successful

Every team will hit some big bump kicking off scrum
Many will need some support, if only moral
In the early days, there are many more evangelists for
failure than for success
Even the undecided will assume that an early failure is a
strike against scrum
Overbudget the time early teams will need to work
through systemic issues
5. Find the Middle Path Philosophically
Scrum Purists
Tend to be the initial instigators
They also tend to be the first to feel anxiety as Scrum
stops being a guerrilla campaign, and becomes how
the army is run
Scrum Pragmatists
Tend to be more effective in big organizations
Also more prone that the purist to compromise,
possibly at the expense of effectiveness
Don’t let either of them win outright
Make sure you have both!
6. Set a High Bar and Low Expectations for
Teams that Want to Use Scrum
It’s very easy when evangelizing scrum to set

unrealistic expectations
potential benefit
work required
People know when they’re being sold
People also pick up on respectful realism
tell them it’s hard, tell them it involves risk, and
emphasize that only they in their hearts know if it
might be right for their team
7. Scrum is Hard
Scrum surfaces all sorts of nasty stuff

Make sure people are prepared
Make sure they understand that this is Scrum
working, not failing
Help teams learn from each other
Be ready to stage a rescue mission
There are some problems teams can’t solve by
themselves
8. Get Experienced Help
Outside experts can help with specific practices,

training, etc.
Don’t overlook perhaps their greatest help in the early
days: telling you they’ve seen this a million times
before, and it’s all going to be fine
And at the same time, making sure you don’t overlook
and slack off on something important
9. Your Enemy is Your Friend
Spend the most time with the people who like

Scrum least
Before you have momentum, Scrum detractors can
have more impact the Scrum proponents
Get close to the detractors, and make them part of the
team
Who knows, some of them might actually have
something valid to contribute
10. Be Prepared to Use Guerilla Tactics to Get
Things Done
Some of the obstacles to Scrum are big

Organizational, policy, management...
Many are small
conference room table
Focus on the big ones
11. Make Good Information More Accessible
than Bad Information
As a Scrum rollout picks up momentum, the

rumor mill becomes more of a factor
Good rumors as well as bad
“You have to release every month”
“You get to release every month!”
Make sure there’s a constant flow of good
information
Email updates, brown-bag lunches, staff meeting talks
Start building a fun list of the top N greatest myths
about Scrum
12. Find Your Evangelists
Build a network that includes every group of the

company, and every level
Make sure they’re well educated on reality, and
also able to be candid, with you and others
you want them able to bring you the nuggets of
information or news asap
Very helpful to have a senior executive advocate
with a single statement they can set the default
management attitude to scrum
beware getting them TOO excited though
13. Measure the Results Early and Often
Scrum is in part about making things visible

So measure the results and experiences from a
bunch of different angles
Publicize both the good and bad
14. The Urge to Tinker is Great
Everyone has a way to improve Scrum

Important to set standards and adhere to them
If it isn’t scrum, don’t let people call it Scrum
Protect Scrum’s good name!
15. Scrum will Always Be Messy
Scrum is about people, and people are

messy
Inconsistent, insensitive, erratic, make mistakes
For this reason, it will never be perfect
Idealists will always be disappointed
Opponents will always have ammo
Just keep asking, is it better than before
LAST

Intro To Scrum Slides 2.0

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Intro To Scrum Slides 2.0

Diunggah oleh

Hak Cipta:

Format Tersedia

Introduction to Scrum

Assuming every step is understood, a

Disadvantage: People are involved

 Translation into English: Inspect and Adapt

Inspect & Adapt

 Scrum formalized in 1996 by Ken Schwaber

 Now in use at a growing list of big companies:

 US FDA-approved software for X-Rays, MRIs

 4 pilot teams migrated to Scrum in early 2005

Scrum Daily Scrum

Scrum Daily Scrum

 Responsible for the overall project vision and goals

Scrum Daily Scrum

Scrum Daily Scrum

 The ScrumMaster does everything in

 The ScrumMaster does not manage the team

 Step 1 – Create list of everything the

Plan training for team, and do career-

 Step 3 – Help the manager turn this into a

Scrum Daily Scrum

Product Backlog Retrospective

Product Owner lists

Size estimates are rough

 User Stories are a good approach for

Scrum Daily Scrum

Product Backlog Retrospective

Sprint Length 2 weeks

Workdays During Sprint 8 days

Avail Days Avail Hours Total Avail Hrs

*Net of holidays and other

time available for productive work

hacking, reading blogs, playing foosball

time available for productive work

time available for productive work

hacking, reading blogs, playing foosball

time available for productive work

“8-Hour Day” time committed to another team

hacking, reading blogs, playing foosball

Sprint Length 2 weeks

Workdays During Sprint 8 days

Avail Days Avail Hours Total Avail Hrs

*Net of holidays and other

Sprint Length 2 weeks

Workdays During Sprint 8 days

Avail Days Total Avail ¼

*Net of holidays and other

DESIGN CODE TEST

DESIGN CODE TEST

SPRINT SPRINT SPRINT

DESIGN CODE TEST

Sprint Length 2 weeks

Workdays During Sprint 8 days

Avail Days Avail Hours Total Avail Hrs

*Net of holidays and other

 Team’s available time is mostly committed

Scrum Daily Scrum

Scrum Daily Scrum

 No Changes to the Deliverable

Current Sprint Every Future Sprint

 What is “Emergency Response”?

“Scrum Work” “Critical Issues”

Scrum Team D.R.

Translation into English: Inspect and Adapt

Scrum formalized in 1996 by Ken Schwaber

Now in use at a growing list of big companies:

US FDA-approved software for X-Rays, MRIs

4 pilot teams migrated to Scrum in early 2005

Responsible for the overall project vision and goals

The ScrumMaster does everything in

The ScrumMaster does not manage the team

Step 1 – Create list of everything the

Step 3 – Help the manager turn this into a

User Stories are a good approach for

Team’s available time is mostly committed

No Changes to the Deliverable

What is “Emergency Response”?

To make this work, 3 things are required

Do a Daily Scrum Meeting for your table

After the Daily Scrum, team members