Slides PDF

Professional Scrum
Foundations
by Scrum.org – Improving the Profession of Software Development
v3.1
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
Executives Designers
Developers
Testers
Professional Scrum Foundations Everyone
© 1993 - 2012 Scrum.org, All Rights Reserved 3

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 3
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? 3
MIN
10
9
8 Very
7
6
5
4
3 Not
2
1
Where are you now?
10
We know what to do Living
9 and we aren’t 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
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 Team chooses which requirements to meet
• The Team chooses how to

best meet the requirements

Time for Review
Step away from the keyboards 
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 methods
• 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 • Outputs are often unpredictable

steps to get known results and unrepeatable

Where is Scrum appropriate? 3
MIN
A network operations team receives Increments from Scrum

Teams. They see Scrum’s effectiveness for product
development and are considering using Scrum to manage
their work.
What is your advice to this team?

An Empirical Model is Needed When
• We don’t 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 aren’t 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 Master Backlog • Sprint Review
• Retrospective
Sprint
Product Planning
Owner Meeting Sprint Review Retrospective
Sprint
Increment
Daily
Product Sprint Scrum
Backlog Backlog Product Development Scrum
Owner Team Master

Very
Complexity and Scrum Uncertain
Simple Scrum Thrives Here

Everything is known
What We Make
Chaos
Complicated
More is known than unknown
Complex
More is unknown than known
Simple Complicated Complex

Chaotic
Very little is known Very How We Do It
Certain © 1993 - 2012 Scrum.org, All Rights Reserved 29
Plan-Driven Projects
Visibility Ability to Change
Business Value Risk

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

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
Development Team
Scrum Master Service flows

this way

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

Ideally has every competency it

needs to deliver a done Increment

Scrum Master
• Enacts Scrum values, practices, and rules

throughout the organization
• Ensures the Scrum Team is functional and

Personifies
productive
agility 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

Team interest
• Selected by the Development

Team

Scrum Roles Review
Product Owner
Development Team
Scrum Master
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
• The 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 software created in the Sprint
• Is usable and it works
• Is potentially shippable
• 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
Sprint
Sprint Planning
Daily Scrum
Sprint Review
Retrospective
Sprint
• A container for all activity
• Includes development activities and other Scrum events.
• Starts with Sprint Planning
• Ends with Sprint Retrospective
• One month 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
– The Development Team forecasts what will be completed 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
• Some teams find value in having a “verify” column

• Only work for the Sprint is ever shown here.
• This isn’t a place to store your backlog.
PBI To Do In Progress Done

Sprint Review
• The Scrum Team shows the product Increment
• The Product Increment is inspected
• Stakeholders are encouraged to provide feedback

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 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
• martinfowler.com/articles/itsNotJustStandingUp.html
• Agile Estimating and Planning by Mike Cohn
• Scrum and XP from the Trenches by Henrik Kniber

Sprint 2

Preparation
• Collect new requirements
• Identify your Team’s Product Owner
• The Product Owner will prioritize requirements and accept

or reject the increment.

Sprint Planning 10
MIN
• Estimate the size of PBIs

• Choose what 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 Team chooses which requirements to meet
• The Team chooses 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

– The Development Team
– 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 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 features or functionality 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 Team’s Velocity may vary dramatically from

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

More on Roles, Artifacts, and Events

Product Owner
• Has the final word on what the Development Team is working on
• Not the Development Team’s assistant

– May not ever write a User Story
– Typically spends 20-30% of their time with the Development Team
• Defines features and functionality

– The level of this will vary
– Some Product Owners will work closer to implementation details than
others

• Composition is constant throughout a Sprint
• Typically has 6 +/- 3 members
• 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

Scrum Master
• Not the Development Team’s 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 organization’s 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 Team’s success

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
total Sprint length
• Has two phases 8 hours for 4

week Sprint
– What will we do?
– How will we do it?
Often the day – Some Development
Teams do this all at once
following
Sprint 4 hours for 2
Retrospective week Sprint
Sprint Planning Meeting Flow
Development Team Product

Velocity + Capacity Backlog
Analyze, evaluate and select

Product Backlog for Sprint
Forecast functionality
Decompose into actionable plan
Sprint Backlog

Ins and Outs of Sprint Planning
Inputs Outcome
• The Product Backlog • The Sprint Goal or Goals
• The latest Increment • Sprint Backlog

– 60-70% known and accurate
• Development Team Capacity – Some work is stubbed out for
discovery later
for next Sprint
– 100% time commitment is
going to fail
• Past performance of the
Development Team
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 Goals
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
Are sacrosanct • As the Development Team works, it keeps this goal in mind
throughout the • Each Daily Scrum assesses the Team’s 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 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

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 you What will you do

do since the last before the next
meeting? meeting?
What
Impediments are
in your way?

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

Patterns and Practices
• Increase and maintain situational awareness

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

