PSF3 Watermarked

Professional
Scrum
Foundations
by Scrum.org Improving the Profession of Software Development
V3.6.1
Why Are You In This Class?
Introduce yourself
One interesting fact
Have you used Scrum before?
Are you working with Scrum?
Whats your background:
Development?
IT?
Other?
1993 - 2014 Scrum.org, All Rights Reserved 6

Professional Scrum at Scrum.org
Professional Professional Professional

Scrum Scrum Master Scrum
Product Owner Developer
.NET | Java
Architects
Business Analysts
Product Owners DB Specialists
Scrum Masters Designers
Executives
Developers
Testers
Professional Scrum Foundations Everyone

Agenda
Day 1 Day 2
Introductions Sprint 3
Sprint 1 Scrum Planning
Scrum Framework: 1 Sprint 4
Sprint 2 Getting Started
Scrum Framework: 2 Keeping Scrum Healthy

About This Course
A mix of discussion and exercise
Introduces Scrum
mechanics and practices
Focuses on delivering software

Logistics
Classroom Hours and Days

Cell Phones
Refreshments
Materials
This course is collaborative
Talk to me
And each other

Why are you
in this class?
What You Do Now 1
MIN
How effective are your current

processes and practices?
Not Very
1 2 3 4 5 6 7 8 9 10

How familiar are you with Scrum? 1
MIN
10
9
8 Very
7
6
5
4
3 Not
2
1
Where are you now 3
MIN
10
9
8
7
How
familiar are 6
you with 5
Scrum? 4
3
2
1
1 2 3 4 5 6 7 8 9 10
How effective are your current processes and practices?

Where are you now?
10
We know what to do Living
9 and we arent doing it the dream
8
Scrum Familiarity
7
6 Learning
5 and improving
4
3
2 This hurts. Things are just fine
1 Help. without Scrum
0
0 1 2 3 4 5 6 7 8 9 10
Current Process Effectiveness
Do. Or do not, there is no try.
Yoda
Sprint 1
Professional Scrum Foundations

Preparation 10
MIN
Make roughly even-sized teams of 3-5 members

Ensure teams have a mixture of skills
Technical and non-technical skills will matter
Post for all to see:

An animal mascot for your team
1-3 things you want to learn in this class
Get requirements

Scrum On! 30
MIN
You will show your Product in 30 minutes
The Scrum Team chooses which requirements to meet
The Development Team chooses how to

best meet the requirements

Time for Review
Step away from the keyboards J
Sprint Review 15
MIN

Retrospective 10
MIN
Part 1 Part 2
Teams work independently Share with class
Record Summarize
What went well? What worked well
What could improve? What could improve
What will you change or Commitments for next
retain next Sprint? Sprint

The Scrum Framework Part 1

Scrum in a Nutshell
1. A Team commits to delivering working software

in 30 days or less
2. A time is scheduled to show that software
3. The Team creates the software
4. The Team offers their work for inspection and adapts the plan
for the next cycle
Scrum (n): A framework within which people can address
complex problems, and productively and creatively deliver
products of the highest possible value.
Scrum is:
One of the agile approaches
Lightweight
Extremely simple to understand
Extremely difficult to master
What Scrum Is and Is Not
Keeping Scrum Healthy

Scrum is only a framework
with rules
like chess

Process Control Models
Defined Empirical
All work is understood before Frequent inspection and

execution adaptation occurs as work
proceeds
Given a well-defined set of
inputs, the same outputs are Processes are accepted as
generated every time imperfectly defined
Follow the pre-determined steps Outputs are often unpredictable

to get known results and unrepeatable
An Empirical Model is Needed When
We dont know the exact outcomes

at the time we begin Does this
describe
We want to control software
the results and keep
quality high
development?
Steps arent always repeatable

Empirical Processes Require Courage
Trust
Inspection & Goal
& Transparency
Adaptation realization
Courage

Scrum Has Three Legs
We all know what

is going on.
Transparency
Check your work
as you do it.
Adaptation Inspection
OK to change
tactical direction.

In this Module
Roles Artifacts Events
Product Increment Sprint

Owner Product Sprint
Development Backlog Planning
Team Sprint Daily Scrum
Scrum Backlog Sprint Review
Master Retrospective
Stakeholder
Sprint Retrospective Sprint Review

Product Planning
Owner Meeting
Sprint
Increment
Daily
Product Sprint Scrum
Backlog Stakeholder Product Development Scrum
Backlog Owner Team Master
Complexity and Scrum
Simple Scrum Thrives

Everything is known Here
Complicated
More is known than unknown
Complex
More is unknown than known
Chaotic
Very little is known Source: Ralph Stacey, University of Hertfordshire

Scrum vs. Waterfall Working software is available.
Waterfall
Plan Design Code Test Release Review

Plan-Driven (Waterfall) Projects
Visibility Ability to Change
Business Value Risk

Scrum vs. Waterfall Working software is available.
Waterfall
Plan Design Code Test Release Review
Scrum
Analyze Analyze Analyze Analyze
Design Design Design Design

