Scrum Foundations

OFFICE OF DISTANCE AND ELEARNING
PgMO
Scrum Foundations
A Lightweight Agile Framework

PgMO
WHY AGILE FOR IT?
PROBLEM
High Failures Rate
Late Delivery
Low Quality
SOLUTION
Visibility
Intensive Collaboration
Simplicity

PgMO
DECISION-MAKING IN AN UNCERTAIN WORLD
Simple
Everything is known.
Complicated
More is known than not known.
Complex
More is unknown than known.
Chaotic
Very little is known.
REQUIREMENTS
TECHNOLOGY
CHAOS
COMPLICATED
COMPLICATED
SIMPLE
Close to
Certainty
Far from
Certainty
Far from
Certainty
COMPLEX

PgMO
Iteration 1 Iteration 2 Iteration 3 Iteration 4
THINK DIFFERENTLY
Which method delivers more value sooner to users?

PgMO
THE AGILE MANIFESTO
Individuals & Interactions
Working Software [Product]
Customer Collaboration
Responding to Change
Following a Plan
Comprehensive Documentation
Contract Negotiation
Processes & Tools

PgMO
1. Our highest priority is to
satisfy the customer
through early and
continuous delivery of
valuable software, products,
and services.
2. Welcome changing
requirements, even late
in the process. Agile
processes harness change
for the customer's advantage.
3. Deliver working software,
products, and services.
frequently, from a couple of
weeks to a couple of months,
with a preference to the
shorter timescale.
4. Business people and
technical people must work
together daily throughout
the project.
5. Build software, products,
and services around
motivated individuals.
Give them the environment
and support they need, and
trust them to get the job
done.
6. The most efficient and
effective method of
conveying information to and
within a team is face-to-face
conversation.
7. Working software/
product/service is the
primary measure of
progress.
8. Agile processes promote
sustainable paces and
processes. The sponsors,
technical people, and users
should be able to maintain a
constant pace indefinitely.
9. Continuous attention to
technical excellence and
good design enhances
agility.
10. Continuous attention to
technical excellence and
good design enhances agility.
11. The best architectures,
requirements, and designs
emerge from self-organizing
teams.
12. At regular intervals, the
team reflects on how to
become more effective, then
tunes and adjusts its
behavior accordingly.
12 Agile Principles

PgMO
TRAINING OUTLINE
Definition of Scrum
Scrum Theory
Scrum Values
The Scrum Team
1. The Product Owner
2. The Product Team
3. The Scrum Master
Scrum Events
4. The Sprint
5. Sprint Planning
5. Daily Scrum
6. Sprint Review
7. Sprint Retrospective
Scrum Artifacts
9. Product Backlog
10.Sprint Backlog
11.Increment
Transparency
Sprint Goal
Definition of "Done"
Monitoring Progress

PgMO
BACKLOG
Scrum Theory
Scrum Values
The Scrum Team
Scrum Events
Scrum Artifacts
Artifact Transparency
4

PgMO
SCRUM BOARD
PRODUCT BACKLOG SPRINT BACKLOG IN PROGRESS DONE
Sprint
Retrospective
Sprint
Review
Daily
Scrum
Sprint
Planning
The Sprint
Dev Team
Member
Scrum
Master
Product
Owner
Commitment
Courage
Focus
Openness
Respect
Product
Backlog
Sprint
Backlog
Product
Increment
Scrum
Theory
Artifact
Transparency
Non Team
Members

PgMO
BACKLOG REFINEMENT
Scrum Theory
What is Scrum?
Why use Scrum?
Empiricism
Scrum Principles
4

PgMO
SPRINT PLANNING
Scrum Theory
(2) What is Scrum?
(2) Why Scrum?
(1) Empiricism
(5) Scrum Principles
10
4

PgMO
SCRUM BOARD
Sprint
Retrospective
Sprint
Review
Daily
Scrum
Sprint
Planning
The Sprint
Dev Team
Member
Scrum
Master
Product
Owner
Commitment
Courage
Focus
Openness
Respect
Product
Backlog
Sprint
Backlog
Product
Increment
Scrum
Theory
Artifact
Transparency
What is
Scrum?
Why Scrum
Empiricism
Scrum
Principles
Non Team
Members