Sprint Review
• 2.5% of Sprint Duration 4 hours for a 4

week Sprint
The entire
Scrum Team is • The point is the
2 hours for a 2
present feedback week Sprint
+ • No slides
all who care to
attend • Show your work

Mechanics of Sprint Review
Product Owner Development

Everyone
Shares Team Shares
• What was done • The actual • Provides and
• What wasn’t Increment of hears feedback
• State of the software
Product Backlog • What happened
• Likely Release in the Sprint
projections • How problems
were addressed

Sprint Retrospective
• 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 Team’s opportunity to improve
• Typically 3 hours for a 4 week Sprint

Kaizen -
– Proportionally less for shorter Sprints Continuous
Improvement
• After every Sprint Review
• 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 could be
What worked well?
improved?
What will we
commit to doing
in the next
Sprint?
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 self
• It is a primal behavior in nature organizing
– Swarms
– Flocks teams to the
– Herds organization’s
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 Teams
• Select the work to complete
• Determine how best to

meet requirements
• Get help with external

• disruptions (Impediments)
• Select their own Scrum Master

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

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 customers
Daily Scrum Backlog Grooming Dedicated QA resources
Loose coupling Planning Poker Product Backlog
Using Self-Organizing Teams Well
• Provide a framework within which the team operates

– Scrum
– Prescribed Engineering Practices
– Team-evolved rules, customs, and norms
• Provide clear goals and desired outcomes
• Remove Impediments to the team’s progress

Impediments
Anything that:
• Impedes a team’s progress
The Scrum • Cannot be resolved by the team internally

Master’s bread
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
• More on Roles, Artifacts, and Events
• Self Organization

Sprint 3

The Sprint Structure 70
MIN
• Sprint Planning (15m)

• Sprint (30m)
• 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 doesn’t
and
historical mean
consistently
performance changing
transparent
timing

Scrum Focuses Here
Release
Backlog Product Owner
owns this
Product
Backlog
Sprint
Entire
Scrum Team
Backlog
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
Backlog Grooming
• Grooming means
– Planning the PBL to an actionable level of detail
– Maintaining a Rolling Backlog Projection
• Plan 10% of each Sprint to be spent

grooming the Product Backlog
• Top ordered Product Backlog items are well understood and

easily selected in Sprint Planning

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.
— Fred Brooks (1975)
Estimating Software Development

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 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
– XS, S, M, L, XL, XXL
0, ½, 100, 300, ∞
– 1, 2, 3, 5, 8, 13, 21
– 1, 2, 4, 8, 16, 32

Using Story Points
Product Backlog
Cost: 13
We can see right away
Cost: 20
Cost: 20 Defect
1. Which work items cost the
Cost: 3
most
Requirement
Cost: 5 Constraint
Cost: 1
2. Total cost of all the work
Cost: 8
Cost: 13
3. Total cost to an iteration
Cost: 3
Cost: 100
Cost: 13

Economies of Estimation
Cost per story • The context in which A 13 in strategic
point in a planning is a
Development relative estimates remain
Team’s economy related different size
may be $100 than a 13 in
feature planning
Cost per story • Economies are different
point in an – Per planning level
executive An 8 in one
economy may be – For different teams team is not the
$1,000,000 same size as an
8 for a
Same company
different team
Planning Poker Rules
• Each estimator has a deck of estimation cards.
• Customer/Product Owner reads a story and it’s discussed briefly.
• Each estimator selects a card that’s 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
• Please don’t one”
– Broadcast opinions before
estimations are made “I am throwing a
– Show cards early 3”
“This is huge”
• Because it
– Causes reactive estimates “This will be a 5”
– 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 8.
• 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.

Owning a Product Backlog
Scrum Planning

Product Backlog Item Meta Data
Title: ...
As a . . .
I want . . .
So that . . .
Product Owner ___________
Bob
Development Team ___________

Alpha
Scenario: ...
Given . . .
When . . . Business Value ___________
13
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 isn’t always just revenue
Market share to capture
• Can be estimated or calculated Money to be saved
Improvement to
User Experience

Ordering the Product Backlog
• Risk
– Identify risk for items in the Backlog
– Do highest risk items first
Estimated ROI Index
• Return on Investment
𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑒𝑑 𝑉𝑎𝑙𝑢𝑒
– 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
– That’s 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
complete by a given date? be ready?

Product Backlog
Cost: 13
Cost: 20
Cost: 20
When will
Cost: 3
constraint A
Cost: 5
likely ship?
Cost: 1
Cost: 8
• Average Team Velocity = 32
• 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
ready in 8
Size: 2
Requirement B
Size: 8
weeks?
Requirement C All This
Size: 5
Constraint A
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
25 23
Best Case
20 Middle 3
Story Points
Avg 19
15 Likely Case
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
Top 3 Avg Middle 3 Avg Bottom 3
Estimate : 13 23 19 Avg 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 is Something Done?
 When the Task is complete
 When the Sprint is over
 When the customer says so
 When all agreed upon criteria for success are complete

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
• Keep checklists for Definition of Done at various levelsand