Review
Review
Review
Review
Plan
Plan
Plan
Plan
Code Code Code Code
Test Test Test Test
Release Release Release Release

Comparing Scrum And Plan-Driven
Visibility Ability to Change
Business Value Risk
Waterfall Scrum
Roles and Responsibilities
The Scrum Framework, Part 1

Scrum Roles
Product Owner
Scrum
Development Team
Team
Scrum Master
Product Owner
Optimizes the value of the Product
Creates and maintains the Product Backlog

Ideally Product
Owners have
Chooses what and when to release Profit & Loss
accountability for
the product
Represents stakeholders and customers
to the Development Team

Product Owner
May Be May Not Be

A Product Manager A committee
They might chair one
An executive They might represent one
A personnel manager The Scrum Master

This is a direct conflict of interest
A customer

The Development Team
Creates the product Increment
Operates in a series of Sprints

Self-organizing
rarely means Organizes itself and its work
self-managing
Collaborates with Product Owner
to optimize value

Development Team Members
May Be May Also Be

Software Developer Business Analyst
Engineer Database Specialist
Tester User Interaction Designer
Architect Requirements Engineer
Graphic Designer
Technical Writer

Must have all the skills it needs to

deliver a done Increment Ideally
more than one team member has
the competency

Scrum Master
Enacts Scrum values, practices, and rules

throughout the organization
Ensures the Scrum Team is functional and

Personifies agility
productive
and
professionalism
Provides guidance and support for the Scrum
Team

Scrum Master
May Be May Not Be

A manager with appropriate
servant-leader skills A Product Owner
A member of the Development This is a direct conflict of interest

Team
Selected by the Development

Team

Scrum Roles Review
Product Owner
Development Team
Scrum Master
Scrum Roles Review
May select
(hire)
Product Owner
Development Team
Scrum Master Service flows

this way

Scrum Artifacts

Artifacts
Product Backlog
Sprint Backlog
Increment
Product Backlog
An ordered list of desirements
Potential features of the product
The single source of truth for what is planned in the product
Public and available

Product Backlog Item
Transparent unit of deliverable work
Contains clear acceptance criteria

Criteria for successful completion
Answering what will be true when this works
May reference other artifacts like:

Specifications, Mockups, Architecture Models
Sized appropriately
May be completed within a single Sprint
Typically with a few other PBIs

Valid Product Backlog Items
Features
Constraints Behaviors
definitions
User actions or
Bugs / Defects Use Cases
stories
Non-functional
Desirements
requirements

Sprint Backlog
All Product Backlog items selected for a Sprint
A plan by the Development Team to deliver them
&
The plan must provide a sum of work remaining in the Sprint

A Common Expression of a Sprint Backlog
Product Backlog Sprint Backlog

Sprint Backlog
Created by the Development Team during Sprint Planning
Often derived by examining and decomposing Product Backlog

items
Might be a simple To Do list

Increment
The Increment is the sum of all the Product Backlog items

completed during the Sprint and all previous Sprints
Is usable and it works
Is potentially releasable
Must be DONE
As per Scrum Team standards
With no work remaining
Artifacts Review
Product Backlog
Sprint Backlog
Increment
Events and Time Boxes

Scrum Events and Time Boxes Scrum uses time-boxed events, such that every event
has a maximum duration. This ensures an appropriate
amount of time is spent planning without allowing
waste in the planning process.
Sprint
Sprint Planning
Daily Scrum
Sprint Review
Retrospective
Sprint
A container for all activities
Includes development activities and other Scrum events.
Starts with Sprint Planning
Ends with Sprint Retrospective
30 days or less
Sprint Planning Meeting
A Sprint Goal is created
The Sprint Backlog is created

The Development Team selects Product Backlog items for the Sprint in
collaboration with the Product Owner
The selection of Product Backlog items into the Sprint Backlog
represents the Development Team's forecast for what can be completed
in this Sprint
The entire Scrum Team attends

Daily Scrum
Same time and place each day
Scrum Master may or

may not facilitate
A daily meeting for the Development Team to:

Synchronize activities
Create a plan for the next 24 hours
Assess progress toward the Sprint Goal

A Simple Scrum Board
PBI Todo In Progress Done

Create Scrum Boards 10
MIN
Only work for the Sprint is ever shown here

PBI column isnt a place to store your Product Backlog
PBI To Do In Progress Done

Sprint Review
The Scrum Team shows the product Increment
The product Increment is inspected by stakeholders (customer,

marketing, sales, )
Stakeholders are encouraged to provide feedback and to

collaborate
The Product Backlog might be adapted

Defining Done 5
MIN
Only completed features may be shown at Sprint Review. How will

your team know what may be shown in the next Sprint Review here
in class?
Post a simple Definition of Done for your team so that all items
shown in Sprint Review are known to meet a baseline expectation
of quality and completeness.

Sprint Retrospective
An inspect / adapt opportunity for the

Scrum Team
The Scrum Team discusses

What went well in the Sprint
What could be improved
What will we commit to improve for the next Sprint