PgMO
PRODUCT BACKLOG
Sprint
Retrospective
Sprint
Review
Daily
Scrum
Sprint
Planning
The Sprint
Dev Team
Member
Scrum
Master
Product
Owner
Commitment
Courage
Focus
Openness
Respect
Product
Backlog
Sprint
Backlog
Product
Increment
Scrum
Theory
Artifact
Transparency
What is
Scrum?
Why Scrum
Empiricism
Scrum
Principles
Non Team
Members

PgMO
THE SCRUM FRAMEWORK

PgMO
THE GOLDILOCKS PRINCIPLE
Application of
a lightweight
process is the
fastest way to
success.

PgMO
WHY SCRUM?
1. Focus on delivery.
2. Urgency of time-bound constraints.
3. Team members own their work.
4. Continuous learning.
5. Clear roadmap to success.

PgMO
EMPIRICISM
Transparency
Inspection
Adaptation
Repeat
Until…
Identify
Opportunity
Understand
Desired
Outcome
Evaluate
Possible
Solutions
Build
Increment
Deploy &
Measure

PgMO
THE SCRUM PRINCIPLES
Empirical Process
Control - This principle
emphasizes the core
philosophy of Scrum based
on the three main ideas of
transparency, inspection,
and adaptation.

PgMO
Self-organization - This
principle focuses on
knowledge workers who
deliver significantly greater
value when self-organized,
resulting in better buy-in
and shared ownership as
well as an innovative and
creative environment more
conducive to growth.

PgMO
Collaboration - This
principle focuses on the
three core dimensions
related to collaborative
work: awareness,
articulation, and
appropriation. It also
advocates project
management as a shared
value-creation process.

PgMO
Value Based
Prioritization - This
principle highlights the focus
of Scrum to deliver
maximum business value,
from beginning early in the
project and continuing
throughout.

PgMO
Timeboxing - This principle
describes how time is
considered a limiting
constraint in Scrum, and
used to help effectively
manage project planning
and execution. Time-boxed
elements in Scrum include
Sprints, Daily Standup and
all meetings.

PgMO
Iterative Development -
This principle defines
iterative Product and
emphasizes how to manage
change and build products
that satisfy customer needs.
It also delineates the PO's
and organization's
responsibilities related to
iterative Product.

PgMO
BACKLOG REFINEMENT
Scrum Theory
Scrum Values
The Scrum Team
Scrum Events
Scrum Artifacts
Artifact Transparency
10
4

PgMO
SPRINT PLANNING
Scrum Theory
Scrum Values
(1) Openness
(1) Courage
(1) Respect
(1) Focus
(1) Commitment
(5) Discussion
10
4

PgMO
SCRUM BOARD
Sprint
Retrospective
Sprint
Review
Daily
Scrum
Sprint
Planning
The Sprint
Dev Team
Member
Scrum
Master
Product
Owner
Commitment
Courage
Focus
Openness
Respect
Product
Backlog
Sprint
Backlog
Product
Increment
Artifact
Transparency
Non Team
Members

PgMO
THE FIVE SCRUM VALUES
The Scrum Team
and its
stakeholders agree
to be open about
all the work and the
challenges with
performing the
work.
OPENNESS

PgMO
OPENNESS
For Scrum to work as intended, it involves—nay,
it demands transparency and openness.

PgMO
MOOSE ON THE TABLE
What are your team’s impediments to
openness?
What keeps you from being more
open with stakeholders?
What organizational norms need to
be broken to increase openness?

PgMO
The Scrum team
and its
stakeholders agree
to be open about
all of the work and
the challenges with
performing the
work.
OPENNESS

PgMO
SCRUM BOARD
Sprint
Retrospective
Sprint
Review
Daily
Scrum
Sprint
Planning
The Sprint
Dev Team
Member
Scrum
Master
Product
Owner
Product
Backlog
Sprint
Backlog
Product
Increment
Artifact
Transparency
Commitment
Courage
Focus
Openness
Respect
Non Team
Members

PgMO
Scrum Team
members have the
courage to do the
right things and
work on tough
problems.
COURAGE

PgMO
Scrum Team members respect
each other to be capable,
independent people.
RESPECT

PgMO
Everyone focuses
on the work of the
Sprint and the
goals of the Scrum
Team.
FOCUS

PgMO
People personally
commit to
achieving the goals
of the Scrum Team.
COMMITMENT

PgMO
Successful use of
Scrum depends
on people
becoming more
proficient in living
these five values.
OPENNESS
COURAGE
RESPECT
FOCUS
COMMITMENT

