Scrum Boot Camp Slides

Scrum Boot Camp
Construx®
Scrum Boot Camp

Succeeding with Scrum
Jenny Stuart
Vice President of Consulting
Jenny.stuart@construx.com
www.construx.com
Construx®
Copyright Notice
This presentation is copyright © 2013-2022 Construx Software Builders, Inc. All Rights Reserved.
No part of this seminar may be reproduced or transmitted in any form or by any means without the
written permission of Construx Software Builders, Inc.
Third-party brands and names may be claimed as the property of others.
Portions of this presentation’s base materials are taken from The Scrum Guide™ 2020 and are used under
Creative Commons Attribution-Share Alike license from Scrum.org and Scrum Inc.
2 Construx®
© Construx Software, Inc. 1

Scrum Boot Camp
Course Vision
For: New adopters OR teams and organizations seeking to improve their adoption of
Scrum
Who: Want to understand the Scrum framework and practices for successful Scrum
adoption and use
Scrum Boot Camp Two-day course with hands-on exercises

is a:
That: Teaches the Scrum framework fundamentals and effective practices at the team
and enterprise levels.
Unlike: Many other courses in the marketplace
This course: Prescribes a flexible, tool-box approach that is consistent with Scrum Guide
2020 and provides PDU credits.
3 Construx®
Why are You Here?
Use sticky notes to state your expectations for this seminar in the story format shown below
Use one sticky note per expectation
As a… <your role>
I want… <your goal or desire>
So that… <value or benefit>
4 Construx®

Scrum Boot Camp
Contents
1. Agile Fundamentals
2. Scrum Overview
3. Scrum Roles in Detail
4. Populate a Product Backlog
5. Estimate and Order a Product Backlog
6. Plan a Sprint
7. Execute a Sprint
8. Wrap Up a Sprint
9. Summary
5 Construx®
Course Objectives
After completing this course, you will be able to:

1. Understand how Scrum fits within Agile
2. Demonstrate an understanding of the Scrum framework
3. Apply effective practices to perform Scrum events and create Scrum artifacts
4. Understand the user story format and be able to write stories
5. Estimate using story points and know what velocity is and can be used for
6. Know how to plan, execute, and track progress of a Sprint
7. Appreciate how retrospectives and reviews are used to obtain feedback
6 Construx®

Scrum Boot Camp
Proposed Working Agreements
1. Class starts at 9am, and ends by 5pm

2. There will be a 10-minute break each hour
3. We will be punctual
4. We will leave computers and phones off outside of breaks and lunch
5. We will have a retrospective (~10 minutes) at the end of today
6. Default lunch is 60 minutes at noon, but the class may agree by consensus to a shorter lunch or
different start time
Anything else?...
7 Construx®
Construx®
Agile Fundamentals
8 Construx®

Scrum Boot Camp
Section Story
Story Acceptance Criteria:

As a Student of Scrum, 1. Students understand the Agile manifesto
and Agile Principles
I want to be able to describe Agile, Agile values,
and the benefits of adopting an Agile approach 2. Students know the difference between Agile
and Scrum
So that I can help support a high-fidelity
adoption of Scrum on my team or within my
organization
9 Construx®
Task Board
To Do Doing Done
Agile Principles
Agile vs. Scrum
10 Construx®
10

Scrum Boot Camp
What Does Agile Really Mean?
A·gile [ah-jile]
-adjective
1. Possessing the ability to effectively respond to change
Agile development refers to a group of software development methodologies based on iterative

development, where requirements and solutions evolve through collaboration between self-organizing
cross-functional teams.
11 Construx®
11
The Agile Manifesto
The original Agile Manifesto (2001) reads:

“We are uncovering better ways of developing software by doing it and helping others do it. Through
this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
Source: http://agilemanifesto.org/
12 Construx®
12

Scrum Boot Camp
Principles Behind the Agile Manifesto

Satisfy the customer through early, continuous delivery
Welcome changing requirements, even late
Deliver working software frequently
Business people and developers collaborate daily
Build projects around motivated individuals
Convey info via face-to-face conversation
Primary progress measure: working software
Maintain a constant pace indefinitely
Continuously demonstrate technical excellence
Simplify: maximize amount of work not done
Self-organize to produce better software artifacts
Retrospect and tune behavior to be more effective
Source: Adapted from Langr & Ottinger, 2011
Construx®
13
Task Board
To Do Doing Done
Scrum vs. Agile
Agile Principles
14 Construx®
14

Scrum Boot Camp
The Big Agile Umbrella
Practices Methodologies & Approaches

• Test-Driven Development (TDD) • Scrum
• Continuous Integration (CI) • Feature-Driven Development (FDD)
• Time boxing • Crystal Clear
• Pair programming • Extreme Programming (XP)
• User stories • Kanban
• Planning Poker • Evolutionary Delivery (Evo)
• Burn-down chart • Lean Development
• Etc. • Etc.
15 Construx®
15
Scrum Has Won the Agile Wars

3% 1% 1%
4%
7%
Scrum
Scrumban
8% Cust om Hybrid
Scrum/XP
Kanban
9% Iterative
57%
Don't Kn ow
Lean Startup
10% XP
Source: Version One 14th Annual State of Agile Report
16 Construx®
16

Scrum Boot Camp
Why Choose Scrum?
“Scrum, done even fairly well, is a good framework… It’s good to

have a strong connection to the business deciding what needs to be
done, and what needs to be deferred. It’s good to have all the skills
you need to build the product right on the team. It’s good to build a
tested tangible product every couple of weeks, and it’s good to show
it to stakeholders, and it’s good to review how things went and how
to improve them.” – Ron Jeffries
Scrum has clearly emerged as the best of

breed of the Agile practices. We've seen
many organizations succeeding with
Scrum. – Steve McConnell
17 Construx®
17
Reflections
1. What is Agile?
2. What is the first Agile Principle?
3. Why is Scrum so predominate in the industry today?
4. Name one situation in which you would not use Scrum
18 Construx®
18

Scrum Boot Camp
Task Board
To Do Doing Done
Agile Principles
Scrum vs. Agile
19 Construx®
19
Construx®
Scrum Overview
Framework, Roles, Events, Artifacts, and Rules
20 Construx®
20

Scrum Boot Camp
Section Story
Story Acceptance Criteria:

As a Student of Scrum, 1. Scrum and related terms defined
I want to understand how Scrum works at a high 2. Students understand Scrum’s roles, events,
level and artifacts at a high level
So that I can succeed in learning Scrum at Depth

in the rest of the class
21 Construx®
21
What is Scrum?
Scrum is a framework within which people can address complex adaptive problems, while productively
and creatively delivering products of the highest possible value
• Lightweight
• Simple to understand
• Difficult to master
Scrum is an excellent way to learn to be Agile because it contains a good set of prescribed roles,
events, artifacts, and rules that embody Agile Principles
Software development: Rugby match or bucket brigade?
Adapted from Scrum Guide 2020
22 Construx®
22

Scrum Boot Camp
Why Scrum Works
Scrum works because it:

• Is simple to understand
• Is based upon sound empirical principles
• Empowers people, and holds them responsible
• Exposes everything
• Demands commitment
• Confronts you to improve the way you work
23 Construx®
23
The Scrum Framework
Roles Events Artifacts
1. Product Owner 1. Sprint 1. Product Backlog

2. Developers 2. Sprint Planning 2. Sprint Backlog
3. Scrum Master 3. Daily Scrum 3. Increment
4. Sprint Review
5. Sprint Retrospective
Scrum’s rules bind together the roles, events,

Rules
and artifacts, in order to govern the
relationships and interactions among them.
24 Construx®
24

Scrum Boot Camp
Adopting Scrum: Decisions, Decisions…

Roles
1. Who will staff the Scrum roles?
2. What about existing roles such as project managers, product managers, program managers,
development managers, etc.
Events
3. When will we hold our refining meetings?
4. How will Daily Scrums be conducted?
5. How long is a Sprint?
6. How will Sprint and overall project progress be tracked and made visible?
Artifacts and More
7. What goes on the Project Backlog?
8. What is your “definition of done”?
25 Construx®
25
Scrum at a Glance
Sprint Planning
Product Daily Scrum
Backlog
Sprint
backlog ? ? ?
development
work Sprint Sprint
Review Retrospective
Increment
26 Construx®
26

Scrum Boot Camp
Product Backlog
The Product Backlog is an ordered list of Product Backlog Items (PBIs)

Product
Backlog • There is only one Product Backlog, and it must be ordered
• The Product Backlog contains the current understanding of
everything that might be needed for the product
PBIs • PBIs are often captured as User Stories, but can also be features,
functions, requirements, enhancements, defect fixes, etc.
• The Product Backlog evolves continuously with the needs of the
customers, market, Developers, and other stakeholders
The Product Owner is responsible for the Product Backlog’s content, PBI
ordering, and availability
27 Construx®
27
Sprint
A Sprint is a container that consists of Sprint Planning, Daily Scrums, the development work, the Sprint
Review, and the Sprint Retrospective
• Each Sprint delivers something that is usable and potentially releasable
• Sprints can be no longer than one calendar month; this ensures regular value deliveries and limits
program risk
Sprint Planning
Product Daily Scrum
Backlog
Sprint
backlog ? ? ?
development
work Sprint Sprint
Review Retrospective
28 Construx®
28

Scrum Boot Camp
Typical Sprint Timeline & Ranges
Sprint Retrospective
Sprint Execution
Sprint Planning
Sprint Review
¾-3 hours
4-18 days
1-4 hours
2-8 hours
Overall Sprint
1-4 weeks
= Daily Scrums
29 Construx®
29
Sprint Planning
Sprint Planning 1. The Product Owner discusses the upcoming Sprint’s objective,
Product and the Product Backlog Items needed to achieve that objective
Backlog
Sprint 2. The Developers forecasts what portion of those Product Backlog
backlog Items it can deliver during the next Sprint
3. The Developers creates a Sprint Backlog through discussion of
how that chosen work will get done
4. A Sprint Goal captures why the team is building the increment
to ensure alignment
1. What can be done this Sprint?

2. How will the chosen work get done?
30 Construx®
30

Scrum Boot Camp
The Definition of Done

Definition of Done (example only)
Good Scrum Teams establish a Definition of Done q Code conforms to our standards
(DoD)
q Code builds without errors or warnings
“Done” establishes a shared quality bar that must
be accomplished to consider the work complete q Static code analysis pass
The DoD should be as close as possible to q Unit tests pass with 80% statement
“potentially releasable” as the team can do today coverage
The DoD ensures that an increment is judged q Functional test cases pass
complete or not based on complete, consistent,
q Selected regression test cases pass
transparent criteria
q No new defects
q APIs documented
q Release notes and help documentation
updated
31 Construx®
31
Lab: What’s in Your DoD?
Learning Objectives:
1. Understand what elements should be in a Definition of Done
2. Create and initial Definition of Done (or refresh your current one)
Instructions:
• In groups of 3-5 people, review the example Definitions of Done and then create your own
Time Box:
• 15 minutes
32 Construx®
32

Scrum Boot Camp
Daily Scrum
Daily Scrum
The Developers meets every day no more than 15 minutes to inspect the
work done since the previous Daily Scrum and plan for the next 24 hours
The meeting must be held at the same time each day, and covers:
1. Inspection of each team member’s progress towards the Sprint
development Goal
work
2. Plans for each team member for the next 24 hours in pursuit of
the Sprint Goal
3. Identification of any impediments
The Daily Scrum provides
accountability, Attendance by Developers is mandatory
transparency, and
Others may attend, but only Developers may participate
efficient communication
33 Construx®
33
Sprint Review
The Sprint Review is a meeting between the Developers and the Product Owner at
? ? ?
the end of the Sprint
The Sprint Review closes the loop with Sprint Planning by answering these questions:
1. What is done and what is not?
Sprint
Review 2. Does the completed work meet expectations?
3. How should what has been completed (and not) influence what should be
The Sprint Review developed next?
intended to elicit
feedback and foster The meeting may include customers, stakeholders, and other interested parties in
collaboration addition to the Developers, and is time-boxed to 4 hours*
Output of the Sprint Review includes a revised Product Backlog
*Assuming 1-month Sprints. For shorter Sprints, the Sprint Review is usually shorter.
34 Construx®
34