Scrum Events and Time Boxes Review
Sprint
Sprint Planning
Daily Scrum
Sprint Review
Retrospective
Section Summary
Scrum Defined
Roles and Responsibilities
Artifacts of the Framework
Events and Time Boxes

Section References
Scrum Guide from Scrum.org
Agile Project Management with Scrum by Ken Schwaber
Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
The Enterprise and Scrum by Ken Schwaber
The Fifth Discipline: The art and practice of the learning organization by Peter Senge
[http://bit.ly/RtbhG8]
martinfowler.com/articles/itsNotJustStandingUp.html [http://bit.ly/QAWtSW]
Agile Estimating and Planning by Mike Cohn
Scrum and XP from the Trenches by Henrik Kniberg

A little less conversation, a little more action
please
- Elvis Presley
Sprint 2

Preparation
Collect new requirements
Identify your Teams Product Owner
The Product Owner will order requirements and accept or reject

the increment.

Sprint Planning 10
MIN
Estimate the size of PBIs

Forecast which PBIs will be delivered
Create a plan to deliver them
The Product Owner handles questions about functionality

Rules 30
MIN
You will show your Product in 30 minutes
The Development Team decides how to best meet the

requirements

Time for Review
Sprint Review 15
MIN

Retrospective 10
MIN
Part 1 Part 2
Teams work independently Share with class
Record Summarize
What went well? What worked well
What could improve? What could improve
What will you change or Commitments for next
retain next Sprint? Sprint

The Scrum Framework Part 2

In This Module
Scrum Measurements
More on Roles, Artifacts, and Events
Self Organization

Scrum Not an Acronym
as in Rugby, the ball gets passed within the team

as it moves as a unit up the field.
Takeuchi-Nonaka The New New Product

Development Game (1986)
Scrum Measurements

Sprint Burndown
140
120
100
80
60
40
20
0
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10

Sprint Progress
This measurement is for

No one else
Used to see
How we are progressing in the Sprint
If scope should be discussed with the Product Owner

Sprint Progress Monitoring
Can easily be (mis)used

To micromanage the Development Team
To demonstrate false progress
May change abruptly when

New work is added or removed during the Sprint
Scope is renegotiated with the Product Owner
New things are learned about the work of the Sprint

Velocity
30
25
Functionality Delivered
20
15
10
0
1 2 3 4 5 6 7 8 9
Sprint

Velocity
A measure of Product Backlog Items (features, bugs, ) delivered

per Sprint
Used by the Product Owner to provide forecasts
Used by the Development Team to gauge how much work to pull

in a Sprint Planning meeting

Considering the nature of velocity 3
MIN
A Development Teams Velocity may vary dramatically from one

Sprint to the next.
Each team determine:
Is this good or bad?


Product Owner
Not the Development Teams assistant

May not ever write a User Story
Needs to spend as much time with the Development Team as needed. Not less!
(as a rule of thumb 20%-30%)
Defines features and functionality

The level of this will vary
Some Product Owners will work closer to implementation details than others
Has the final word on the content and the order of the Product Backlog

Composition is constant throughout a Sprint
Typically has 3-9 members with the sweet spot around 6
May have partially allocated members

Often considered an impediment
Ex: Database Administrators, User Interface Design experts, Technical
Writers

Requirements
Non Sequential execution is key
Design
Code
Everyone pitches in regardless of
Test
individual skill specialty
The Development Team is held to account as a unit
Sprint n-1 Sprint n Sprint n+1

Scrum Master
Not the Development Teams assistant

May not even attend the Daily Scrum
Is not there to drive the team or drive results
This is a servant-leader, management position

Managing the organizations Scrum use and adoption
Serving and coaching the Scrum Team
Embodying agility for all to see

Scrum Master
Guides and cares for the Team
Adhere to Scrum values, practices,
and rules
Understand and use self-organization
Be more productive
Increase quality of Increments
Removes Impediments to the

Development Teams success that
they are unable to remove
themselves

Product Backlog Items
Each Product Backlog item is executable within a Sprint
Best to have several in a Sprint
Each one is ideally discrete without dependencies

Sprint Planning Meeting
Typical duration is 5% of 8 hours for 4 week

total Sprint length Sprint
Has two topics

What will we do?
How will we do it?
Often the day
following Usually less for
Sprint shorter Sprints
Retrospective
Sprint Planning Meeting Flow
Development Team Increment + Ready Retrospective
Definition of Done
Velocity + Capacity Product Backlog Commitments
1 What
Analyze, evaluate and select

Product Backlog for Sprint
2 How
Decompose into actionable plan
Enough Work is decomposed
Sprint Goal + Forecast + Sprint Backlog

Ins and Outs of Sprint Planning
Inputs Outcome
Definition of Done The Sprint Goal
Development Team Capacity for next Sprint
Forecast
Past performance of the Development Team
The Ready Product Backlog Sprint Backlog

60-70% known and accurate
The latest Increment
Some work is stubbed out for
Retrospective commitments discovery later
100% time commitment is going to
fail

Sprint Planning 5
MIN
List the activities and responsibilities for each Scrum role during the
Sprint Planning meeting
Product Owner
Development Team
Scrum Master

Sprint Goal
An objective to be Through the implementation of the PBIs selected in Sprint

Planning
met in the Sprint Providing guidance to the Development Team
Allows flexibility in
Allows wiggle room for exact implementation of PBIs
delivering the Although the Sprint Goal is fixed
increment
Is sacrosanct As the Development Team works, it keeps this goal in mind

throughout the Each Daily Scrum assesses the Teams progress toward
meeting the Sprint Goal
Sprint
Some Sprint Goals
Decrease upstream
payloads by 30%
Deliver a minimal set

of administration
features.

Daily Scrum
Development Inspect Adapt,

Team creates progress optimizing
a plan for the toward the the value of
next day Sprint Goal the next day

The Daily Scrum
15 minute time box
Create a plan for the

next 24 hours
Assess progress toward the Sprint Goal
By the Development Team, for the Development Team

The Daily Scrum Beginner Level
What did I do yesterday What will I do today to

that helped the help the Development
Development Team Team meet the Sprint
meet the Sprint Goal? Goal?
Do I see any impediment

that prevents me or the
Development Team from
meeting the Sprint Goal?

Why a Daily Scrum?
Share commitments
Identify Impediments
Create focus A Daily Scrum in Microsoft

Patterns and Practices
Increase and maintain situational awareness

The Sprint
All Sprints have consistent duration
Starts right after the previous one
Scope is negotiated constantly throughout

Between Development Team and Product Owner
This recognizes uncertainty even within the Sprint

Sprint Review
The Scrum Team shows the Increment
Feedback is heard from all present
Feedback used to guide the next Increment

Sprint Review
Typically 2.5% of Sprint 4 hours for a 4

Duration week Sprint
The entire
Scrum Team is Usually less for
present The point is the feedback shorter Sprints
+ No slides
all who care to
attend Show your work

Mechanics of Sprint Review
Product Owner Development Team

Everyone
Shares Shares
What was done The actual Provides and hears
What wasnt Increment of feedback
State of the software
Product Backlog What happened in
Likely Release the Sprint
projections How problems
were addressed
and the effect on
the increment

A discussion of:
The Scrum process
Scrum Team member behaviors
Tools used and needed
Expanding the Definition of Done
To find actionable improvements

The Scrum Team can enact next Sprint
To adapt common practices and techniques
To increase the DoD
The Sprint Retrospective
The Scrum Teams opportunity to improve
Typically 3 hours for a 4 week Sprint

Usually less for shorter Sprints
Kaizen -
Continuous
After every Sprint Review Improvement
Whole Scrum Team participates

Scrum Master
Product Owner
Development Team
The Retrospective Prime Directive
Regardless of what we discover, we
understand and truly believe that
everyone did the best job they could, given
what they knew at the time, their skills and
abilities, the resources available, and the
situation at hand.
- Norm Kerth,
Project Retrospectives: A Handbook for Team Reviews
The Typical Sprint Retrospective Model
What worked What could be

well? improved?
What will we
commit to doing in
the next Sprint?
Event lengths and Sprint length
Event 30 Days 3 Weeks 2 Weeks 1 Week

Less than 8 hours Less than 8 hours Less than 8 hours
Sprint Planning 8 hours (~6 hours) (~4 hours) (~2 hours)
Daily Scrum 15 min
Less than 4 hours Less than 4 hours Less than 4 hours

Sprint Review 4 hours (~3 hours) (~2 hours) (~1 hour)
Less than 3 hours

Less than 3 hours Less than 3 hours
Sprint Retrospective 3 hours (~2 hours 15
(~1 hour 30 mins) (~45 mins)
mins)

Self Organization

Self Organization
A structure or pattern appears in a system without a

central authority or external element imposing it
through planning.
The skill is using
It is a primal behavior in nature self organizing
Swarms teams to the
Flocks organizations
Herds
advantage
Scrum exploits this
You have seen it today

Productive Self Organization
Requires skill
In the domain at hand
In the constraints of the framework
In the software development craft
Skills needed in software teams using Scrum

Scrum itself Languages and frameworks
The business domain Levels of testing
Useful technologies Mastery of development tools
Practices of software Build and Deploy Automation
craftsmanship Emerging architecture or design
The science of user experience Many, many more

Self Organization 5
MIN
Each team consider:
What does it mean

for a Development Team
to be self-organizing?

Self Organizing Scrum Development Teams
Select the work to complete
Determine how best to

meet requirements
Get help with external disruptions

(Impediments)
Select their own Scrum Master

What does Scrum require? 3
MIN
A Development Team new to Scrum is trying to create their first

Definition of Done and create a loose plan for their first Sprint.
Many topics are being discussed.
They want to know which of these Scrum requires. What is your

guidance?
TDD User Acceptance Testing Sprint Retrospective
Continuous Integration Sprint Planning Demo to customer
Daily Scrum Backlog Refinement Dedicated QA resources
Loose coupling Planning Poker Product Backlog
2 Parts of the Scrum Discussion
People Practices Engineering Practices

Planning Design
Empiricism Coding
Collaboration Testing
Self-organization Automation
Leadership Deploying
Communication User experience
Transparency Emergent Architecture

Using Self-Organizing Teams Well
Provide clear goals and desired outcomes
Provide a framework within which the team operates

Scrum rules
Prescribed Engineering Practices
Team-evolved principles, norms, and culture
Sprint challenge and pressure
Remove Impediments to the teams progress

Impediments
Anything that:
Impedes a teams progress

The Scrum
Masters bread Cannot be resolved by the team internally
and butter
Requires cooperation of non-team members
Affects the work of the current Sprint

Handling Impediments 5
MIN
You are the Scrum Master. The Development Team reports having 2
Impediments:
Network operations is late delivering a needed server

One of the developers refuses to attend the Daily Scrum
What do you do?

Section Summary
Scrum Measurements
Self Organization

Sprint 3

The Sprint Structure 65
MIN
Sprint Planning (10m)

Sprint Goal
Forecast
Sprint Backlog
Development (30m)
Deliver a Done Increment
Sprint Review (15m)
Sprint Retrospective (10m)

Time for Review
Scrum Planning

In this Module
Planning Levels
Estimating Software Development
Owning a Product Backlog
Defining Done

Planning Levels
Scrum Planning

Scrum Planning
Plan constantly, not just in the beginning
Planning is an activity, not a document
Recognize, embrace, and support change rather than trying to

control it

Scrum Planning
Changing the
Constantly
Focuses on plan doesnt
and
historical mean
consistently
performance changing
transparent
timing

Scrum Focuses Here
Product
Backlog
Product Owner
owns this
Release
Backlog
Sprint
Entire Backlog
Scrum Team
owns this
Development Teams
own this
Daily Plan

Backlog Accuracy and Item Detail
Vague Understood Estimated PBIs Tasks
Other Next
Next Next This
Backlog Next
Release Sprint Sprint
Items Sprint

Keep a Rolling Backlog Projection Current Sprint
PBIs are estimated and ordered for

approximately the next 3 Sprints
The current Sprint is detailed

Next Sprint
Broken into Sprint Backlog Tasks
Very granular detail
Next 2 Sprints are understood

by the entire Scrum Team Next, Next Sprint
Estimated
Valued
Ordered
Loosely planned
Product Backlog Refinement
Refining means
Planning the PBL to an actionable level of detail
Maintaining a Rolling Backlog Projection
Plan 10% of the Sprint capacity of the Development Team to be

spent on refining the Product Backlog
Top ordered Product Backlog items are well understood and

easily selected in Sprint Planning.
They are Ready
It is very difficult to make a vigorous, plausible, and
job-risking defense of an estimate that is derived by
no quantitative method, supported by little data, and
certified chiefly by the hunches of the managers.
The Mythical Man-Month, Fred Brooks (1975)

Scrum Planning

Estimating with Groups
Group derived estimates are demonstrably

more accurate than estimates by individuals
When guessing the number of jellybeans

any given jar, the average of all guesses is
typically within 2-3% of the correct answer.
- James Surowiecki
The Wisdom of Crowds

Myth
With more
analysis and
effort, estimates
get significantly
more accurate.
Estimation is Often Expensive
Accuracy
Effort or Time

Estimating the Unknown 3
MIN
A Development Team refuses to estimate Feature X because no one

on the team has any experience with the technology to be used.
The Product Owner proposes the following Product Backlog Item.

What is your advice to the Development Team?
Learn how the new technology works and understand any relevant
design implications to Feature X.

Estimating the Unknown 3
MIN
A Development Team is uncomfortable estimating Feature Z

because no one on the team fully understands the architecture
needed for the feature. There is no need for a new technology, but
a new technique or design pattern.
The Product Owner proposes the following Product Backlog Item.

What is your advice to the Development Team?
Experiment with options for implementing Feature Z.

Story Points
Very common way to estimate Points are additive

work
Based on historical reality
Based on size, effort and
complexity, not duration Easy to use and understand
Unitless and numerically relative
Different for each team of

estimators

Story Point Values
Non-linear in progression
Can you distinguish 1 point from 2?
Can you distinguish a 17 from an 18? Include big and
How about a 99 from a 100? small outliers if
you want.
Use units that make sense
1, 2, 3, 5, 8, 13, 21
0, , 100, 300,
1, 2, 4, 8, 16, 32

Using Story Points
Product Backlog
Cost: 13
We can see right away
Cost: 21
Cost: 21 Defect
1. Which work items cost the most
Cost: 3 Requirement
Cost: 5 Constraint
2. Total cost of all the work Cost: 1
Cost: 8
3. Total cost to an iteration Cost: 13
Cost: 3
Cost: 34
Cost: 13
Planning Poker Rules
Each developer has a deck of estimation cards.
Customer/Product Owner reads a story and its discussed briefly.
Each developer selects a card thats his or her estimate.
Cards are turned over so all can see them (synchronously).
Discuss differences (especially outliers).
Re-estimate until estimates converge.

Avoid Anchoring
This is an easy one
Please dont
Broadcast opinions before
I am throwing a 3
estimations are made
Show cards early
This is huge
Because it
This will be a 5
Causes reactive estimates
Shuts down discussion
May leave important details undiscovered I have no idea.

Planning Poker
Homer
Marge
1
Bart Lisa Maggie

Planning Poker
Homer
Marge
3
Bart Lisa Maggie

Planning Poker
Homer
Marge
5
Bart Lisa Maggie

Make Your Decks 5
MIN
Create a deck of cards as follows:

1, 2, 3, 5, 8, 13, 21
? = I still have questions
= Too big to estimate
* Note: The above sequence uses

the actual Fibonacci sequence

Planning Poker 1 5
MIN
Choose 3-5 PBIs of varying size your team has already delivered.
Choose 1 of medium size and label it as an 5
Estimate the other completed PBIs
Use the estimated items as a comparison point to the items you

are estimating.

Planning Poker 2 10
MIN
Using the completed and

estimated PBIs for reference,
estimate PBIs not yet worked
on.
Try and get 3-5 PBIs

estimated.

Scrum Planning

Product Backlog Item Attributes
Title: ...
As a . . .
I want . . .
So that . . .
Development Team Alpha
Scenario: ...
Given . . .
13
When . . . Business Value
Effort Estimate 5
Then . . . ROI 2.6

Business Value
Money to be earned
The Product Owner is
responsible for this Clients to be retained
Delight to bring to users

It isnt always just revenue
Market share to capture
Can be estimated or calculated Money to be saved
MoSCoW
1100 Improvement to
User Experience

Ordering the Product Backlog
Risk
Identify risk for items in the Backlog
Do highest risk items first
Return on Investment
Estimated ROI Index
Simple business value
ranking system
This gives a single number
by which to rank work
Because the Product Owner says so

ROI Index Ordering Product Backlog
Can see value at a glance 5.7

4.8
4.3
Less subjective 4.3
3.2
3.1
Not the last word
2.3
Thats the Product Owner
1.7
ROI Index is a tool 0.0
.73
.04

Rule #1
An accurate release plan

requires an ordered
and estimated backlog
Rule #2
An accurate release plan

requires known Velocity

2 Basic Types of Release Planning
Date Target Planning Feature Target Planning

The product will release on a The product will release when
specific date specific features are ready
We Must Answer We Must Answer

How much of the backlog will be When will features A, B, and C be
complete by a given date? ready?

Product Backlog
Cost: 13
Cost: 21
Cost: 21
When will
Cost: 3
item A
Cost: 5
likely ship?
Cost: 1
Cost: 8
Average Team Velocity = 33
Sprint Length = 2 weeks
Cost: 13
Cost: 3 A
Cost: 100
Cost: 13 6 weeks
Product Backlog
Defect A
Size: 13
What will be
Defect B
Size: 1
Requirement A
Size: 2
Requirement B
Size: 8
ready in 8
Requirement C
Size: 5
Constraint A
All This weeks?
Size: 13
Requirement D Average Team Velocity = 18
Size: 3
Requirement E Sprint Length = 2 weeks
Size: 13
Constraint B
Size: 5
Requirement F
Size: 8
Constraint C
Size: 2

Projecting with Velocity
30
Top 3
Avg 23
25 Best Case
20 Middle 3
Story Points
Avg 19
Likely Case
15
Bottom 3
10 Avg 14
Worst Case
5
0
1 2 3 4 5 6 7 8 9
Sprint

Projecting Velocity for 3 Sprints
Product Backlog
Estimate: 2
Estimate : 20 Worst Case:

3 Sprints X 14 points = 42 points
Estimate : 20
Estimate : 3
Most Likely Case:
Estimate : 5 3 Sprints X 19 points = 57points
Estimate : 1
Estimate : 8 Best Case:

3 Sprints X 23 points = 69 points
Estimate : 13
Estimate : 3
Estimate : 100
Estimate : 13 Top 3 Middle 3 Bottom 3 Avg

Avg 23 Avg 19 14
Best Case Likely Case Worst Case
Product Backlog Burndown Chart
700
600
Functionality Remaining
500 How is the release

going if this is
400
the ship date?
300
200
100
0
1 2 3 4 5 6
Sprint
Defining Done
Scrum Planning

When can you ship or release? 3
MIN
What is done and present for a piece of functionality so that you

can put it into production or release it?
How do you know that there is no work remaining?

Definition of the Definition of Done
The Definition of Done is a shared

understanding of completeness
Must be universally understood and

agreed upon for transparency
The common denominator of quality

for the product

DoD Tips
In general the DoD is for the Increment and all Product Backlog Items
Checklists for Definition of Done at various levels and checkpoints can
be helpful
Visit Definition of Done in each Retrospective
If the development organization does not have a common Definition of

Done for that product, product family, or system (to reflect product fit for
purpose), it defaults to the Development Team to define and own.

Section Summary
Planning Levels
Defining Done

Section Summary
Product Backlog
Release Plan
Sprint Plan
Daily Plan

References
Agile Estimating and Planning, Mike Cohn
Cone of Uncertainty
www.construx.com/Page.aspx?hid=1648
It's Not Just Standing Up: Patterns of Daily Stand-up Meetings

http://martinfowler.com/articles/itsNotJustStandingUp.html

Sprint 4

The Sprint Structure 65
MIN
Sprint Planning (10m)

Development (30m)
Sprint Review (15m)
Sprint Retrospective (10m)

Time for Review
Getting Started

In this Module
Getting
Ready
Starting
Change is the only constant.
Heraclitus, Greek philosopher
Getting Ready
Getting Started

Scrum Values 10
MIN
Where is the value of the Scrum

values for your daily work as
Scrum Master in a Scrum Team?

Agility Requires Organizational Change
Todays culture is finely tuned to

produce current conditions
Agility is an entirely new state Culture

Culture must change to achieve
Agility
Organizational change is a
The way we do
difficult multi-step process that
requires leadership
things here.
Each Team Answer 3
MIN
Should we use Scrum?
Why or why not?

Each Team Answer 3
MIN
What will happen if we

dont change?
Each Team Answer 3
MIN
Why havent previous

efforts worked?
Each Team Answer 3
MIN
What support do we most

need, and from whom?
What help will they need?

Each Team Answer 3
MIN
If we change soon, what will be

true:
In 6 months?
In 1 year?
Agile Transition Backlog 15
MIN
Create and order a backlog

for your organizations
transition to agility with
Scrum.
Refining the Scrum Implementation Backlog 2
MIN
Who will be the Product Owner for this Scrum Implementation

Backlog?
Who will work with this Product Owner to refine this backlog?
Ideally, 1 person from each team in class
Plus the highest ranking person in class

Kotter's 8-Step Change Model
1. Establish a sense of urgency

2. Create a guiding coalition
3. Develop a vision and strategy
4. Communicate and share the vision
5. Create an agile implementation backlog
6. Empower broad-based action
7. Generate short-term wins
8. Anchor new approaches into the culture

Starting
Getting Started

Who Fills These Roles and Why?
Product Owner
Scrum Master
What is a reasonable DoD for a first Sprint?
Where is the Increment deployed? By whom?
What tests accompany it?
What documentation accompanies it?
Will bugs known today still be present?

Product Backlog
Is there one today?

If not, when will one exist?
How and where will the Product Backlog

be managed and made visible?
Are the PBIs estimated and ordered?

If not, when and where will that occur?
Who will schedule it?
How will PBIs be estimated?

The First Sprint
How long will Sprints be and why?
When will the first one begin and end?
What might be a valid Sprint Goal

for your first Sprint?

Information Radiators
Where will they be?
What will they show?

Who will Schedule These Events?
Sprint Planning
Daily Scrums
Sprint Review

Refining
Will you refine?
How
When
Where

Section Summary
Getting Ready
Starting

In this Module
Monitoring Your Health
Patterns of Healthy Scrum Teams
Staying the Course


Retrospective commitments for the next Sprint
Answer: Sprint # What we committed to for the next Sprint

What will your team do in the
next Sprint? 3 All Increments shown in Sprint Review build
via automated build
4 New features will have corresponding unit

Keep these visible to all tests
Keep a growing list of them 5 Tests will run as part of the automated build
processes
Watch DoD grow over time 6 All increments release with a functional
installer

Ask Questions Like These Regularly
Is our DoD increasing in scope?

Is our quality improving?
Are we learning more from each other?
Are we hiding or ignoring anything?
These questions make a

And for each answer nice addendum
why or why not. discussion to Sprint
Retrospectives

Information Radiators
Walls work well Information Radiator Candidates

Development Team plan
Updated regularly with Build and Test automation status
Scrum events Release plan or Burndown
Sprint Burndown
DoD checklists
Visited frequently
Retrospective commitments
during discussions
Others?
Keep important information visible and transparent at all times

What Will You Do? 5
MIN
The Development Team has been together for several months. You
are a Scrum Master. Velocity is fairly stable.
The CTO asks why, What are you doing to help the team improve
their velocity?
What is your response?


An Active Team Room

Anti-Pattern: Poor Use of Retrospectives
A: Everything went wrong

that time.
B: Whatll we do about it?
A: Forget that ever happened.
B: Good idea.

Fewer Specialists
In a multi-disciplinary Development Team

of appropriate size, specialization is
simply not possible
Task pairing and sharing grows everyone
Focus shifts from fulfillment of individual

duties to the overall success of the team

Self Organizing Development Teams
The Development Team determines
Who does what & when

Who is needed on the team and not
When it needs help resolving
Impediments
Needed process improvements
Technology practices
Their own Scrum Master
Undone Work 5
MIN
It is the last day of a Sprint and the Development Team has

completed all work, except one item. The remaining item is too
small to be split. It is too large to be completed.
The Development Team is unsure what to do.
What is your guidance?

Anti-Pattern: Reverting to Bad Behavior
Scrum is simple, but hard
Giving up when it feels hard

undermines everyone else
Scrum Teams need time and support

to adopt the successful disciplines
Just this one time with no unit tests

Dont do it.
Anti-Pattern: The Hero Developer
High functioning organizations

do not need heroes
Heroes almost always ignore quality:

Tests, Documentation, Automation
Needing a hero means the overall

system is fundamentally broken
Heroes resist Scrum as focus moves

to the team
away from the individual

Actual Software at Sprint Review
Power Point No slides! No models! Just

misses the point working software!
The product is ready to be

deployed if needed No special effects
Preparation is minimal, no
more than 2 hours Real software.
Real feedback.
Real value.
Anti-Pattern: Absent Product Owner (APOP)
Very common and very destructive
Increases wait time and creates waste
A quarreling Product Owners is worse
Feature decisions are often decided

by those least appropriate to do so

Staying the course

Know Your Supporters
Identify organizational leaders

who will want Scrum to succeed
Why do they want it? Specifically?

Can those things be measured to see Scrums effect?
How can you help your supporters?
Consider Agility Path

Have the Right Scrum Master
Scrum Master is not a Project Manager
Good Scrum Masters are fit via temperament and facilitation

skills, not job title
Good Scrum Masters are ferocious advocates

For Scrum
For the Development Team

Will this Really Work? 3
MIN
Will You Try Scrum by the Book for 3 Months?

With sincerity
Allowing time before deciding the process doesnt work.
Realizing that it wont be easy
Knowing early failures often precede success
What does this mean to:

- Your organization?
- Your team?
- You?
Section Summary
Staying the Course

Professional Scrum Master 1 Assessment
Included in your class $150 per student value
Instructor submits information to Scrum.org

85% is a passing score
The Scrum Open assessment is great practice
Professional Scrum Master certification upon passing

Thank You!

Thank You
Scrum On!

PSF3 Watermarked

Uploaded by

Document Information

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

PSF3 Watermarked

Uploaded by

Copyright:

Available Formats

Professional

1993 - 2014 Scrum.org, All Rights Reserved 6

Professional Professional Professional

Professional Scrum Foundations Everyone

1993 - 2014 Scrum.org, All Rights Reserved 7

1993 - 2014 Scrum.org, All Rights Reserved 8

A mix of discussion and exercise

Focuses on delivering software

1993 - 2014 Scrum.org, All Rights Reserved 9

Classroom Hours and Days

1993 - 2014 Scrum.org, All Rights Reserved 10

How effective are your current

1993 - 2014 Scrum.org, All Rights Reserved 12

How effective are your current processes and practices?

1993 - 2014 Scrum.org, All Rights Reserved 16

Make roughly even-sized teams of 3-5 members

Post for all to see:

1993 - 2014 Scrum.org, All Rights Reserved 17

You will show your Product in 30 minutes

The Scrum Team chooses which requirements to meet

The Development Team chooses how to

1993 - 2014 Scrum.org, All Rights Reserved 18

1993 - 2014 Scrum.org, All Rights Reserved 20

1993 - 2014 Scrum.org, All Rights Reserved 21

1993 - 2014 Scrum.org, All Rights Reserved 22

1. A Team commits to delivering working software

2. A time is scheduled to show that software

3. The Team creates the software

1993 - 2014 Scrum.org, All Rights Reserved 25

1993 - 2014 Scrum.org, All Rights Reserved 26

All work is understood before Frequent inspection and

Follow the pre-determined steps Outputs are often unpredictable

We dont know the exact outcomes

Steps arent always repeatable

1993 - 2014 Scrum.org, All Rights Reserved 28

1993 - 2014 Scrum.org, All Rights Reserved 29

We all know what

1993 - 2014 Scrum.org, All Rights Reserved 30

Roles Artifacts Events

Product Increment Sprint

Sprint Retrospective Sprint Review

Simple Scrum Thrives

1993 - 2014 Scrum.org, All Rights Reserved 33

1993 - 2014 Scrum.org, All Rights Reserved 34

Business Value Risk

1993 - 2014 Scrum.org, All Rights Reserved 35

Design Design Design Design

Test Test Test Test

Release Release Release Release

1993 - 2014 Scrum.org, All Rights Reserved 36

Business Value Risk

1993 - 2014 Scrum.org, All Rights Reserved 38

Optimizes the value of the Product

Creates and maintains the Product Backlog

1993 - 2014 Scrum.org, All Rights Reserved 40

May Be May Not Be

A personnel manager The Scrum Master

1993 - 2014 Scrum.org, All Rights Reserved 41

Creates the product Increment

Operates in a series of Sprints

1993 - 2014 Scrum.org, All Rights Reserved 42

May Be May Also Be

1993 - 2014 Scrum.org, All Rights Reserved 43

Must have all the skills it needs to