PgMO
SPRINT PLANNING
The Scrum Team
(5) Dev Team Member
(15) Scrum Master
(15) Product Owner
(5) Non-Team Members
10
4

PgMO
BACKLOG REFINEMENT
The Scrum Team
(7) Scrum Master
(13) Product Owner
• (3) Video
• (1) Quote
• (2) Chart
• (3) You Might Be
• (3) Responsibilities
• (1) Quote
(5) Product Team Member
10
4

PgMO
SCRUM BOARD
Sprint
Retrospective
Sprint
Review
Daily
Scrum
Sprint
Planning
The Sprint
Dev Team
Member
Scrum
Master
Product
Owner
Product
Backlog
Sprint
Backlog
Product
Increment
Artifact
Transparency
PO Video
Non Team
Members

PgMO
SCRUM ROLES
• The holder of
product value.
• Determines what
needs to be
done.
• Sets priorities to
deliver high
value.
Product
Owner
• The servant
leader.
• Protects the
scrum process.
• Prevents
distractions by
removing
impediments.
Scrum
Master
• The self-
organizing
group.
• Takes on work
and decides how
to do deliver
chunks of work
in frequently
increments.
Product
Team

PgMO
THE SCRUM MASTER

PgMO
THE SCRUM MASTER
The Scrum Master is a servant leader responsible for the
implementation of scrum. Service includes:
PRODUCT OWNER
• Refinement
Techniques
• Educating Team on
Backlog Management
• Ensure PO maximizes
Value
• Facilitate Events as
Needed
TEAM
• Coach in Cross-
Functionality and Self-
Organization
• Help Understand
Value
• Remove Impediments
• Arrange Events as
Needed
ORGANIZATION
• Coach Scrum Adoption
• Help Management
Understand Empirical
Product Product
• Suggest
Organizational
Changes
• Improve Scrum

PgMO
THE SCRUM MASTER
Responsibilities & Characteristics
• Responsible for helping the team deliver work to the Product Owner
• Makes sure the team can meet its commitments by removing any impediments they face, including
Managing dependencies, escalating blockers that they cannot remove themselves
• Facilitates process & meetings (i.e. Reviews, Stand Ups, Planning, Estimation, Scheduling,
Prioritization)
• Makes sure the team is fully functional, productive and improving quality
• Shields the team from distractions and interferences (including the Product Owner)
• Enables close co-operation across all roles and functions, removes barriers
• Responsible for reporting progress, including producing standard outward-facing artifacts
• Manages Product Owners expectations of the team
• Responsible for keeping time and quality requirements

PgMO
THE PRODUCT OWNER

PgMO
SCRUM BOARD
Sprint
Retrospective
Sprint
Review
Daily
Scrum
Sprint
Planning
The Sprint
Dev Team
Member
Product
Owner
Product
Backlog
Sprint
Backlog
Product
Increment
Artifact
Transparency
Non Team
Members

PgMO
THE PRODUCT OWNER
The Product Owner is responsible for maximizing the value
of the product and the work of the team by ensuring there is
a steady stream of well-defined, valuable, and prioritized
work available for the scrum team to work on.
BACKLOG
• Clearly expressing
Product Backlog items;
• Ordering the items in
the Product Backlog to
best achieve goals and
missions.
VALUE
• Optimizing the
value of the
work the
Product Team
performs;
TRANSPARENCY
• Ensuring that the Product Backlog is visible,
transparent, and clear to all, and shows what
the Scrum Team will work on next; and,
• Ensuring the Product Team understands items
in the Product Backlog to the level needed.

PgMO
THE PRODUCT OWNER
You might already be a product owner if…
• The “buck stops with you” in regards to the product or
service success.
• You know the product or service intimately; you know
what it is “all about” to the customers.
• You are empowered to make decisions regarding the
product or service features and releases.
• You are in charge of changes to the product or service, or
in charge of getting them approved, including EoL.

PgMO
DETERMINING VALUE
MUST
If it doesn’t do
that, it’s
worthless to me.
We really need
something to
help us do this.
SHOULD
I think it should
be able to do
that.
It should also do
these things.
It should be easy.
COULD
I would like it to
be able to do
that.
It would be great
if the product
also did this.
Users have a lot to say…