Scrum Boot Camp
Sprint Retrospective
The Sprint Retrospective occurs between the Sprint Review and the start of the
next Sprint
The team evaluates its performance in several areas, including people,
Sprint relationships, process, and tools
Retrospective
The Sprint Retrospective is time-boxed to 3 hours*, and is led by the Scrum
Master
The Sprint Retrospective
provides a formal The team identifies what went well and what could be improved, and creates a
opportunity to reflect, plan for improving how the work gets done in the next Sprint (and beyond)
inspect, and adapt
*Assuming 1-month Sprints. For shorter Sprints, the Sprint Retrospective is usually shorter.
35 Construx®
35
Lab: Adopting the Scrum Workflow
1. Recognize gaps between your current process and high-fidelity Scrum use
2. Identify improvement opportunities for your team and organization
Instructions:
• See handout
Time Box:
• 10 minutes
36 Construx®
36

Scrum Boot Camp
Reflections
1. Name the 3 roles, 5 events, and 3 artifacts of Scrum

2. (T/F): A Scrum Sprint ends with the Sprint Review
3. (T/F): A Sprint is typically between 1 and 4 weeks in length
4. (T/F): A Sprint is only finished when the Sprint Backlog has been completed
5. (T/F): A Sprint always results in a production release
6. What is the purpose of …
• Sprint Planning
• Review
• Retrospective
• The DoD
37 Construx®
37
Construx®
Scrum Roles in Detail

Scrum Master
Product Owner
Developers
38 Construx®
38

Scrum Boot Camp
Section Story
Story: Acceptance Criteria:

As a Student of Scrum, 1. Students understand Scrum roles in detail
I want to understand the various Scrum roles, 2. Students know the attributes of an effective
how they interact, and the attributes of an Scrum team
effective Scrum team
So that I can help my team adopt or improve its
use of Scrum
39 Construx®
39
Task Board
To Do Doing Done
Product Owner
Developers
Scrum Master
40 Construx®
40

Scrum Boot Camp
The Product Owner
The Product Owner (PO) is the sole person responsible for maximizing the value of the product resulting
from work of the Developers
In addition, the PO is:
• A proxy for all project stakeholders
• The person responsible for the Product Backlog including new PBIs, PBI modifications, and
changes to PBI order
• The only person permitted to select Product Backlog items for consideration by the Developers in
a Sprint
• The key resource for explaining Product Backlog items and answering questions
• Connects the team to the vision/mission/north star
For the Product Owner to succeed, the entire organization must respect their decisions.
41 Construx®
41
A Good Product Owner
A Good Product Owner is An Ineffective Product Owner

Knowledgeable about the product and the market Wants to control how the team works
Able to clearly define product requirements Doesn’t understand enough about software
development to be able to evaluate the tradeoffs
More concerned with ‘what’ than ‘how’
Is rarely available to the team due to other obligations
Always available to the team to resolve ambiguity on (travel, multiple responsibilities, etc.)
backlog items Ignores Scrum processes and rules if they seem to
hinder “firefighting”
Willing to listen to the team’s technical guidance
Doesn’t know much about Scrum and doubts it will
Unwilling to compromise on acceptance criteria issues, work
including quality or completeness
Lacks trust in the team’s ability or maturity
Able to put project success over personal ego
gratification… doing the right thing over being right
42 Construx®
42

Scrum Boot Camp
Task Board
To Do Doing Done
Product Owner
Developers
Scrum Master
43 Construx®
43
Characteristics of the Developers
No one, including the Scrum Master and Product Owner, can tell the Developers how
Self-organizing
to organize itself or implement PBIs
The Developers must possess the collective knowledge and skills it needs to create
Cross-functional
the product
No Titles Everyone shares the same title: Developer
Developers may have specialized skills and areas of focus, but accountability always
Specialization
belongs to the Developers as a whole
There are no sub-teams focused on specific domains such as testing or business
No Sub-teams
analysis; the Developers is the only team
3– 9 people, to avoid skill constraints on the small end and excessive complexity on
Small Size
the large end
44 Construx®
44

Scrum Boot Camp
Well-Formed Teams
The characteristics prescribed by Scrum have a sound basis in the fundamental characteristics of any
well-formed team:
• A shared, elevating vision or goal • Interdependence among team members

• A sense of team identity • Effective communication
• A results-driven structure • A sense of autonomy
• Competent team members • A sense of empowerment
• A commitment to the team • Small team size
• Mutual trust • A high level of enjoyment
Adapted from Rapid Development, Steve McConnell
45 Construx®
45
Task Board
To Do Doing Done
Product Owner
Scrum Master
Developers
46 Construx®
46

Scrum Boot Camp
The Scrum Master
The Scrum Master role has several important responsibilities to the Scrum Team
As Process Keeper for the Scrum Team, the Scrum Master ensures that:
• The Developers and Product Owner adhere to the Scrum rules and practices, according to the
underlying theory
• Coaching the Developers in self-organization and cross-functionality
• Facilitating Scrum events as requested or needed
As a Servant Leader for the Scrum Team, the Scrum Master ensures that:
• People outside the Scrum Team interact with it in a helpful way, improving interactions as needed
to maximize the Scrum Team’s delivered value
• The team has what it needs to succeed, removing impediments, coaching, and facilitating Scrum
events as requested
47 Construx®
47
The Scrum Master (cont.)
As a Sage and Mentor to the Scrum Team, the Scrum Master ensures that
• Technical issues are understood and resolved quickly and correctly
• Commitments are understood in a clear, common, and coherent way
• There is continuous improvement to the team’s performance
48 Construx®
48

Scrum Boot Camp
A Good Scrum Master…
A Good Scrum Master An Ineffective Scrum Master

Understands Scrum Has a cursory knowledge of Scrum
Has sufficient experience to know when the team Doesn’t believe Scrum can be effective
is struggling even if they won’t admit it Doesn’t understand software development
Understands and follows the manager-as- Believes projects and teams need to be driven
servant philosophy
Avoids necessary confrontation
Is a good listener
Works with the team to identify and eliminate
impediments
Has a high level of courage and integrity,
combined with tact and sensitivity An ineffective Scrum Master will
lead to Scrum project failure!
49 Construx®
49
Lab: A Day in the Life
1. Characterize a typical working day for each Scrum role
2. Identify impediments to use of the Scrum working style in your environment
Instructions:
• See handout
Time Box:
• 5 minutes to read
• 10 minutes to discuss
50 Construx®
50