checkpoints
• 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
• Estimating Software Development
• Owning a Product Backlog
• 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 70
MIN
• Sprint Planning (15m)

• Sprint (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

Agility Requires Organizational Change
• Today’s 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

don’t change?
Each Team Answer 3
MIN
Why haven’t 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
organization’s transition
to agility with Scrum.
Grooming 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 groom 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
• Sprint Retrospective

Section Summary
Getting Ready
Starting

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

Monitoring Your Health

Make Visible Retrospective Commitments
Answer: Sprint # What we committed to for the next Sprint

What will do in the next Sprint?
3 All Increments shown in Sprint Review build
via automated build
• Keep these visible to all 4 New features will have corresponding unit
tests
• Keep a growing list of them
• Watch DoD grow over time
5 Tests will run as part of the automated build
processes
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?

Patterns of Healthy Scrum Teams

An Active Team Room

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

that time.”
B: “What’ll 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 Managing 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”

Don’t 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!

misses the Just working software!
point
• The product is ready to
No special effects
be deployed if needed
• 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
• Quarreling Product Owners are 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 Scrum’s effect?
• How can you help your supporters?

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 doesn’t work”.
• Realizing that it won’t be easy
• Knowing early failures often precede success
What does this mean to:

- Your organization?
- Your team?
- You?
Section Summary
• Monitoring Your Health
• Patterns of Healthy Scrum Teams
• Staying the Course

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

• You have 14 days to take the assessment
• 85% is a passing score
• The Scrum Open assessment is great practice
• Professional Scrum Master certification upon passing

Thank You
Scrum
On!

Slides PDF

Uploaded by

Document Information

Original Title

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

Slides PDF

Uploaded by

Copyright:

Available Formats

Professional Scrum

Professional Professional Professional

Professional Scrum Foundations Everyone

© 1993 - 2012 Scrum.org, All Rights Reserved 3

© 1993 - 2012 Scrum.org, All Rights Reserved 4

A mix of discussion and exercise

Focuses on delivering software

© 1993 - 2012 Scrum.org, All Rights Reserved 5

• Classroom Hours and Days

© 1993 - 2012 Scrum.org, All Rights Reserved 6

How effective are your current

© 1993 - 2012 Scrum.org, All Rights Reserved 8

© 1993 - 2012 Scrum.org, All Rights Reserved 11

• Make roughly even-sized teams of 3-5 members

• Post for all to see:

© 1993 - 2012 Scrum.org, All Rights Reserved 12

• You will show your Product in 30 minutes

• The Team chooses which requirements to meet

• The Team chooses how to

© 1993 - 2012 Scrum.org, All Rights Reserved 13

© 1993 - 2012 Scrum.org, All Rights Reserved 15

© 1993 - 2012 Scrum.org, All Rights Reserved 16

© 1993 - 2012 Scrum.org, All Rights Reserved 17

1. A Team commits to delivering working software

2. A time is scheduled to show that software

3. The Team creates the software

© 1993 - 2012 Scrum.org, All Rights Reserved 20

© 1993 - 2012 Scrum.org, All Rights Reserved 21

• All work is understood before • Frequent inspection and

• Follow the pre-determined • Outputs are often unpredictable

© 1993 - 2012 Scrum.org, All Rights Reserved 22

A network operations team receives Increments from Scrum

What is your advice to this team?

© 1993 - 2012 Scrum.org, All Rights Reserved 23

• We don’t know the exact outcomes

• Steps aren’t always repeatable

© 1993 - 2012 Scrum.org, All Rights Reserved 24

© 1993 - 2012 Scrum.org, All Rights Reserved 25

We all know what

© 1993 - 2012 Scrum.org, All Rights Reserved 26

Roles Artifacts Events

• Product • Increment • Sprint

© 1993 - 2012 Scrum.org, All Rights Reserved 28

Simple Scrum Thrives Here

Simple Complicated Complex

Business Value Risk

© 1993 - 2012 Scrum.org, All Rights Reserved 30

© 1993 - 2012 Scrum.org, All Rights Reserved 31

Business Value Risk

© 1993 - 2012 Scrum.org, All Rights Reserved 33

Scrum Master Service flows

© 1993 - 2012 Scrum.org, All Rights Reserved 34

• Optimizes the value of the Product

• Creates and maintains the Product Backlog

© 1993 - 2012 Scrum.org, All Rights Reserved 35

May Be May Not Be

• A personnel manager • The Scrum Master

© 1993 - 2012 Scrum.org, All Rights Reserved 36

• Creates the product Increment

• Operates in a series of Sprints

© 1993 - 2012 Scrum.org, All Rights Reserved 37

May Be May Also Be

© 1993 - 2012 Scrum.org, All Rights Reserved 38