PgMO
THE PRODUCT OWNER
Responsibilities & Characteristics
• Voice of the Stakeholders, represents the business
• Manages stakeholder relationships, communications & expectations
• Accountable for the vision, scope, scale, and success of the product
• Defines key features of the product & success criteria
• Continuously refines requirements, Decides on release date, content and budget
• Sets delivery schedule by managing the backlog – creates and updates the
release plan, including prioritization
• Accepts and rejects work in the sprint reviews
• Takes advice from the team on Backlog Dependencies
• Single point of contact for the product (including New requirements
Prioritizing backlog items)

PgMO
BACKLOG REFINEMENT
The Scrum Team
(7) Scrum Master
(13) Product Owner
(5) Product Team Member
10
4

PgMO
SCRUM BOARD
Sprint
Retrospective
Sprint
Review
Daily
Scrum
Sprint
Planning
The Sprint
Dev Team
Member
Product
Backlog
Sprint
Backlog
Product
Increment
Artifact
Transparency
Non Team
Members
Dev Team
Member

PgMO
TEAM MEMBERS & NON-MEMBERS
Product TEAM MEMBERS
Everyone who is working
daily to design, develop,
and test the product or
service.
Team should encompass
everyone needed to do the
work, not inform the work.
NON-TEAM MEMBERS
Stakeholders
Managers
Subject Matter Expert (SME)

PgMO
THE Product TEAM MEMBER
Are you doing the work of developing a product or service?
• Self Organizing
• Cross Functional
• May Have Specialized Skills
or Areas of Focus
• Accountable for the Work
Optimal Product Team size is small enough to remain
nimble and large enough to complete significant work
within a Sprint.

PgMO
NON-TEAM MEMBERS
There are other people who may be involved in projects, but
are not Scrum team members. They include:
• Stakeholders
• Subject Matter Experts (SMEs)
• Members of Other Teams
• Leadership
• Project Manager

PgMO

PgMO
BACKLOG REFINEMENT
Scrum Events
The Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
10
4

PgMO
BACKLOG REFINEMENT
Scrum Events
(5) The Sprint
(5) Sprint Planning
(5) Daily Scrum
(5) Sprint Review
(10) Sprint Retrospective
10
4

PgMO
THE SPRINT
Who: The Product Owner, Scrum Master, & Dev Team
What: Container (timebox) for all other sprint events.
Why: Scrum events are used to create regularity and to
minimize the need for non-scrum meetings.
When: Scrum processes are cyclical, repeating in regular
cycles.
Timebox: One to four weeks with the preference to the
shorter time. The less detail known about the work, the
shorter the sprints should be.

PgMO
THE SPRINT “RULES”
• No changes are made that would endanger the Sprint
Goal.
• Quality goals do not decrease.
• Scope may be clarified and re-negotiated between the
Product Owner and Product Team as more is learned.
Each Sprint may be considered a project with no more than a one-month
horizon. Like projects, Sprints are used to accomplish something. Each Sprint
has a definition of what is to be built, a design and flexible plan that will guide
building it, the work, and the resultant product.

PgMO
WHOWHAT
WHYWHEN
TIMEBOX

PgMO
SPRINT PLANNING
What: The sprint goal is created and work to be performed
in the Sprint is planned at the Sprint Planning.
Why: To answer: (1) What can be delivered in the
Increment resulting from the upcoming Sprint? (2) How will
the work needed to deliver the Increment be achieved?
When: At the beginning of each new sprint.
Timebox: Maximum of eight hours for a one-month Sprint,
down to ½ hour for a weekly sprint.

PgMO
SPRINT PLANNING “RULES”
• Work planned for the first days of the Sprint by the
Product Team is decomposed by the end of this meeting
(The What).
• The Product Team self-organizes to undertake the work
in the Sprint Backlog, both during Sprint Planning and as
needed throughout the Sprint (The How).
Having set the Sprint Goal and selected the Product Backlog items for the
Sprint, the Product Team decides how it will build this functionality into a “Done”
product Increment during the Sprint. The Product Backlog items selected for this
Sprint plus the plan for delivering them is called the Sprint Backlog.

PgMO
DAILY SCRUM
Who: Product Team, Scrum Master (optional)
What: Inspect progress toward the Sprint Goal and inspect
how progress is trending toward completing the work in the
Sprint Backlog, as well as identify impediments to Product
for removal.
Why: Synchronize activities and create a plan for the next
24 hours.
When: Daily
Timebox: 15 Minutes

PgMO
DAILY SCRUM “RULES”
During the meeting the Product Team members explain:
• What did I do yesterday that helped the Product Team
meet the Sprint Goal?
• What will I do today to help the Product Team meet the
Sprint Goal?
• Do I see any impediment that prevents me or the
Product Team from meeting the Sprint Goal?
This is a key inspect and adapt meeting. The Daily Scrum is held at the same
time and place each day to reduce complexity.