Scrum Boot Camp
Reflections
1. Who is responsible for assigning Sprint scope to the Developers during Sprint Planning?
a. The Product Owner
b. The project executive
c. The Scrum Master
d. Trick question – only the Developers can forecast work that can be completed in a Sprint; no
one assigns it
2. How many Developers can a Scrum team have? Why?
3. Which of the following is/are not a responsibility of a Scrum Master?
a. Process coach
b. Sage and mentor for improved team performance
c. Ensuring the Product Backlog is in the best possible order
d. Ensuring adherence to all Scrum rules
e. Assigns and manages Developers tasks during each Sprint based on the Sprint Backlog
51 Construx®
51
Reflections
1. (T/F): The Product Owner has the final say on how much will be delivered in any Sprint
2. (T/F): The Scrum Master’s only responsibilities are to his/her/their Developers
3. (T/F): The Developers are free to choose their titles based on the type of work they are doing in each
Sprint
4. (T/F): The Product Owner role can be shared by more than one person; on larger projects, it is often
performed by a committee
52 Construx®
52

Scrum Boot Camp
Task Board
To Do Doing Done
Product Owner
Developers
Scrum Master
53 Construx®
53
Construx®
Populate a Product Backlog
54 Construx®
54

Scrum Boot Camp
Section Story

As a Product Owner, 1. Students understand how to use User Stories
as PBIs
I want to know how to populate the Product
Backlog 2. Students know the attributes of a good User
Story
So that I can maximize the value delivered by my
3. Students know how to refine, order, and
team
maintain a Product Backlog
55 Construx®
55
Task Board
To Do Doing Done
Product Backlog
Items
Product Backlog
Refinement
56 Construx®
56

Scrum Boot Camp
Common Product Backlog Item Types
Scrum does not prescribe a particular item User

type for the Product Backlog Stories
User Stories are very popular, but teams
often include other item types in addition to,
or instead of, User Stories Features
Spikes
/ Epics
The most common PBI types are shown here,
but this is not a complete list Product
Backlog
Technical Defects /
Debt Bugs
57 Construx®
57
User Stories
A User Story is a short, abstract description of something that a person playing a particular role wants to
accomplish using the system, written the following (or similar) format:
As a <role name>, I want <feature or function> so that <goal or value proposition>

User Stories:
• Are easy and intuitive for end users to understand
• Focus on the what rather than the how, leaving implementation details for later
• Include Acceptance Criteria to objectively measure when the story is done
A story can be thought of as a promise to hold a future conversation
58 Construx®
58

Scrum Boot Camp
Elaborate Stories with the Three C’s
Since story cards cannot describe every

detail for a feature, they shift the focus
from writing about features to talking
about them.
Conversation
• Cards are tokens; the • Supplement verbal
card isn't the real thing conversations with
- it's a placeholder for • The real thing. acceptance criteria to
the real thing Converse continually confirm when story is
with customers to done
meet their needs.
Card Confirmation
Construx®
Adapted from (Jeffries, 2001); see (Langr & Ottinger, 2011)
59
Epics
An Epic is a story that is too big to be completed in a single sprint

• Epics can be used as placeholders for describing large portions or areas of a product or a release
• During estimation, User Stories are sometimes discovered to be Epics instead
make a
reservation
Make and Manage Reservations
change a
reservation
As an frequent business travel cancel a
reservation
I want to create and manage reservations …

in order to have a place to stay on business and personal travel
60 Construx®
60

Scrum Boot Camp
INVEST in Good User Stories
Good User Stories are:
Independent, so they can be scheduled flexibly and cause little interference

I
with each other
Negotiated, rather than interpreted as a fixed contract for delivery (this implies
N
they are also negotiable)
V Valuable to the product’s stakeholders
Estimable, meaning they contain necessary content and context to be

E
estimated for size, difficulty, etc.
Sized
S Small, so their scope can be clearly understood, and they are easier to manage
Appropriately
Testable, usually demonstrated by a set of acceptance criteria that the
T
stakeholders agree will show completion of the story
INVEST Model originally created by Bill Wake. See http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
61 Construx®
61
Lab: Populate the Product Backlog
1. Learn how to populate a Product Backlog using User Stories
2. Practice good User Story writing
Instructions:
• See handout
Time Box:
• 30 minutes
62 Construx®
62

Scrum Boot Camp
Task Board
To Do Doing Done
Product Backlog
Backlog Items
Refinement
User Stories as
PBIs
63 Construx®
63
Backlog Refinement
The Product Owner must ensure that the items at the top of the Product Backlog are ready for the
Developers to move into a Sprint Backlog
• But this is a collaborative effort; the Product Owner is responsible, but the Developers assist by
providing estimates, technical input, etc.
• Typically, the Developers spends approximately 10% of its capacity on Backlog Refinement
Refinement often entails:
• Splitting User Stories or PBIs
• Elaborating User Stories or PBIs with acceptance criteria
• Creating estimates (or re-estimates)
Focus is on the PBIs near the top of the Product Backlog, since they are most likely to be needed in
upcoming Sprints
64 Construx®
64

Scrum Boot Camp
Elaborating Stories with Acceptance Criteria
A second way to elaborate User Stories is to add Acceptance Criteria
Settings Presets
As a digital photographer, I want to be able to store various settings so that I
can recall them quickly and not miss an important picture.
Acceptance criteria:
1. The camera holds up to five sets of user settings
2. Settings include white balance, autofocus, flash, ISO rating, file format,
and auto-exposure
3. Setting sets can be created, read, updated, and deleted
4. A setting set can be recalled with no more than two taps
5. Each setting can be given a user-defined name of up to 32 characters
65 Construx®
65
Definition of Done vs. Acceptance Criteria
Things that must be true for all PBIs DoD

in an increment
Things that must be true for some

PBI Acceptance Criteria
subset of PBIs or a single PBI
66 Construx®
66

Scrum Boot Camp
Splitting Large Stories
By acceptance criteria
Defer alternate paths, edge cases, or error cases
Defer supporting fields
Defer side effects
Stub dependencies
Split operationally (for example, CRUD)
Defer nonfunctional aspects
Defer variant data cases
Use or inject dummy data
(Langr & Ottinger, 2011) Construx®
67
The Definition of Ready
Definition of “Ready” (example only)

The Scrum Team should establish a Definition of q The PBI has well understood with complete,
Ready to ensure that the items at the top of the clear, and well-written Acceptance Criteria
Product Backlog are ready to be moved into a
q The PBI is testable within the Sprint
Sprint Backlog
(infrastructure available, etc.)
The Definition of Ready creates transparency, and q No external dependencies would block the
permits the Developers to forecast the Sprint PBI from being completed
Backlog with confidence
q All necessary UX guidance is available
q …
68 Construx®
68

Scrum Boot Camp
Lab: Refine the Product Backlog
1. Understand refining activities
Instructions:
1. Select 2-3 small stories from yesterday (or the Answer Key)
2. Discuss and document acceptance criteria for for those stories
3. Decompose at least one user story into smaller stories using the acceptance criteria
4. Capture acceptance criteria for that at least one child story (suggest the one you think is the
smallest story)
Time Box:
• 30 minutes
69 Construx®
69
Task Board
To Do Doing Done
Product Backlog
Items
Refining PBIs
70 Construx®
70

Scrum Boot Camp
Reflections
1. (T/F): The Product Backlog must contain User Stories, and only User Stories
2. (T/F): The Developers do not play any role in populating the Product Backlog – the Product Owner
does everything
3. What is the purpose of the Definition of Ready?
4. Name at least three ways to split large User Stories
71 Construx®
71
Construx®
Estimate a Product Backlog
72 Construx®
72

Scrum Boot Camp
Section Story

As a Scrum Team member, 1. Students understand Agile estimation
practices and their use in Scrum
I want to understand the common sizing
techniques used on Scrum projects 2. Students understand the concept of velocity
and its relationship to estimation
So that I can accurately and efficiently estimate
3. Students know how to estimate User Stories
the size of the work at hand
in a Product Backlog
73 Construx®
73
Task Board
To Do Doing Done
Agile Estimation
Velocity
74 Construx®
74

Scrum Boot Camp
Common Agile Estimation Practices
What How When Where
T-Shirt Product
Feature, Epic Product Planning
Increasing Detail and Precision
Sizes Backlog
Story Release Planning

Product
Epic, Points & Backlog
Refining Backlog
Story
Ideal Sprint Planning Sprint

Task Hours Backlog
75 Construx®
75
Story Points
Story Points are a measure of a User Story’s size and complexity relative to other User Stories
• Story Points are not an estimate of development hours
• The numbers are somewhat arbitrary, reflecting the imprecise nature of estimation
There are several common schemes for Story Point numbering:
• Fibonacci series: 1, 2, 3, 5, 8, 13, 21, …
• Modified Fibonacci numbers: 1, 2, 3, 5, 10, 20, 40, 100, ?
• Powers of 2: 1, 2, 4, 8, 16, 32, 64, …
What matters most is that a team uses their chosen scheme consistently
76 Construx®
76

Scrum Boot Camp
Planning Poker
If outliers exist, the
The Product The team may team engages in a
Owner selects a briefly discuss Each estimator focused discussion
PBI to be the item and ask privately selects a to expose
estimated, and clarifying card representing All estimators assumptions,
reads the item to questions to the his or her reveal their cards missing facts, and
the team Product Owner estimate simultaneously misunderstandings
Consensus?
Select PBI Clarify Estimate Reveal Discuss
N
Planning Poker is a gamified way Establish PBI

to estimate PBIs using either Estimate
Story Points or T-Shirt sizing
77 Construx®
77
Pin-the-Tail Sizing
Pin-the-Tail estimation combines analogy and consensus for rapid sizing of PBIs, while also preventing
sizing drift over time
3. In a workspace off
the board, rank up
1. Place a Fibonacci
to 10 PBIs from
scheme on the wall
smallest to largest
2. Place references 4. Then, place each

stories (or some ranked item under
existing, estimated the size category
PBIs) on the board that best reflects it
as size references
78 Construx®
78

Scrum Boot Camp
Sizing Fundamentals
1. The team owns the process; everyone participates

2. Use Planning Poker (or similar) to reach agreement
3. Remember that the goal is relative size, not absolute size
4. Decrease granularity as story size increases
5. It is an apples to oranges comparison between teams
6. Use prior estimated PBIs to anchor new estimates and prevent drift over time
7. Use a Definition of Done to ensure consistent, complete estimates
79 Construx®
79
Lab: Estimate the Work
1. Estimate dogs using Story Points and Pin-the-Tail Sizing
Instructions:
• Create a set of “dog cards” – see Jenny’s list of dogs
• Create a Fibonacci scale --1, 2, 3, 5, 8, 13, 21, 34, 55, etc.
• Select a reference dog (suggest a mid-weight dog) and place it on the reference scale
• Stack rank the dogs by WEIGHT (how heavy they are to lift)
• Compare the stack ranked dogs to the reference dog and place them on the story point scale
Time Box:
• 15 minutes
80 Construx®
80

Scrum Boot Camp
Task Board
To Do Doing Done
Agile Estimation
Velocity
81 Construx®
81
What is Velocity?
In Scrum, velocity refers to the rate at which the team is delivering value, typically measured in delivered
story points per Sprint
A team can track its velocity over time to monitor its productivity, predictability, and the results of
improvement efforts
Different teams can have significantly different velocities, because:
• They have normed on different Story Point sizing (one team’s 8 is another team’s 13)
• Whether or not they count defect correction, spikes, etc. in velocity measurement or just User
Stories
• Whether they report their velocity based on just the most recent Sprint, the n previous Sprints, or
all Sprints
• Etc.
Velocity is a useful measure for a team to use internally to forecast Sprint scope and broad release
content & timing
82 Construx®
82

Scrum Boot Camp
Task Board
To Do Doing Done
Agile Estimation
Velocity
83 Construx®
83
Reflections
1. What are Story Points useful for?

a. Translating User Stories to effort estimates
b. As a relative measure of User Story size and complexity
c. Measuring team productivity
d. Both a. and b.
e. Both b. and c.
2. (T/F): Velocity’s standard definition makes it comparable across teams and useful for management to
assess and evaluate team performance
3. (T/F): Velocity calculation always includes defect correction and spikes as well as User Stories
84 Construx®
84

Scrum Boot Camp
Construx®
Plan a Sprint
85 Construx®
85
Section Story