PgMO
SPRINT REVIEW
Who: Entire Scrum Team and Customer(s) if possible.
What: The presentation of the finished Increment.
Why: Intended to elicit feedback and foster collaboration.
When: A Sprint Review is held at the end of the Sprint.
Timebox: This is a four-hour time-boxed meeting for one-
month Sprints. For shorter Sprints, the event is usually
shorter. The Scrum Master ensures that the event takes
place and that attendants understand its purpose. The
Scrum Master teaches all to keep it within the time-box.

PgMO
SPRINT REVIEW “RULES”
• The Product Owner explains what Product Backlog items have been “Done” and what has
not been “Done”;
• The Product Team discusses what went well during the Sprint, what problems it ran into, and
how those problems were solved;
• The Product Team demonstrates the work that it has “Done” and answers questions about
the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely
completion dates based on progress to date (if needed);
• The entire group collaborates on what to do next, so that the Sprint Review provides
valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed what is
the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next
anticipated release of the product.

PgMO
SPRINT RETROSPECTIVE
What: Opportunity for the Scrum Team to inspect itself and
create a plan for improvements to be enacted during the
next Sprint.
Why: This is the adaptation to the inspection of the Scrum
Team itself. The Sprint Retrospective provides a formal
opportunity to focus on inspection and adaptation.
When: After the Sprint Review & before the next planning.
Timebox: About 30-45 minutes per week of sprint length.

PgMO
SPRINT RETROSPECT “RULES”
The Scrum Master ensures that the event takes place and that attendants
understand its purpose. The Scrum Master teaches all to keep it within the time-
box. The Scrum Master participates as a peer team member in the meeting from
the accountability over the Scrum process. The purpose of the Sprint
Retrospective is to:
• Inspect how the last Sprint went with regards to people,
relationships, process, and tools;
• Identify and order the major items that went well and
potential improvements; and,
• Create a plan for implementing improvements to the way
the Scrum Team does its work.

PgMO
REVIEW VS. RETROSPECTIVE
Attendees:
Review
• Stakeholders
• Customers
• Scrum Team
• Leadership
Retrospective
• Scrum Team

PgMO
WHAT’S ON YOUR CALENDAR?
Weeks Sprint Events in Hours Work Allocations
Sprint Sprint Planning Daily Stand-Up Sprint Review Sprint Retrospective Total Work Hours Time in "Meetings" Time to Work
1 2 0.25 1 0.75 4 40 10% 90%
2 4 0.25 2 1.5 7.75 80 10% 90%
3 6 0.25 3 2.25 11.5 120 10% 90%
4 8 0.25 4 3 15.25 160 10% 90%
10%
90%
SCRUM TIME ALLOCATIONS
Scrum Events "Real" Work
1. Get our your phones.
2. Open your calendar app.
3. Add up the number of hours you have
scheduled for planning, problem solving,
updating, and reporting on the work you and
your team does (non “real” work time).
4. Divide by 40 to get percent.

PgMO
SPAGHETTI TOWER PROJECT
Materials per Team
• 20 Pieces of Spaghetti
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Tallest structure possible that can hold the marshmallow up (marshmallow cannot touch floor or table top).
Rules
• You must follow the project management methodology assigned or chosen by your group to the end.
• You may draw plans out on this paper. You may NOT look ideas or solutions up on the Internet.
• Your tower must not depend on a team member to hold it up. This means when “hands off” is called, all
hands must be removed from the tower, ready or not.
• You will have exactly 18 minutes to do all the planning and work.
Chaos Scrum Traditional
On your mark, get set, go! 2 Plan
7 Sprint
2 Plan
7 Sprint
6 Initiation and Planning
13 Execute, Monitor, & Control
Project Methodologies

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
18

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
17

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
16

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
15

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
14

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
13

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
12

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
11

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
10

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
9

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
8

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
7

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
6

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
5

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
4

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
3

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
2

PgMO
Materials per Team
• 1 Marshmallow
• 1 Yard Tape
• 1 Yard String
Requirements
Rules
7 Sprint
2 Plan
7 Sprint
1

PgMO
TIME HAS RUN OUT!
FREEZE!