As a Scrum Team member, 1. Students understand the Sprint planning
process and outputs
I want to understand how to plan a Sprint
2. Students can apply techniques for
So that I can participate in Sprint planning, and decomposing stories into tasks
explain to external stakeholders how Sprint
3. Students know how to create a Sprint goal
planning works and what to expect
86 Construx®
86

Scrum Boot Camp
Task Board
To Do Doing Done
Sprint Planning
Meeting
Structure &
Roles
Estimating
Team Capacity
87 Construx®
87
Sprint Planning
Sprint Planning 1. The Product Owner proposes how the product could increase its
Product value and utility in the upcoming Sprint
Backlog
Sprint 2. The team collaborates to create a draft Sprint Goal
backlog
3. The Developers select items from the Product Backlog to include
in the Sprint
4. The Developers plan to work necessary to complete each
selected Product Backlog Item and bring that work to the team’s
Definition of Done
5. The team finalizes the Sprint Goal and commits to the Sprint
1. Why is this Sprint valuable?
2. What can be Done this Sprint?
3. How will the chosen work get done?
88 Construx®
88

Scrum Boot Camp
Sprint Planning Meeting Structure
Purpose Establish agreement between the Product Owner and the Developers on the team’s
forecast for completed PBIs during the upcoming Sprint
Format Meeting
Length Time-boxed to 8 hours*
Participants Developers, Product Owner, Scrum Master
Inputs Product Backlog, previous increment, projected team capacity during the Sprint, at
least one high priority process improvement from the retro
Outputs Sprint Goal, Sprint Backlog which may include a process improvement from the
retrospective
For a one-month Sprint; for shorter Sprints, the event is proportionally shorter. Scrum Guide official language say “For shorter sprints the
*
event is usually shorter.”
89 Construx®
89
Sprint Planning by Role
Developers
• Decomposes and analyzes PBIs as needed to make a confident, accurate forecast
• Determines the set of PBIs that it believes it can deliver in the upcoming Sprint, and forecasts that set
as the Sprint Backlog
• Decides how it will build a “Done” product increment based on the Sprint Backlog
• Plans enough work in detail to accommodate the first few days of the Sprint
• Plans enough work in detail to confidentially make a commitment
• Self-organizes as needed during both Sprint Planning and the following Sprint
90 Construx®
90

Scrum Boot Camp
Sprint Planning by Role
Product Owner
• Ensures Product Backlog order represents the highest value items
• Clarifies PBIs, answers Developers questions
• Helps create the Sprint Goal
• Renegotiates the Sprint Backlog if the Developers determines it is either too much or too little work
for the Sprint
Scrum Master
• Ensures the Sprint Planning meeting is held, and participants understand its purpose
• Teaches the team how to keep it within the allowed time-box
• Coaches on effective techniques and practices to completing planning
91 Construx®
91
Task Board
To Do Doing Done
Sprint Planning
Estimating Meeting
Team Capacity Structure &
Roles
92 Construx®
92

Scrum Boot Camp
Estimating Team Capacity
Capacity is expressed in
• Story Points available this sprint
• Ideal Hours available this Sprint
Be sure to account for non-Scrum activities such as vacation, training, general business meetings, etc.
As you progress, use the team’s performance data to adjust Team Capacity estimates
93 Construx®
93
Ideal Hours
Ideal hours assume no distractions or context-switching during work

For the best estimates:
• Allow for factors that influence effort: complexity, risk, precedence, etc.
• Focus on tangible deliverables
• Think start-to-finish
• Make your tasks granular
• Remember your Definition of Done
Heuristics:
1. Assume no more than 6
ideal hours/day
2. Track your own data to
validate and adjust this
number
94 Construx®
94

Scrum Boot Camp
Example: Team Capacity Calculation
Sprint Duration (Business Days) 10

Ideal Hours per Day × 6
Total Ideal Hours per person per Sprint = 60
Subtract Scrum Activities:

Product Backlog Grooming (10%) − 6
Sprint Planning − 4
Sprint Review − 2
Sprint Retrospective − 2
Net Ideal Hours per person per Sprint = 46
Number of Developers(100% dedicated) × 5

Team Capacity (net Ideal Hours per Sprint) = 230
95 Construx®
95
Decomposing PBIs into Tasks

Make Reservation
As a … Reservation Maker
…
I want to… Make a Reservation
…
In order to… guarantee a place to stay
in my upcoming travel plans.
5 Heuristic:
Decompose PBIs into tasks
that would take one day or
less to complete.
Regression Backend Update release
UI Coding
Testing Coding and help notes
4h 6h 2h 1h
96 Construx®
96

Scrum Boot Camp
Task Board
To Do Doing Done
Sprint Planning
Meeting
Structure &
Roles
Estimating
Team Capacity
97 Construx®
97
Lab: Populate the Sprint Backlog
1. Decompose at least one Product Backlog Item into tasks
2. Estimate task effort in Ideal Hours
Instructions:
• See instructor
Time Box:
• 15 minutes
98 Construx®
98

Scrum Boot Camp
Task Board
To Do Doing Done
Sprint Planning
meeting
structure &
roles
Estimating
Team Capacity
99 Construx®
99
Reflections
1. The number of PBIs that the Developers forecast for delivery is determined by:
b. The Scrum Master, based on previous Sprints and the team’s velocity
c. The Developers
d. Both a. and b., via Sprint Negotiation
2. Which of the following is not an input to Sprint Planning?
a. Product Backlog
b. Sprint Goal
c. The most recent Increment
d. Projected team capacity
e. Data on past performance
100 Construx®
100

Scrum Boot Camp
Reflections
3. The Sprint Goal is determined by:

a. The Scrum Master
b. The Product Owner
c. The Developers
d. Both b. and c.
e. The entire Scrum Team
4. (T/F): Using Ideal Hours allows people not to focus on context-switching and interruptions when
estimating sprint tasks
101 Construx®
101
Construx®
Execute a Sprint
102 Construx®
102

Scrum Boot Camp
Section Story

As a Scrum Team member, 1. Students understand what each Scrum role
does during a Sprint
I want to understand how to execute a Sprint
2. Students know what data and status
So that I can perform my role in generating information to collect
maximum customer value
103 Construx®
103
Task Board
To Do Doing Done
Sprint Overview
Daily Scrum
Tracking
Progress
104 Construx®
104

Scrum Boot Camp
Product Owner
During a Sprint, the Product Owner’s duties include:

1. Continuing to refine PBIs for upcoming Sprints
2. Capture and refine stakeholder requirements related to the future Sprints
3. Answer questions related to the current PBIs to ensure the right functionality is built during the
Sprint
4. Revise the Product Backlog (not the Sprint Backlog) and release plans to account for new
information and circumstances
5. Review intermediate work products and builds
105 Construx®
105
Developers
During a Sprint, the Developers' duties include:

1. Breaking down Sprint Backlog items into tasks (if/as needed)
2. Creating and refining estimates as needed
3. Selecting and completing tasks in support of the Sprint Goal
4. instilling quality by adhering to the DOD ; collaborating on design, code reviews, testing, etc.
5. Maintaining the Sprint Backlog to reflect progress, changes, and new information
6. Helping the Product Owner with Product Backlog refinement for future Sprints
106 Construx®
106

Scrum Boot Camp
Scrum Master
During a Sprint, the Scrum Masters duties include:

1. Facilitating the Daily Scrum
2. Coaching the team on how and why to adhere to Scrum practices and rules
3. Helping the team maintain its progress and status indicators
4. Dealing with external impediments and interruptions
5. Coaching the Developers on their performance against the Definition of Done, internal working
agreements, ability to hold each other accountable as professionals, etc.
107 Construx®
107
Sprint Fundamentals
A Sprint’s conclusion occurs at the end of the time-box, not at Sprint Backlog completion
• Any incomplete tasks at the end of the Sprint are, by definition, out of scope for the Sprint
Only the Developers can add or remove work from the Sprint Backlog
Work in a Sprint always occurs in priority order to maximize value delivery
108 Construx®
108

Scrum Boot Camp
Task Board
To Do Doing Done
Sprint Overview
Daily Scrum
Tracking
Progress
109 Construx®
109
Daily Scrum Meeting Structure
Purpose Synchronize activities and plan for the next 24 hours by inspecting and adapting the
Sprint Backlog
Format Meeting
Length Time-boxed to 15 minutes
Participants Developers (primary), Product Owner, Scrum Master, and stakeholders
Inputs Sprint Backlog, Sprint Goal
Outputs Sprint Backlog (possibly revised), Sprint Goal (possibly revised), current impediments,
plan for next 24 hours
110 Construx®
110

Scrum Boot Camp
Daily Scrum
The Developers uses the Daily Scrum to inspect progress toward the Sprint Goal and procuce an
actionable plan for the next day of work.
The Daily Scrum is held at the same time and in the same location each day
The Daily Scrum can be more discussion based or can use the traditional three question format of:
1. What did I do yesterday to help the team meet the Sprint Goal?
2. What do I plan to do in the next 24 hours to help the team meet the Sprint Goal?
3. Do I see any impediments that prevent me or the team from meeting the Sprint Goal?
Team members often meet after the Daily Scrum for detailed discussions
111 Construx®
111
Task Board
To Do Doing Done
Sprint Overview
Tracking
Progress
Daily Scrum
112 Construx®
112

Scrum Boot Camp
Status Indicators: Task Boards
Story To Do Doing Done
Show the … Create the …

Add the … Discuss the …
8 hrs 4 hrs Abby 8 hrs Grace 1 2 hrs
As a user, I … Code the … Integrate … Design the … Prototype …
8 pts Izzy & AJ
4 hrs 6 hrs 6 4 hrs Sam 8 hrs
Test the …
2 hrs
Model storm … Add the …

As a user, I …
2 hrs 2 hrs
5 pts
Create the … Test the …
2 hrs 6 hrs
113 Construx®
113
Example: Sprint Burndown Chart
700
600
500
400
300
200
100
0
0 7 14 21 28
Plann ed (Constant velocity) Actual
114 Construx®
114

Scrum Boot Camp
Task Board
To Do Doing Done
Sprint Overview
Daily Scrum
Tracking
Progress
115 Construx®
115
Reflections
1. Who is responsible for maintaining the Sprint Backlog during a Sprint?

b. The Scrum Master
c. The Developers
d. All of the above
2. During a Daily Scrum, the Scrum Master’s role includes:
a. Gathering status from each Developer
b. Leading the discussion
c. Teaching the Developers to stay within the 15-minute time box
d. All of the above
3. (T/F): The Developers must attend the Daily Scrum, but the Product Owner may choose to attend or
not on a day-by-day basis
116 Construx®
116

Scrum Boot Camp
Construx®
Wrap Up a Sprint
117 Construx®
117
Section Story

As a Scrum Team member, 1. Students can describe the rules and process
for conducting a Sprint Review and Sprint
I want to understand how to wrap up a Sprint
Retrospective
So that Gather feedback on the product and 2. Students are familiar with symptoms of
process in order to improve our product and common Scrum problems (smells) and
process Scrum antipatterns
118 Construx®
118

Scrum Boot Camp
Task Board
To Do Doing Done
Sprint Review
Sprint
Retrospective
Scrum Smells &

Antipatterns
119 Construx®
119
Sprint Review Meeting Structure
Purpose Inspect the “Done” Increment and adapt the Product Backlog (if needed)
Format Demonstration and discussion
Participants Scrum Team, and any stakeholders invited by the Product Owner
Inputs Completed Increment, Sprint Goal, and any resources necessary for the
demonstration
Outputs Feedback on the Increment, updated product data, and a revised Product Backlog
that indicates probable PBIs for the next Sprint
*For a one-month Sprint; for shorter Sprints, the event is proportionally shorter. Scrum Guide official language say “For shorter sprints the event is usually shorter.”
120 Construx®
120

Scrum Boot Camp
Sprint Review Meeting Flow
1. The Product Owner describes what PBIs were completed during the Sprint, along with any forecasted
work that was not completed
2. The Developers:
• Discusses what went well, what went poorly, what impediments it encountered, etc.
• Demonstrates the completed work using the Increment and answers any questions
3. The Product Owner summarizes the current state of the Product Backlog, updating projections for
completion dates as needed
4. All attendees collaborate and discuss:
• Changes to the product’s market, capabilities, feasibility, value proposition, and the effects of
those changes on the Product Backlog
• What should be done next, as input into the next Sprint Planning meeting
121 Construx®
121
Task Board
To Do Doing Done
Sprint
Sprint Review
Retrospective
122 Construx®
122