PgMO
STAND-UP DEBRIEF
PRODUCT (Sprint Review)
1. Did you achieve the
goal?
2. Was the scope
satisfactory?
3. Is the quality high?
PROCESS (Retrospective)
1. Did you spend enough time
planning?
2. Were you able to make
appropriate changes to your
plan to achieve your goal in
the allotted time? (Agility)
3. How was the teamwork?

PgMO
SCRUM ARTIFACTS
• Product Backlog
• Sprint Backlog
• Increment
• Transparency
• Definition of Done

PgMO
PRODUCT BACKLOG
The Product Backlog is:
• An ordered list of everything that might be needed in the
product.
• The single source of requirements for any changes to be
made to the product.
• The Product Owner is responsible for the Product
Backlog, including its content, availability, and ordering
• A Product Backlog is never complete.

PgMO
PRODUCT BACKLOG
Make sure your product backlog is D.E.E.P.
Detailed (Appropriately)
Estimated
Emergent
Prioritized
Current
Sprint
Next
Release
Future
Releases
+
-
DETAIL

PgMO
BACKLOG REFINEMENT
What’s in your backlog?
An ordered list of features that might be delivered.
RELEASE PLANNING

PgMO
SPRINT BACKLOG
A slice off the
top of the
backlog.
Looks nice in
theory, but, who
is doing what,
when, and how?

PgMO
THE SPRINT GOAL
A sprint backlog is a forecast of the work that the team will
need to do to meet the sprint goal.
• Supports Prioritization
• Creates Focus
• Facilitates Teamwork
• Helps Obtain Relevant Feedback
• Makes it Easier to Analyze Feedback
• Supports Stakeholder Communication

PgMO
SPRINT GOAL IMPORTANCE
The sprint backlog is wholly owned by the Product
team, while the goal is shared between them and the
product owner. It must be agreed by them during
sprint planning. Therefore the goal is not a component
of the sprint backlog, but is a point of reference
around which the backlog may be re-planned and
changed.
- Ian Mitchell, Chief Scientist, proAgile Ltd.
“

PgMO
PRODUCT CANVAS
NAME GOAL METRICS
TARGET GROUP BIG PICTURE PROJECT DETAILS
What is the name of your product? What are you creating this sprint? How will you measure success?
Who are you creating this for? How does this iteration fit into
the larger product or service
roadmap?
How will your customers experience this product? What will it look like?
What will it help them do? What will it help them be?

PgMO
SPRINT BACKLOG
Well planned by the
scrum team!
DETAILED
ESTIMATED
EMERGENT
PRIORITIZED

PgMO
Evolves
and Changes
Analyze and
Update
Slice of Value off
Top of BacklogProvide Data and
Feedback
FEEDBACK LOOP
Product
Backlog
Product
Increment
Users
Customers
Stakeholders
Product
Owner
Team

PgMO
ESTIMATING WORK
“STORY” POINTS
• T-Shirt Sizes
• Swimlane Sizing
• Planning Poker
• Fibonacci
“NO” ESTIMATES
• Decomposing Work
• Same-Sized

PgMO
ESTIMATE SIZE  DERIVE DURATION
Examples:
1500 LBS 3 PPM 8.33 HRS
22 Miles 30 MPH 40 Minutes
1 Gallon 3 GPD 5.33 Days
Size Velocity Duration

PgMO
1 2 3 4
RELEASE PLANNING
Incremental or Iterative?

PgMO
MONITORING PROGRESS
What?
At any point in time, the total work remaining to reach a goal can
be summed.
Who? When?
The Product Team tracks this total work remaining at every Daily
Scrum to project the likelihood of achieving the Sprint Goal.
Why?
By tracking the remaining work throughout the Sprint, the Product
Team can manage its progress.

PgMO
UNDERSTANDING THE “BURN”
Teams use the sprint Burndown chart to track the product
Product effort remaining in a sprint.
General speaking the Burndown chart should consist of:
• X axis to display working days
• Y axis to display remaining effort
• Ideal effort as a guideline
• Real progress of effort

PgMO
RELEASE BURNDOWN CHART

PgMO
TAKEAWAYS
Solving User Problems
Short Feedback Loops
Value Focused vs. Task Focused
Empirical Data-Based Decisions
Variable Granularity of Planning
Flexible Scope
Responsible Individuals

Scrum Foundations

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Scrum Foundations

Similar to Scrum Foundations (20)

More from Robin Surland

More from Robin Surland (20)

Recently uploaded

Recently uploaded (20)

Scrum Foundations

Editor's Notes