Scrum Boot Camp
Sprint Retrospective Meeting Structure
Purpose Inspect how the Sprint went, generate improvement ideas, and create plans for
implementing improvements in the next Sprint
Format Meeting (exercises and discussion)
Participants Scrum Team
Inputs Data, process descriptions, and work products for the most recent Sprint;
current Definition of Done
Outputs Improvement plans for the next Sprint; adapted process descriptions, work product
templates, and Definition of Done (as needed)
*Fora one-month Sprint; for shorter Sprints, the event is proportionally shorter. Scrum Guide official language say, “For shorter sprints the
event is usually shorter.”
123 Construx®
123
Retrospective Fundamentals
1. Confidentiality: All participants agree to abide by strict confidentiality for topics presented or
discussed in the retrospective
• This include scrubbing or summarizing contributions as needed to protect everyone’s identity
2. Attitude: The meeting is conducted in a spirit of improvement and quality assurance, not fault-finding
or blame
3. Root Causes: Allocate sufficient time, in a safe, focused atmosphere, for the team to locate root
causes to issues and real insights
4. The Retrospective Prime Directive* is in effect:
“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”
*See http://www.retrospectives.com
124 Construx®
124

Scrum Boot Camp
Retrospective Fundamentals
Scrum does not impose any particular method or practice for Sprint Retrospectives, but there is a good
general framework for Agile retrospectives*:
1. Set the Stage
2. Gather Data
3. Generate Insights
4. Decide What to Do
5. Close the Retrospective
All these steps are important; if you skip or skimp on any, you may end up just wasting time…
*See Agile Retrospectives: Making Good Teams Great, Esther Derby and Diana Larson, http://estherderby.com
125 Construx®
125
Generate Data Example: Emotional Time Line
Finished
slightly early
Great pairing
on
1st story
impediment
done early
Scrum
Master
0 3 5 rescue! 7 9
External
interruption
Ugly
impediment
126 Construx®
126

Scrum Boot Camp
Generating Insights
Without clear focus on generating insights, retrospectives tend to turn into long lists of symptoms and
observations that don’t lead to clear, effective improvement actions
• Don’t just create “What worked” and “What didn’t work” lists
• 5 Whys, causal analysis, fishbone diagrams, “5 W's and an H”, fault trees, and many other
techniques can be used to go beyond symptoms
127 Construx®
127
Task Board
To Do Doing Done
Sprint Review
Sprint
Retrospective
128 Construx®
128

Scrum Boot Camp
Reflections
1. What is the purpose of the Sprint Review meeting?

a. Inspect the completed Increment and adapt the Product Backlog (if needed)
b. Inspect how the previous Sprint went, generate improvement ideas, and create plans for
implementing improvements in the next Sprint
c. Both a. and b.
2. Which of the following is NOT an output of the Sprint Review meeting:
a. Feedback on the Increment
b. Updated product data
c. Revised Product Backlog
d. Improvement suggestions for conducting the next Sprint
3. (T/F): Once a team has successfully completed several Sprints, the Sprint Retrospective may be
eliminated to save time
129 Construx®
129
Construx®
Summary
130 Construx®
130

Scrum Boot Camp
Back to the Beginning
Course Objectives:
1. Define important terms and concepts related to Agile and Scrum
2. Demonstrate an understanding of the Scrum framework
3. Apply effective practices to perform Scrum events and create Scrum artifacts
4. Understand the user story format and be able to write stories
5. Estimate using story points and know what velocity is and can be used for
6. Know how to plan, execute, and track progress of a Sprint
7. Appreciate how retrospectives and reviews are used to obtain feedback
131 Construx®
131
Construx®
Construx Software is committed to helping individuals and
organizations improve their software development practices
For information about our training and consulting services, contact
info@construx.com.
Seminar Schedule: www.construx.com/calendar
1100 Bellevue Way NE, Suite 8A– PMB 13

Bellevue, WA 98004
+1 (866) 296-6300
132 Construx®
132

Scrum Boot Camp Slides

Uploaded by

Copyright:

Available Formats

Scrum Boot Camp Slides

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

Scrum Boot Camp Slides

Uploaded by

Copyright:

Available Formats

Scrum Boot Camp

Scrum Boot Camp

Third-party brands and names may be claimed as the property of others.

© Construx Software, Inc. 1

Scrum Boot Camp Two-day course with hands-on exercises

Unlike: Many other courses in the marketplace

Why are You Here?

I want… <your goal or desire>

So that… <value or benefit>

© Construx Software, Inc. 2

After completing this course, you will be able to:

© Construx Software, Inc. 3

Proposed Working Agreements

1. Class starts at 9am, and ends by 5pm

© Construx Software, Inc. 4

Story Acceptance Criteria:

Agile vs. Scrum

© Construx Software, Inc. 5

What Does Agile Really Mean?

Agile development refers to a group of software development methodologies based on iterative

The Agile Manifesto

The original Agile Manifesto (2001) reads:

© Construx Software, Inc. 6

Principles Behind the Agile Manifesto

Scrum vs. Agile

© Construx Software, Inc. 7

The Big Agile Umbrella

Practices Methodologies & Approaches

Scrum Has Won the Agile Wars

Source: Version One 14th Annual State of Agile Report

© Construx Software, Inc. 8

Why Choose Scrum?

“Scrum, done even fairly well, is a good framework… It’s good to

Scrum has clearly emerged as the best of

© Construx Software, Inc. 9

Scrum vs. Agile

© Construx Software, Inc. 10

Story Acceptance Criteria:

So that I can succeed in learning Scrum at Depth

Software development: Rugby match or bucket brigade?

Adapted from Scrum Guide 2020

© Construx Software, Inc. 11

Why Scrum Works

Scrum works because it:

The Scrum Framework

Roles Events Artifacts

1. Product Owner 1. Sprint 1. Product Backlog

Scrum’s rules bind together the roles, events,

© Construx Software, Inc. 12

Adopting Scrum: Decisions, Decisions…

© Construx Software, Inc. 13

The Product Backlog is an ordered list of Product Backlog Items (PBIs)

© Construx Software, Inc. 14

Typical Sprint Timeline & Ranges

1. What can be done this Sprint?

© Construx Software, Inc. 15

The Definition of Done

Lab: What’s in Your DoD?

© Construx Software, Inc. 16