PeopleCert Scrum Master I (Study Guide)

PeopleCert SCRUM Master I
Copyright Details
The contents of this workshop are protected by copyright and can be reproduced under the Terms of Use agreed between PeopleCert
and the ATO using this material only.
Material in this presentation has been sourced from the bibliography listed in the certifications Syllabus.
No part of this document may be reproduced in any form without the written permission of PeopleCert International Ltd. Permission
can be requested at www.peoplecert.org.
E-mail: info@peoplecert.org
Website: www.peoplecert.org
Copyright © 2021 PeopleCert International Ltd.

All rights reserved. No part of this publication may be reproduced or transmitted in any form and by any means (electronic, photocopying,
recording or otherwise) except as permitted in writing by PeopleCert International Ltd. Enquiries for permission to reproduce, transmit or
use for any purpose this material should be directed to the publisher.
Disclaimer
This publication is designed to provide helpful information to the reader. Although every care has been taken by PeopleCert International
Ltd in the preparation of this publication, no representation or warranty (express or implied) is given by PeopleCert International Ltd as
publisher with respect as to the completeness, accuracy, reliability, suitability or availability of the information contained within it and
neither shall PeopleCert International Ltd be responsible or liable for any loss or damaqe whatsoever (indicatively but not limited to,
special, indirect, consequential) arisinq or resultinq of virtue of information. instructions or advice contained within this publication.)
2
PeopleCert: A global leader in certification
✓ Web & Paper based exams in 25 languages

✓ Delivering exams across 200 countries every year
✓ 2,000 Accredited Training Organisations
✓ Comprehensive Portfolio of 500+ Exams and Growing
worldwide
Exam Details
Closed book
60 minutes
40 questions
70% pass mark (28/40)
Multiple choice
4
Exam Details
The PeopleCert Scrum Master I examination will consists

of eight (8) sections with the following percentages:
1 - Introduction to Agile Projection Management (5%)
2 - Scrum as an Agile Framework (2.5%)
3 - The Scrum Framework & Team (25%)
4 - Scrum Artifacts (25%)
5 - Scrum Planning (12.5%)
6 - Scrum Events (25%)
7 - Information Radiators (2.5%)
8 - Scaled Scrum (2.5%)
4
Table of Contents
Module #1: An Introduction to Agile Project Management 7
Module #2: An Introduction to Scrum as an Agile Framework 18
Module #3: An Introduction to the Scrum Framework 21
Module #4: Scrum Roles 28
Module #5: Multilevel Planning 48
PeopleCert SCRUM Master I - Study Guide

5
Table of Contents
Module #6: Preparing the Product (Planning Level) 51
Module #7: Scrum Artifacts 83
Module #8: Iteration Level Planning 99
Module #9: Staying in Control with Information Radiators 133
Module #10: Scrum Rules 139
Module #11: Introduction to Scaled Scrum 142

6
Module #1
An Introduction to Agile
Project Management
Learning Objectives
▪ Define the term "agile" as an adjective used to describe a flexible, iterative project management style and
identify key terms used to describe Agile approaches like iterative, incremental, and adaptive.
▪ Describe the benefits of Agile project management related to three aspects of value: cost; quality; and speed.
▪ Differentiate between the attributes of predictive and adaptive project management and differentiate between
project attributes that best suit a predictive versus an adaptive project management approach.
▪ Explain the main goal of Agile frameworks.
▪ Describe the key factors in the success of Agile project management.
▪ Describe the waterfall methodology and explain its disadvantages.
▪ Define the Agile Manifesto.
▪ Identify the four values outlined in the Agile Manifesto.
▪ Identify the 12 principles of the Agile Manifesto.

7
An Introduction to Agile Project Management
The Agile Manifesto – The Twelve Principles

What Is Agile?
“A project management style focused on
early delivery of business value, 1) Customer satisfaction by early and continuous
continuous improvement, scope flexibility, delivery of valuable software.
team input, and delivering well-tested 2) Welcome changing requirements, even in late
products that reflect customer needs.” development.
3) Deliver working software frequently (weeks
• The Agile Manifesto is a brief document built on 4 values and rather than months)
12 principles for agile software development.
• The Agile Manifesto was published in February 2001 and is the 4) Close, daily cooperation between business
work of 17 software development practitioners people and developers
• Its authors believe software developers should use it to guide 5) Projects are built around motivated individuals,
their work. who should be trusted
6) Face-to-face conversation is the best form of
communication (co-location)
The Agile Manifesto – The Four Values 7) Working software is the primary measure of
progress
Individuals and interactions over processes and tools 8) Sustainable development, able to maintain a
Working software over comprehensive documentation constant pace
Customer collaboration over contract negotiation 9) Continuous attention to technical excellence and
good design
Responding to change over following a plan
10) Simplicity—the art of maximizing the amount of
work not done—is essential
11) Best architectures, requirements, and designs
emerge from self-organizing teams
12) Regularly, the team reflects on how to become
more effective, and adjusts accordingly
Layton, Marc C. Agile Project Management for Dummies. New Jersey: John Wiley & Sons, 2017.
Beck, Kent et al. ”Manifesto for Agile Software Development”. Accessed October 30, 2019. http://agilemanifesto.org/
Agile Alliance. “12 Principles Behind the Agile Manifesto.” Accessed: October 30, 2019 https://www.agilealliance.org/agile101/12-principles-
behind-the-agile-manifesto/ PeopleCert SCRUM Master I - Study Guide
8
The Main Goal and Key Factors in the Success of Agile Project Management
Key factors in the success of

Agile project management
The main goal of Agile
▪ Collocation
frameworks is to make the
▪ Developer versatility
development quicker and ▪ Automated testing
smoother, and to create an ▪ Transitional support
▪ An enforced ‘definition of done’
output that is more satisfying ▪ A clear product vision and roadmap
for the customer. ▪ Product Owner empowerment
Adaptive Empirical
Planning Knowledge
Evolutionary Continual
Development Improvement
Agile Alliance. “Agile Glossary”. Last modified: 2011. Accessed: October 30, 2019. https://www.agilealliance.org/agile101/agile-glossary
Layton, Mark. “10 Ten Key Factors for Agile Project Success.” Accessed: October 30, 2019. https://www.dummies.com/careers/project-
management/10-ten-key-factors-agile-project-success/ PeopleCert SCRUM Master I - Study Guide
9
The Three Characteristics of Value
The business objectives for becoming more agile and using Agile development practices is ultimately connected
to providing more value to the customer as well as the organization. More value means growing sales, remaining
competitive, continual improvements, and continual innovations. Specifically, the target is to shorten the overall
development and delivery cycle, decrease cost associated with the development, and increase quality. Using
Agile development practices will deliver on all three value dimensions.
In terms of Speed, keep in mind that you need to keep your time-to-market short!

10
Adaptive versus Predictive Development
Predictive development models, also known as traditional, sequential, linear, or – most famously – as waterfall
approaches are less flexible because they take an entire deliverable through large phases of requirements, design,
development, integration, testing, and deployment. Progress flows steadily downwards through the linear phases.
▪ Development is phase-based and sequential with the assumption that all the correct information has been made
available from the very start.
▪ The batches are large, and the cost of delay is rarely considered.
▪ The primary means of achieving a good result is considered conformance to the plan.
Iterative Development
Adaptive Development models are iterative and
“A developmental approach to managing
incremental in their approach to planning, developing,
projects that focuses on intentionally allowing
and delivering. These models use collaboration as a
for the potential “revisiting” of work for rework,
foundation to their success. These models are seen as
changes, and improvements.”
circular and repetitive because they break a large
deliverable into smaller, more manageable deliverables
Incremental Development and they also circulate the development through the
“A style of development where each repeated activity of requirements, design, development,
successive version of the product is usable integration, and testing. Deployment is a separate phase
and each version builds upon the previous that follows iterative development.
version by adding user-visible functionality.”
Volkerdon.com. “Agile Glossary”. Accessed October 30, 2019. https://www.volkerdon.com/pages/agile-glossary PeopleCert SCRUM Master I - Study Guide
11
Avoiding the Hand-Off Syndrome
Traditional development models and organizational structures follow

formal waterfall-based processes that push and hand off work from one
specialist team to another.
Volkerdon.com. “Agile Glossary”. Accessed October 30, 2019. https://www.volkerdon.com/pages/agile-glossary PeopleCert SCRUM Master I - Study
Guide 12
The Disadvantages of Traditional Waterfall Development

Sutherland, Jeff. Jeff Sutherland’s Scrum Handbook. Scrum Training Institute, 2010. 13
What’s Wrong With Traditional Software Development? 1/2
The traditional way to build software, used by companies big and small, was a sequential life cycle of which there are many
variants (such as the V-Model). Commonly, it is known as “The Waterfall”.
1. It typically begins with a detailed planning phase, where the end product is carefully thought through, designed, and
documented in great detail.
2. The tasks necessary to execute the design are determined, and the work is organized using tools such as Gantt charts and
applications such as Microsoft Project. The team arrives at an estimate of how long the development will take by adding up
detailed estimates of the individual steps involved.
3. Once stakeholders have thoroughly reviewed the plan and provided their approvals, the team starts to work.
4. Team members complete their specialized portion of the work, and then hand it off to others in production-line fashion.
5. Once the work is complete, it is delivered to a testing organization (some call this Quality Assurance), which completes
testing prior to the product reaching the customer. Throughout the process, strict controls are placed on deviations from the
plan to ensure that what is produced is actually what was designed.
This approach has strengths and weaknesses. Its great strength is that it is supremely logical – think before you build, write it
all down, follow a plan, and keep everything as organized as possible. It has just one great weakness: humans are involved.
Hence a lot of problems occur:
• Creativity is inhibited
This approach requires that the good ideas all come at the beginning of the release cycle, where they can be incorporated into
the plan. But as we all know, good ideas appear throughout the process – in the beginning, the middle, and sometimes even
the day before launch. A process that does not permit change will stifle this innovation. With the waterfall, a great idea late in
the release cycle is not a gift, it’s a threat.
• Written documents have their limitations

The waterfall approach places a great emphasis on writing things down as a primary method for communicating critical
information. The very reasonable assumption is that if I can write down on paper as much as possible of what’s in my head, it
will more reliably make it into the head of everyone else on the team; plus, if it’s on paper, there is tangible proof that I’ve done
my job. The reality, though, is that most of the time these highly detailed 50-page requirements documents just do not get read.
When they do get read, the misunderstandings are often compounded. A written document is an incomplete picture of my
ideas; when you read it, you create another abstraction, which is now two steps away from what I think I meant to say at that
time. It is no surprise that serious misunderstandings occur.
Sutherland, Jeff. Jeff Sutherland’s Scrum Handbook. Scrum Training Institute, 2010.
14
What’s Wrong With Traditional Software Development? 2/2
• Bad timing
Something else that happens when you have humans involved is the hands-on “aha” moment – the first time that you actually
use the working product. You immediately think of 20 ways you could have made it better. Unfortunately, these very valuable
insights often come at the end of the release cycle, when changes are most difficult and disruptive – in other words, when doing
the right thing is most expensive, at least when using a traditional method.
• No crystal balls
Humans are not able to predict the future. For example, your competition makes an announcement that was not expected.
Unanticipated technical problems crop up that force a change in direction. Furthermore, people are particularly bad at planning
uncertain things far into the future – guessing today how you will be spending your week eight months from now is something of
a fantasy. It has been the downfall of many a carefully constructed Gantt chart.
• Too much work and no fun

In addition, a sequential life cycle tends to foster an adversarial relationship between the people that are handing work off from
one to the next. “He’s asking me to build something that’s not in the specification.”
“She’s changing her mind.” “I can’t be held responsible for something I don’t control.” And this gets us to another observation
about sequential development – it is not much fun. The waterfall model is a cause of great misery for the people who build
products. The resulting products fall well short of expressing the creativity, skill, and passion of their creators. People are not
robots, and a process that requires them to act like robots results in unhappiness.
• Sub-optimized results
A rigid, change-resistant process produces mediocre products. Customers may get what they first ask for (at least two
translation steps removed), but
is it what they really want once they see the product? By gathering all the requirements up front and having them set in stone,
the product is condemned to be only as good as the initial idea, instead of being the best once people have learned or
discovered new things.
Many practitioners of a sequential life cycle experience these shortcomings again and again. But, it seems so supremely logical
that the common reaction is to turn inward: “If only we did it better, it would work, and if we just planned more, documented
more, resisted change more, everything would work smoothly”. Unfortunately, many teams find just the opposite: the harder
they try, the worse it gets! There are also management teams that have invested their reputation – and many resources – in a
waterfall model; changing to a fundamentally different model is an apparent admission of having made a mistake.
Sutherland, Jeff. Jeff Sutherland’s Scrum Handbook. Scrum Training Institute, 2010. PeopleCert SCRUM Master I - Study Guide
15
Agile versus Waterfall
The major value difference in the two approaches is that the traditional Waterfall
side is mostly calculated, controlled, managed, and focused on the
schedule. Fundamentally different, the Agile approach is focused on
delivering maximum value to the customer by collaborating on the
release backlog and sprint backlog work items.
Agile
Disadvantages of Traditional Waterfall Development

▪ Creativity is inhibited. ▪ No crystal balls
▪ Written documents have their limitations. ▪ Too much work and no fun
▪ Bad timing ▪ Sub-optimized results
Adapted from Layton, Mark C. Agile Project Management for Dummies. New Jersey: John Wiley & Sons, 2017:45-46 PeopleCert SCRUM Master I - Study Guide
16
Adaptive versus Predictive Development
Traditional development models are best suited to Adaptive development models are best suited to
predictive projects and products where the requirements chaotic projects and products where requirements and
and scope are fixed, the product itself is firm and stable, scope will evolve over time, and/or the product itself will
and the technology is clearly understood. Traditional evolve over time, and/or the technology will evolve over
development models are well suited to situations where time.
contracts are involved and are of a fixed price and scope.
Unknown
This chart provides a

basic tool for finding the
right approach and mix
Chaotic of development
practices. The
decisions are based on
Technology
an assessment of the
predictability of
requirements and the
complexity of the
technology. The
predictability zone is
best suited to traditional
Predictable development
approaches, while the
chaotic zone is best
Known
suited to adaptive
development
approaches.
Known Unknown
Requirements
James, Michael and Luke Walter. “Scrum Reference Card.” Accessed August 12, 2019. PeopleCert SCRUM Master I - Study Guide
http://scrumreferencecard.com/scrum-reference-card/
17
Module #2
An Introduction to Scrum as
an Agile Framework
Learning Objectives
▪ Explain how Scrum has been used extensively worldwide.

▪ Describe the benefits of Scrum in relation to the common challenges faced by IT.
▪ Define the term "scrum" as a lightweight Agile software development framework that provides a basic structure
for small-sized teams, roles, artifacts, events, and rules for product development.
▪ List the five Scrum values: commitment; focus; openness; respect; & courage and identify examples of each one.

18
An Introduction to Scrum as an Agile Framework
What Is Scrum?
What is Scrum?
“A framework within which people can “The word "framework" means that much is not
address complex adaptive problems, while specified and must be devised by those using the
productively and creatively delivering framework. I equate Scrum to the
products of the highest possible value.” game of chess. You can read the
official rulebook for chess. The
moves, players, sequences,
The Five Scrum Values
scoring, etc. are all specified.
Learn them. Then you can play
chess.” - Ken Schwaber
The successful use of Scrum depends on people becoming

more proficient in living these five values. People personally
commit to achieving the goals of the Scrum team. The Scrum
team members have the courage to do the right thing and
work on tough problems. Everyone focuses on the work of the
sprint and the goals of the Scrum team. The Scrum team and
its stakeholders agree to be open about all the work and the
challenges with performing the work. Scrum team members
respect each other to be capable, independent people.
[Scrum Guide]
Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum: The Rules of the Game. ScrumAlliance, 2017.
Krish, Venkatesh. Techwell “A Brief history of Scrum”. Last modified October 15, 2012. Accessed August 13, 2019. PeopleCert SCRUM Master I - Study
https://www.techwell.com/techwellinsights/2012/10/brief-history-scrum Guide 19
An Introduction to Scrum as an Agile Framework
The Uses and Benefits of Scrum
Scrum has been used extensively, worldwide, to: The Key Benefits of Scrum
▪ Research and identify viable ▪ Scrum offers a team-based approach to

markets, technologies, and project work that allows a product
product capabilities development process to benefit from iterative
▪ Develop products and self-reflection
enhancements
▪ Helps a team learn how to estimate their own
▪ Release products and ability to address unfamiliar tasks
enhancements as frequently as
many times per day ▪ Exposes metrics about team effectiveness
▪ Develop and sustain cloud (online, secure, on- ▪ Encourages dialog about feature
demand) and other operational environments for implementation instead of static specifications
product use
▪ Sustain and renew products. ▪ Supports a rapid response to changing

market conditions in a sustainable manner
Green, David. Sitepoint.com “Power Up Your Team by Using Scrum Properly”. Last modified: May 22, 2016. Accessed: October 31
2019. https://www.sitepoint.com/introducing-scrum/
Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum: The Rules of the Game. ScrumAlliance, 2017. PeopleCert SCRUM Master I - Study Guide
Accessed August 12, 2019. https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide 20
Module #3
An Introduction to the
Scrum Framework
Learning Objectives
▪ List each of the Scrum practices: roles; events; and artifacts, and provide examples of each.
▪ Define "artifact" and each of the three main Scrum artifacts: product backlog, sprint backlog, product increment.
▪ Define empirical process control and define each of the three pillars of Scrum: adaption; transparency; and
inspection.
▪ Explain the importance of artifact transparency.
▪ Describe the three pillars of Scrum: inspection; adaptation; and transparency and explain their respective
purpose.
▪ Identify the purpose of roles, artifacts, and events in Scrum.
▪ Describe the impact of artifacts that are not fully transparent.

21
An Introduction to the Scrum Framework
The Scrum Framework
Master
Adapted from Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson
Education, 2013, 14. PeopleCert SCRUM Master I - Study Guide
22
A Walk-Through of the Framework
The Scrum framework is based on the principle

of empirical process control. Empirical
means that work needs to be transparent and
visible, and that actual work results are the only
true measure of progress. Thus, the Scrum
framework makes decisions and functions in a
fact-based, experience-based, and evidence-
based manner.

Doshi, Hiren. “Scrum.org” The Three Pillars of Empiricism (Scrum). Last modified December 4, 2016. Accessed August 23
13, 2019. https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum
The Three Pillars of Scrum - Adaptation
Adaptation
Adaptation is about being flexible;

adjusting; being Agile. Adaptation is
making changes as needed and when
needed, based on the inspection of the
actual transparent progress and results.
It’s about a continual alignment with
strategies and objectives, and making
continual improvement as well as
achieving efficiency and effectiveness.
A prime example of adaptation occurs

during the sprint event. The
development team may have been
working with a customer stakeholder to
develop a specific requirement. The
development may be nearing the
completion stage when the customer
realizes they need to modify the
requirement and make significant
changes.
Adaptation and Scrum are friendly

towards change. Although late in the
process, the development team
welcomes the change as a way to
ensure they produce a product that fully
meets customers’ needs and values.
24
The Three Pillars of Scrum - Transparency
Transparency
Transparency means that everything is

visible and nothing is hidden. This
applies to every role artifact and event
in the Scrum framework and, in general,
across the organization.
Strategies, goals, and objectives are

clearly visible and understood. All
interactions and conversations between
the roles should be open and
transparent. All planning and work
progress should be visible and
transparent.
A prime example of this transparency is

the work done daily by the development
team. They commonly work in open and
collaborative spaces with posted sprint
and progress charts visible to all team
members as well as passers-by.
Empirical Process Control
Work needs to be transparent and

visible, and actual work results are
the only true measure of progress.
Decisions and functions are fact-

based, experience-based, and
evidence-based.
Doshi, Hiren. Scrum.org. “The Three Pillars of Empiricism (Scrum)”. Last modified December 4, 2016. Accessed August 13, 2019. 25
https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum
The Three Pillars of Scrum - Inspection
Inspection
Inspection refers to “review and

inspection”. It goes hand in hand with
transparency. All the transparent and
visible artifacts, events, and role
activities need to be reviewed and
understood.
Actual results and the progress towards

goals and objectives are used to gather
lessons learned and to drive continual
improvement.
Inspection needs to be balanced and

done at appropriate times. It should not
be so frequent that it gets in the way of
the work, and not so far between that
there is no time to be agile and adjust to
changes.
A prime example of inspection occurs at

the end of a sprint event. The completed
work is demonstrated and inspected by
the customer, all stakeholders, and the
entire Scrum team.
26
Scrum Artifacts
What is a
Scrum
artifact?
“Scrum artifacts provide key

information that the Scrum
team and the stakeholders
need to be aware of for
understanding the product
under development, the
activities being planned, and
the activities done in the
project.”
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the
perceived state of the artifacts. To the extent that transparency is complete, these decisions have
a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be
flawed, value may diminish, and risk may increase.
The Scrum Master’s job is to work with the Scrum team and the
organization to increase the transparency of the artifacts. This work usually
involves learning, convincing, and change.
Artifact Transparency https://publications.axelos.com/PRINCE2Agile2016/content.aspx?page=pra_241&showNav=true&expandNav=true

Visual Paradigm. “What are Scrum Artifacts.” Accessed August 13, 2019. https://www.visual-paradigm.com/scrum/what-are-scrum-
artifacts/ PeopleCert SCRUM Master I - Study Guide
Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum: The Rules of the Game. ScrumAlliance, 27
2017. Accessed August 12, 2019. https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide
Module #4
Scrum Roles
Learning Objectives
▪ Define the terms "Product Owner", “Scrum Master” and “development team” and describe the characteristics of
each.
▪ Identify the responsibilities and accountabilities of a Product Owner, Scrum Master, and development team within
Scrum.
▪ Define the term "self-organizing team" and describe the characteristics of a self-organizing team.

28
Scrum Roles
The Scrum Team
What is
a role?
SCRUM MASTER
“A set of
responsibilities,
activities, and
authorities granted to
a person or team.
PRODUCT OWNER The role is defined in
a process or function,
and one person or
team may have
multiple roles.”
Adapted from: Layton, Mark C. Scrum for Dummies. New Jersey: John Wiley & Sons, 2015: 13
AXELOS. ITIL® Glossary of Terms English v.1.0. Last modified: 2011. Accessed October 30, 2019. PeopleCert SCRUM Master I - Study Guide
https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf 29
Scrum Roles
The Development Team
Characteristics of a
Successful
Development Team
T-shaped
The Development Team skills
The development team is accountable and responsible for:
Self-
organizing
▪ Being united and completely aligned with the goal of the project
Musketeer
▪ Being completely aligned with operational support and attitude
Plan the maintenance as well as the achievement of the service level
sprint. targets High-
bandwidth
communications
Help ▪ Developing, supporting, and maintaining the product Cross-
grooming the
functionally
product
▪ Responding to event alerts and acting upon incident, problem, diverse and
backlog.
and request tickets, as well as performing scheduled sufficient
Perform the maintenance, tuning, and update procedures
sprint Long-lived
execution.
▪ Owning, creating, and maintaining the sprint backlog artifact
Focused and
Inspect and committed
▪ Prioritizing the work in the sprint backlog
adapt.
Transparent
▪ Carrying out the five main sprint events of: communication
• Sprint planning
Deliver a potentially • Sprint execution Works at a
releasable increment sustainable Right-sized
• Daily Scrum
of “done” product at pace
the end of each sprint. • Sprint review
• Sprint retrospective
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson PeopleCert SCRUM Master I - Study Guide
Education, 2013.
30
Scrum Roles
What Is a Self-Organizing Team?
Self-Organizing
“Self-organizing teams choose how best to
accomplish their work, rather than being
directed by others outside the team.”
A self-organizing team is a group of motivated individuals who work together toward a goal, have the ability and authority to
make decisions, and can readily adapt to changing demands. Important characteristics include:
▪ They pull work for themselves and don't wait for their leader to assign work. This ensures a greater sense of ownership and
commitment.
▪ They manage their work (allocation, reallocation, estimation, re-estimation, delivery, and rework) as a group.
▪ They still require mentoring and coaching, but they don't require "command and control."
▪ They communicate more with each other, and their commitments are more often to project teams than to the Scrum Master.
▪ They understand the requirements and aren't afraid to ask questions to get their doubts clarified.
▪ They continuously enhance their own skills and recommend innovative ideas and improvements.
Development teams are structured and empowered by

the organization to organize and manage their own
work. The resulting synergy optimizes the development Cross-Functional
team’s overall efficiency and effectiveness.
“Cross-functional teams have all the
competencies needed to accomplish the
work without depending on others who are
not part of the team.”
Mittal, Nitin. Scrum Alliance. “Self-Organizing Teams – What and How”. Accessed: July 12, 2019.
https://scrumalliance.org/community/articles/2013/january/self-organizing-teams-what-and-how
Visual Paradigm. “How Scrum Team Works? - A Brief Guide”. Accessed: October 30, 2019. https://www.visual-paradigm.com/scrum/how-scrum-
team-works/ 31
Scrum Roles
The Correlation between Self-Organizing Teams and Scrum Values
Everyone focuses on the work of the

The Scrum team and its stakeholders sprint and the goals of the Scrum
agree to be open about all the work team.
and the challenges with performing
the work.
Scrum team members

respect each other to be
capable, independent people.
The Scrum team members

have courage to do the right People personally commit to
thing and work on tough achieving the goals of the Scrum
problems. team
32
Scrum Roles
The T-Shaped Professional
What are T-shaped Skills? https://www.hrzone.com/hr-glossary/what-are-t-shaped-skills

Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum: The Rules of the Game. ScrumAlliance, 2017. Accessed
August 12, 2019. https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide
Moghaddam, Yassi et al. “T-Shaped: The New Breed of IT Professional”. Last modified: September 26, 2016. Accessed: October 31, 2019. PeopleCert SCRUM Master I - Study Guide
"https://www.cutter.com/article/t-shaped-new-breed-it-professional-492976"
33
Scrum Roles
The Evolution of a Cross-Functional Development Team
The only possible way for this team to possess all the skills needed are for the team members to be cross-
functional. The latest term to describe having multiple and cross-functional skills is to say that technical team
members have “T-shaped” skill sets. In the “T” shape, people have one or more very proficient and deep skills
(the vertical part of the “T”), such as being an experienced programmer or tester. In the horizontal part of the “T”,
people have multiple secondary skills and experience, which makes them
broad-based and cross-functional, such as a tester also having basic PeopleCert SCRUM Master I - Study Guide
34
skills for coding, business, analysis, training, and deploying.
Scrum Roles
The Development Team – Ideal Size
The Ideal Size of a Development Team
The optimal development team size is between three and nine technical people.
9 This range keeps the team small enough to remain nimble, yet large enough to complete
significant work within a sprint.
A minimum of three people is needed for basic synergy; and more than nine people
should be avoided as they require too much coordination.
3 The size of the team depends largely on the range of the combined cross-functional
skills of its members, where low cross-functional skill sets result in teams at the larger
end of the size range.
The team size should be six plus or minus three, excluding the Product Owner and
Scrum Master.
Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum: The Rules of the Game. ScrumAlliance, 2017. Accessed August 12, 2019.
https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide PeopleCert SCRUM Master I - Study Guide
Moghaddam, Yassi et al. “T-Shaped: The New Breed of IT Professional”. Last modified: September 26, 2016. Accessed: October 31, 2019. 35
https://www.cutter.com/article/t-shaped-new-breed-it-professional-492976
Scrum Roles
The Product Owner
The Product Owner

The Product Owner is the sole person accountable and responsible for owning and managing
the product backlog. Product backlog management includes:
• Ensuring and establishing a product vision and communicating that vision
• Monitoring and managing the product against its IT service level operational targets and service
charter business outcomes objectives (ITIL concept)
• Creating the product backlog and adding items to the product backlog
The Product Owner
• Maintaining a product change log for all strategic, tactical, operational, and improvement
role is a single point of initiatives
contact (SPOC) • Ensuring the development team understands the items in the product backlog to the level
providing a focus and needed to begin collaborating with the customer and stakeholders
• Ordering the items in the product backlog based on the business and risk priority that best
connection between
achieves higher-level strategies, goals, and objectives. By doing this, the Product Owner:
the product and the
▪ Establishes the development schedule based on the priority of the product backlog
customer(s) of that items and their estimates of effort
product. ▪ Communicates and collaborates effectively and regularly with the customer
▪ Carries out ongoing product backlog grooming and maintaining a constant state of
readiness for the items that are a top priority
▪ Ensures the product backlog is transparent, visible, and clearly understandable to all
stakeholders
▪ Monitors the project against its stated goals, objectives, and constraints
Morris, David. Scrum in Easy Steps – an ideal framework for agile projects. UK: In Easy Steps Limited, 2017.
Scrum Roles
The Product Owner
The Product Owner

▪ The Product Owner is responsible for maximizing the value of the product resulting from the
work of the development team.
▪ The Product Owner is the sole person responsible for managing the product backlog.
▪ Develops their product’s vision, strategy, and roadmap
▪ Understands their customers’ stated needs
▪ Works with stakeholders to capture all internal needs
▪ Takes ownership of their product’s release plan
▪ Measures and is accountable for the return on the investment
The Product Owner Characteristics
Morris, David. Scrum in Easy Steps – an ideal framework for agile projects. UK: In Easy Steps Limited, 2017. PeopleCert SCRUM Master I - Study Guide
37
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013, 172.
Scrum Roles
The Scrum Master
The Scrum Master Servant

The Scrum Master is an accountable and responsible role that is Leader
focused on leadership and guidance rather than hands-on
management. The role will:
▪ Understand Scrum fully and, in turn, coach the Scrum team to Coach
adhere to Scrum theory, practices, and rules
▪ Support and encourage that Scrum is followed entirely and
correctly by the Scrum team
▪ Ensure Scrum is understood by stakeholders outside of the Change
Scrum team and will coach them to interact with the Scrum Agent
team in a helpful and success-focused way
▪ Establish Scrum practices and rules appropriate to the
organization and Scrum team Interference
▪ Ensure the organization and Scrum team are constantly Shield
learning and being trained in Agile and Scrum practices
▪ Problem solve and remove obstacles or impediments for the
Scrum team and across the organization, where appropriate Process
▪ Shield the Scrum team from unnecessary external distractions, Authority
disturbances, and interference
▪ Observe and coach the Scrum team by leading Scrum
meetings Impediment
▪ Monitor the performance of the Scrum roles and the overall Remover
performance of the Scrum team
Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum: The Rules of the
Game. ScrumAlliance, 2017.
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson PeopleCert SCRUM Master I - Study Guide
Education, 2013.
38
Scrum Roles
The Characteristics of a Successful Scrum Master
Transparent Collaborative Protective Knowledgeable Questioning Patient
Servant Leadership
“Servant-leadership is fully in line with the Scrum

values of courage, openness, respect, focus, and
commitment. It's the backbone of the Scrum Master
role.
A Scrum Master is a servant-leader whose focus is

on the needs of the team members, and those they
serve (the customer), with the goal of achieving
results in line with the organization's values,
principles, and business objectives.”
A Scrum Master is not a master of the team, but a master at encouraging,

enabling, and energizing people to gel as a team and realize their full potential.
- Geoff Watts
Overeem, Barry. Scrum.org. “The Scrum Master as a Servant-Leader”. Last modified July 20, 2015. Accessed August 12, 2019.
https://www.scrum.org/resources/blog/scrum-master-servant-leader
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013.
39
Scrum Roles
The Characteristics of a Servant Leader

Overeem, Barry. “The Scrum Master as a Servant-Leader”. Scrum.org. https://www.scrum.org/resources/blog/scrum-master-servant-leader Last
modified July 20, 2015. Accessed August 12, 2019.
40
Scrum Roles
10 Servant Leadership Characteristics 1-5
While traditional leadership styles accumulate a great extent of power at the top rungs, servant
leadership puts other people’s need first and shares power with them.A servant leader actively
contributes in the personal development and performance of their team. Here are 10 characteristics and
traits that distinguishes a servant leader from the more traditional ones.
1. Empathy: A servant leader has the ability to recognize and understand feelings and emotions that are
experienced by their team. Such a leader will care for other people and will deeply experience emotions
that match what others are feeling. Since they understand others so deeply, their actions are motivated
by a genuine desire to help others.
2. Listening: By paying complete attention to what others are saying, servant leaders are able to get a
complete understanding of all interpersonal situations that they are dealing with. They use active
listening to resolve conflicts, counsel others, and also to impart training.
3. Awareness: Many people in positions of power are blissfully ignorant of their shortcomings, but not
the servant leader. They are completely aware of their strengths, weaknesses, values, emotions, and
feelings. This self-awareness allows the servant leader to understand personal biases and set them
aside while making decisions.
4. Healing: Followers typically desire for a leader who has a sincere interest in fostering their emotional
and spiritual well-being. By taking an active role in promoting the mental and emotional strength of their
employees, servant leaders typically inspire an exceptional level of trust and faith from others.
5. Conceptualization: An important quality of a servant leader is their ability to conceptualize, or

imagine the possibilities of future and reconcile it with current realities. This ability helps the leader
visualize a bright future, and take the necessary steps to get there.
Overeem, Barry. “The Scrum Master as a Servant-Leader”. Scrum.org. https://www.scrum.org/resources/blog/scrum-master-servant-leader
Last modified July 20, 2015. Accessed August 12, 2019.
PeopleCert SCRUM Master I - Study Guide 41
Scrum Roles
10 Servant Leadership Characteristics 6-10
6. Persuasive: It is easy for a servant leader to influence the opinions and actions of others through
persuasive skills. This quality comes in handy in negotiations with business partners, customers, and
stakeholders. Since servant leaders are committed to the welfare of others, they use this ability only to
influence others positively.
7. Stewardship: A servant leader acts as a steward for the organization’s resources. They assume
complete responsibility for planning and managing all available resources for the betterment and
prosperity of the organization, employees, and stakeholders.
8. Foresight: Everything is connected – the past, the present, and future. Servant leaders have an
intuitive ability to predict what is likely to happen in future, based on the past and the present. This
foresight enables these leaders to plan ahead.
9. Community building: Under a servant leader, people come together for a common purpose. They
are able to create a feeling of belonging to something bigger than each individual, and foster team spirit
and a sense of community. Servant leaders also deeply care for this community that they create.
10. Committed to growth of others: A servant leader takes it upon themselves to develop others. They
are likely to help employees chart out a clear career path and provide them with resources to progress
from one level to the next.
Overeem, Barry. “The Scrum Master as a Servant-Leader”. Scrum.org. https://www.scrum.org/resources/blog/scrum-master-servant-leader

Last modified July 20, 2015. Accessed August 12, 2019.
Scrum Roles
The Scrum Master's Service to the Product Owner
▪ Ensuring that goals, scope, and the product domain are understood
as much as possible by everyone on the Scrum team
▪ Finding techniques for effective product backlog management
▪ Helping the Scrum team understand the need for clear and concise
product backlog items
▪ Understanding product planning in an empirical environment
▪ Ensuring the Product Owner knows how to arrange the product
backlog to maximize value
▪ Understanding and practicing agility
▪ Facilitating Scrum events as requested or needed
The Scrum Master’s Service to the Development Team
▪ Coaching the development team in self-organization and cross-

functionality
▪ Helping the development team create high-value products
▪ Removing impediments to the development team’s progress
▪ Facilitating Scrum events as requested or needed
▪ Coaching the development team in organizational environments in
which Scrum is not yet fully adopted and understood
Sutherland, Jeff. Jeff Sutherland’s Scrum Handbook. Scrum Training Institute, 2010 PeopleCert SCRUM Master I - Study Guide 43
Scrum Roles
The Scrum Master's Service to the Organization
▪ Leading and coaching the organization in its Scrum adoption

▪ Planning Scrum implementations within the organization
▪ Helping employees and stakeholders understand and enact Scrum
and empirical product development
▪ Causing change that increases the productivity of the Scrum team
▪ Working with other Scrum Masters to increase the effectiveness of
the application of Scrum in the organization.
The Stakeholders
Scrum – ScrumMaster https://www.tutorialspoint.com/scrum/scrum_scrummaster.htm

Sutherland, Jeff. Jeff Sutherland’s Scrum Handbook. Scrum Training Institute, 2010
44
Scrum Roles
Agile Work Environments – Co-Location
▪ Workspace that promotes collaboration and face-to-face

communication but also allows for an uninterrupted focus
▪ Visible information radiators
▪ Plenty of flexible and physical collaboration tools
Agile Work Environments – Virtual Teams
▪ Appropriate collaboration and communication tools (video-

conferencing, shared screens, instant messaging, digital agile
management tools)
▪ Negotiating work hours across time zones
▪ Cultural connectedness should be fostered
▪ One-off in-person team formation or project kick-off gathering
Layton, Mark C. Scrum for Dummies. New Jersey: John Wiley & Sons, 2015.
45
Scrum Roles
Transitioning to Agile: How the Roles May Evolve
46
Scrum Roles
Transitioning to Agile: The Roles and Skills Education
Education Scrum Product Development

Master Owner Team
PeopleCert SCRUM Master I X X X
PeopleCert SCRUM Master II X
PeopleCert Business Relationship Management X X
Lean IT Foundation X X X
Lean IT Leadership X
Lean IT Kaizen X
ITIL 4 Foundation X X X
ITIL 4 Specialist – Create, Deliver, and Support X X
ITIL 4 Specialist – Direct, Plan, and Improve X X
PeopleCert DevOps Fundamentals X X X
PeopleCert DevOps Leadership X
47
Module #5
Multilevel Planning
Learning Objectives
▪ Define the term multilevel planning

▪ Explain how multilevel planning helps teams

48
Multilevel Planning
The Planning Onion
Adapted from:
Morris, David. Scrum in Easy Steps – an ideal framework for agile projects. UK: In Easy Steps Limited, 2017
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013 PeopleCert SCRUM Master I - Study Guide
Berteig, Mishkin. “The Agile Planning Onion is Wrong”. Agile Advice. Last modified April 24, 2011. Accessed August 12, 2019. 49
http://www.agileadvice.com/2011/04/24/agilemanagement/the-agile-planning-onion-is-wrong/
Multilevel Planning
The Planning Onion
“The planning onion is often used as a simple and effective

way to show the layers of responsibility for getting things Multilevel Planning Helps Teams:
done. Each layer of the onion drives the goals of the layers
below, sets timeframes, and defines ownership and ▪ Gain a better understanding of long-term goals
interaction. ▪ Create more realistic strategies for achieving
those goals
The planning onion is also a brilliant way to describe the ▪ Gain clarity on their short-term responsibilities
Three Pillars of Scrum. Transparency must happen at all ▪ Understand how these responsibilities can
levels – from planning to progress reporting – for the contribute to long-term objectives.
organization to have a common understanding and to perform
daily activities constantly aligned at achieving strategies and
business results. If all layers are transparent, then all levels of
progress and alignment can be inspected and reviewed. Adaptation at all levels follows. The revelation of changes and/or
progress deviation at all levels allows the Scrum framework to make the necessary changes and adapt to the new reality.
A third dimension to the planning onion illustrates the frequency of activity at each layer. At the top layer, the frequency
between strategy generation activities is quite long, perhaps once per year. Progressively, the activities become more
frequent and of shorter durations, down to the most frequent planning activity of day planning through the daily Scrum event.
Overall, the planning onion is a great tool to visualize the larger workings between the Scrum roles, artifacts, events, and
rules. It also illustrates how Scrum adheres to the Agile values and principles for value-based, iterative, incremental, and
business-/customer-focused delivery. The result is a faster time to market, better delivery predictability, increased customer
responsiveness, and the ability to change direction by managing changing priorities, as well as enhanced software quality
and improved risk management.”
My Agile Mind. “What does the Planning Onion Mean to You?” Last modified October 28, 2011. Accessed August 13, 2019.
myagilemind.wordpress.com/2011/10/28/what-does-the-planning-onion-mean-to-you/
Doshi, Hiren. Scrum.org “The Three Pillars of Empiricism (Scrum)”. Last modified December 4, 2016. Accessed August 13, 2019. PeopleCert SCRUM Master I - Study
https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum Guide 50
Module #6
Preparing the Product
(Planning Level) 1/2
Learning Objectives
▪ Identify the attributes of a product backlog and describe its purpose in Scrum.
▪ Explain how the product backlog can evolve as the product and environment evolves.
▪ Define the terms "product backlog item (PBI)", "requirements statement", "user stories", "acceptance criteria",
“increment”, and "conditions of satisfaction“.
▪ Identify the characteristics of an effective PBI.
▪ Define the terms "epic" and "feature" in relation to ensuring that a PBI is small during the product backlog
grooming.
▪ Describe the difference between an "epic", "theme“, and "user story“.
▪ Describe the role and structure of a user story including methods used to effectively gather them.
▪ Identify each of the elements in the DEEP mnemonic: detailed appropriately; emergent; estimated; and
prioritized, and describe its purpose.

51
Module #6
Preparing the Product
(Planning Level) 2/2
Learning Objectives
▪ Identify each of the elements in the INVEST mnemonic: independent; negotiable; valuable; estimable; small; and
testable during the product backlog grooming.
▪ Describe the overall purpose, process steps, and roles of the Scrum team involved in the product backlog
grooming.
▪ Define the term "story points" in relation to ensuring that a PBI is estimable during the product backlog grooming.
▪ Differentiate between the three referencing techniques of single reference story, triangulation, and affinity
mapping.
▪ Describe the Fibonacci sequence as a valid approach to estimating story points.
▪ Define the terms "development work", "timeboxing", "velocity", "visual management" and "information radiators"
related to a sprint (in Scrum).
▪ Identify estimation techniques used to calculate velocity and its purpose.
▪ Define the term "capacity" in relation to sprint planning including the various factors that influence a team's
capacity.

52
Preparing the Product (Planning Level)
The Scrum Practices
Adapted from Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013, 14. PeopleCert SCRUM Master I - Study Guide
53
The Product Backlog
There are several important points to note regarding this

definition:
Product Backlog
We refer to “product” and not “project”. A project implies a
“An ordered and prioritized list of new
one-time activity, while a product implies an ongoing
product features, changes to existing
collection of all the work that must be done from the very
product features, bug fixes, infrastructure
beginning to the very end of the product. The product
changes, or other activities that is a single backlog is dynamic over the life cycle of the product and is
point of reference for all planned work never complete.
that must be done for the product.”
We refer to a “single point of reference” to call out the need
for a single source list that drives the life cycle management
of changes (additions, modifications, deletions) to the
The product backlog is at the center of product. Without this centralization of work, there can be no
the Scrum framework. Everything in value management and accountability.
Scrum is derived and driven from it. We call out “all that must be done” to imply a scope that is
greater than “requirements” and “features”. All that must be
done includes the following:
▪ Functional and non-functional requirements from the
customer
The Product Owner is the sole person ▪ Functional and non-functional requirements from the IT
responsible for managing the product provider
backlog. ▪ Problems that need to be investigated
▪ Continual improvement initiatives for both the customer
and IT provider
Agile Alliance. ”Agile Glossary”. Last modified: 2011. Accessed: October 30, 2019. https://www.agilealliance.org/agile101/agile-glossary/ PeopleCert SCRUM Master I - Study Guide
54
The Product Backlog
The product backlog is at the center of the Scrum framework.

Everything in Scrum is derived and driven from it.
A prioritized list of:
▪ new features
▪ changes to
existing features
▪ bug fixes
▪ infrastructure
changes
▪ other activities
that a team may
deliver to achieve
a specific
outcome of a
product
55
The Product Backlog
The Product Backlog:

▪ is the only source of work for the
team
▪ provides a centralized and shared
understanding of what to build
▪ must contain a prioritized list of
everything needed for the product
▪ is dynamic and evolving;
requirements never stop changing,
so a product backlog is a living
artifact
▪ must be visible to all project team
members
A product backlog is never complete. The earliest development of it lays out the initially known and best-
understood requirements. The product backlog evolves as the product and the environment in which it will be
used evolves. The product backlog is dynamic; it constantly changes to identify what the product needs to be
appropriate, competitive, and useful. If a product exists, its product backlog also exists.
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013. 56
A Key Artifact: Product Backlog Items
Product Backlog Item

“An item in the product backlog (PBI),
such as a feature, defect, or occasionally
technical work that is valuable from the
Product Owner’s perspective. Can be
classified as an epic, feature, or user
story.”
Epic
An epic typically describes an entire workflow and is large and
broadly defined.
Epics are broken down into smaller PBIs (features and user
stories) when it is time to plan the work into sprints.
An epic can span more than one project if multiple projects are
included in the board to which the epic belongs.
Epics are useful when starting a product for the first time or
Months
when gathering a new set of requirements for a release update.
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013. PeopleCert SCRUM Master I - Study
Guide 57
Product Backlog Items
Feature
A collection of related user stories
Used for products that are large and/or complex
Used as a planning and decomposition level between an epic

and its stories
User Story
A story describes a discrete part of the overall product’s
functionality. These act as the building blocks for the product.
The story describes a functionality that enables a customer to

achieve a specific job.
Use language that is understandable to both business and

technical people.
Note: A user story is similar to a PBI, but it goes beyond a specific

change or requirement. It puts the end-user and their experience front
Days and center. It’s the smallest unit of work in agile development,
expressed from the user’s perspective. This is a functional increment
that’s expected to contribute to the value of the overall product.
58
What to Do with Epics After Splitting Them: Themes
▪ A theme is a large business functionality that acts as a category or grouping of user stories (epics
through to the small user story).
▪ Themes are used for structuring and understanding what the product looks like from the business
functionality point of view and, as such, is a key for release planning.
▪ Typically, a theme starts as an epic user story. Once that epic is split into smaller stories, the epic is
no longer needed as a PBI. Therefore, we keep the epic and features as themes to build the
product structure.
▪ The rule in Scrum is to use themes only when needed by the Product Owner.

59
How Epics, Features, and Stories Typically Map to Sprints

Morris, David. Scrum in Easy Steps – an ideal framework for agile projects. UK: In Easy Steps Limited, 2017, 49.
60
Techniques for Gathering User stories
How to Write Good User Stories
1. The story is always written from the user’s perspective.

2. Use personas to discover the right stories.
“In Scrum and other Agile project frameworks,
3. Create stories collaboratively.
user stories often act as requirements. Each
4. Keep stories simple and concise.
story represents a portion of the business
5. Start with epics.
value that a team can deliver in an iteration. A
6. Refine stories until they are ready.
common format is: “As a (role), I want (goal) so
7. Add acceptance criteria.
that I can (reason).” Here's an example: “As a
8. Use paper cards or sticky notes.
customer, I want a shopping cart functionality
9. Keep stories visible and accessible
so that I can buy items online.” User stories are
using physical or digital boards.
captured in the product release backlog.”
10. Don’t solely rely on user stories.
Graffiius, Scott. AgileScrumGuide.com “Techniques for Gathering User Stories”. Last modified; October 25, 2017. Accessed: October 31, 2019.
https://agilescrumguide.com/blog/files/Techniques-for-Gathering-User-Stories.html PeopleCert SCRUM Master I - Study Guide
61
Roman Pichler “10 Tips for Writing Good User Stories”. Last modified March 24th, 2016. Accessed August 13, 2019.
https://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
The Types of Acceptance Criteria
Acceptance Criteria ▪ Come from the users who specify the requirements
“Can be thought of as the conditions ▪ Must state the intent, not the solution
necessary to pass user testing in the ▪ Should be in relatively simple language
development process” ▪ Are used to demonstrate the requirement to the user
during the sprint review event
Lowe, David. “Using Scrum & Kanban in the Real World. Acceptance Criteria and Conditions of Satisfaction”. Last modified October 26, 2015.
Accessed August 13, 2019. https://scrumandkanban.co.uk/acceptance-criteria-and-conditions-of-satisfaction/ PeopleCert SCRUM Master I - Study Guide
Segue Technologies “What Characteristics Make Good Agile Acceptance Criteria?” Last modified September 3, 2015. Accessed August 13, 2019. 62
https://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria
Product Backlog Grooming
Product Backlog The Scrum event of backlog grooming (also called backlog
Grooming refinement) is an ongoing activity. It relates to the Agile characteristic
of the release and product backlogs that they are always dynamic and
always capable of changing. This is often called emergent
“Product backlog grooming is when the requirements gathering or, more traditionally, as progressive
Product Owner and some, or all, of the elaboration.
rest of the team refine the backlog on a
regular basis to ensure the backlog Product backlog grooming occurs regularly and regardless of whether
contains the appropriate items, that they there is a defined release. The first aspect of backlog grooming is the
are prioritized, and that the items at the result of constant collaboration with all the product stakeholders who
top of the backlog are ready for delivery.” can bring a new PBI, or a request to modify or remove an existing
PBI, to the Product Owner at any time. Such requests may include:
▪ A technical bug (an ITIL problem) that needs to be investigated
• Agile often calls these bugs “escaped defects” when they
are found in the operational environment
▪ A quality improvement work item to refactor code that is not
extensible
An ongoing process where the Product ▪ A new customer feature request
Owner and the development team ▪ A change to an existing customer feature request
collaborate to add detail, estimate, and ▪ A process improvement that will benefit future sprints
order the PBIs in the product backlog. ▪ A learning opportunity that will benefit the product and/or future
sprints
The Product Owner can update items at any
time. The second aspect to backlog grooming is the act of reviewing and
revising existing PBIs. Again, backlog grooming occurs regularly and
The development team is responsible for regardless of whether there is a defined release.
estimating the PBIs.
Agile Alliance. Agile Glossary. Last modified: 2011. Accessed: October 30, 2019. https://www.agilealliance.org/agile101/agile-glossary/]
63
When Product Backlog Grooming Happens
The green line/arrow

represents an ever
changing and evolving
product backlog.

64
Product Backlog Grooming
The higher ordered the PBI,

the clearer and more
detailed they become.
Product backlog items are

ready for selection to be
included in the next sprint.
PBIs are refined so that any

one item can reasonably be
“done” within the sprint time-
box.

65
Good Product Backlog Grooming Characteristics
An acronym coined by Roman Pichler and Mike Cohn for remembering a set of criteria used to evaluate the quality
of a product backlog. The criteria are detailed appropriately, emergent, estimated, and prioritized.
Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Boston, MA: Pearson Education, 2010. PeopleCert SCRUM Master I - Study Guide
66
MoSCoW Prioritization
ProductPlan.com. “Product Management: MoSCoW Prioritization”. Accessed: October 30, 2019 PeopleCert Scrum Master I - Study Guide
https://www.productplan.com/glossary/moscow-prioritization/ 67
Criteria for Prioritizing Product Backlog Items
Clearing Clearing the

Business Technical Retiring risk Testing a
dependent
value debt early hypothesis backlog
work
Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Boston, MA: Pearson Education, 2010. PeopleCert SCRUM Master I - Study Guide
68
INVEST in Good Stories
Large epic-sized The Product Owner Each PBI must All PBIs require A PBI should be Testing can be
PBIs to the smallest is responsible for relate to the three types of sized so that a team thought of as a way
all need to be negotiating and business value to estimates in order to could complete it of clarifying PBIs.
independent of each discussing the justify why it is make them with a few days of
other. INVEST principles needed, and in what manageable: effort, effort. Testing is done from
with stakeholders. priority. cost, and benefits. many perspectives
PBIs that can The extent to which including the
potentially be The higher the This business value Effort estimates are we break large epic- functional testing of
developed, tested, negotiability, the is what determines preferred in Scrum sized PBIs into their features and
and deployed more it allows for the order and over time estimates. smallest component functions and non-
separate from each changing sequence in the is determined by functional testing for
other and have a requirements later. product backlog. Cost and benefit considering each quality,
unique value estimates should be INVEST principle. manageability,
proposition to one One of the highest Value is defined by: translated into security, and
or more objectives when benefit, cost, risk, financial terms. The smaller the PBI, usability.
stakeholders. negotiating the and learning. the more likely it is
INVEST principles to be accurately The smaller the PBI,
PBIs that can be is the value to the estimated, valued, the easier it is to
prioritized and business. and tested to be define and carry out
sequenced relative correct. the testing activity.
to one another.
No PBI can be considered done or can be

deployed without being tested.
Wake, Bill. “INVEST in Good Stories, and SMART Tasks”. Last modified: August 17, 2003. Accessed: October 30, 2019. 69
https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Technical Dependencies
When estimating the size of product backlog items it is important to consider technical dependencies.
Brown, Roger. “Managing Technical Dependencies”. Agile Coach Journal. Last modified April 26, 2012. Accessed August 12, 2019. PeopleCert SCRUM Master I - Study Guide
https://www.agilecoachjournal.com/2012-04-26/managing-technical-dependencies 70
Combining User Stories
Combine user stories when there are a number of “zero-effort” updates or

fixes, such as changing the font size on a form and moving the position of a
field.
A product backlog full of such minor stories will appear overwhelming when
in fact it is not.
Combine user stories that are business or technically dependent on another

user story.

71
Dealing with Problems and Legacy Bugs
PBIs in the product Errors, problems and bugs are

backlog re-work. They are wasteful and
= planned work for don’t add value to the customer.
adding value to the Such waste needs to be made
customer. transparent and visible.
Good Practice:
The best and most common approach is to put all errors, bugs, and
problems into a separate task board called the bug list or defect board.
This allows these items to be prioritized against each other without
cluttering the product backlog.

72
Dealing with Incidents and Immediate Problems
Requests, incidents, and problems

that need to be addressed right away
are considered unplanned and
operational in nature.
Such items should be added to the sprint
backlog to show the transparency and
visibility of the interruption.
When such issues arise and are assigned to a Scrum development

team, the team is responsible to stop its development work and
swarm to restore normal service as soon as possible, and/or to
investigate the problem as part of their support role.

73
Root Cause Analysis Techniques
Fault Tree
Affinity Hypothesis
Brainstorming Analysis
Mapping Testing
(FTA)
Technical
Ishikawa
Observation
Diagrams
Post (TOP)
The team should collaborate on
understanding the root cause of any
problems and agree on team
improvement actions to tackle them.
Sologic
Five-Why’s
Method
Chronological Fault
Analysis Isolation
74
Delivering a High-Quality Product Increment and Reducing Technical Debt
Conditions of
Sprint Acceptance Definition of Good Practice:
satisfaction
backlog criteria done (DoD) Bug list board
(CoS)
High-quality product increment and reduced technical debt
Fit for purpose Fit for use

Good Practice: Bug List Board
By including a bug list board, the Scrum framework also ensures that technical debt is
managed down.
A specific number of A specific number of Each sprint planning

top-priority “bugs” will hours will be devoted will assess which top-
be added to the sprint in each sprint priority bugs will be
backlog each and execution to fixing added to the sprint
every sprint. legacy bugs. backlog.

Estimation
Estimating means making an educated guess. The most common business

estimates (guesses) for projects are time and cost. Like all guesses, they tend to
Estimation be more accurate if we have done the work or something similar before, or if we
can clearly specify all the steps necessary to build our feature and consider all the
“A rough calculation of the risks that might happen.
value, number, quantity, or
The latter approach is how traditional project management makes its estimates;
extent of something.”
they are task detailed and time consuming to complete. They are time-based
guesses based on identifying each step and activity necessary to complete a
~ Approximation, educated
requirement. And they inherit a big, traditional problem: that time-based estimates,
guess, assessment
once made, are instantly taken as a commitment to finish activities in the time
specified. The result of this activity is that our estimates are padded with extra time
so that those doing the work are not penalized (blamed for failure) for unexpected
risks or complications that may delay them. In addition to this padded time
estimate, traditional development teams tend to work more slowly as they “fill time”
so that they are not found out to be padding time estimates. This is a vicious cycle
of inefficiency that Agile environments want to avoid.
Agile thinking is to not waste time on guesses and to avoid padding of estimates.
Agile estimates are effort-based (or size-based) instead of time-based, and are
user story-based instead of separate tasks-based. This does not mean that we
can’t speak about time and end dates, but that we do not make an estimate into a
commitment and guarantee. It becomes simply a number assigned to a
requirement (PBI) that can be compared to other requirements (PBIs) and their
respective numbers. This is a fundamental difference and a key to success for
Agile project management: Agile estimates can be compared to one another for
accuracy.
77
Estimation Concepts
Coach and
▪ Estimate as a team facilitator
▪ Estimates are not set in stone
▪ Accuracy is more important than precision

Clarification Collaborative
▪ Estimate in relative sizes instead of absolute estimation
▪ Keep estimates manageable
Story Points
Ideal Time The advantage of using story
points is that there is no
The time estimated to complete a mention of time. Thus we
user story in a perfect situation
avoid all the inherent and
traditional problems with time
Story Point
estimates becoming
“In simple terms, a story point is a number that tells the team about commitments to that time,
the difficulty level of the story. The difficulty could be related to and the resulting padding and
complexities, risks, and efforts involved.” blame.
Story-point estimating requires one or more sample user stories that have already The disadvantage of using
been completed. It’s an estimate relative to a known reference point. These stories story points is that there must
need to be assigned a size – called the story point – such as size one to 13. be previous and known work
that the development team
Like ideal time, the team that makes the estimation does not have to factor in risks
has already completed
or unknowns or any source of possible delay.
together.
Visual Paradigm. “What is Story Point in Agile? How to Estimate a User Story?” Accessed: October 30, 2019. https://www.visual- PeopleCert SCRUM Master I - Study
paradigm.com/scrum/what-is-story-point-in-agile/ Guide 78
Estimation Techniques
Agile estimating techniques are designed to be fast The Benefits of using the Fibonacci Sequence
and simple. They reflect the realization that estimates
An exponential scale (one that grows at an increasing rate)
are guesses and that guesses do not require fine
provides more detail for smaller tasks, and forces uncertainty for
tuning (such as estimating 1.5 ideal hours or story
larger tasks. This helps build your estimates with increasing
points). As a result of this thinking, we like to talk
uncertainty as the time estimates get longer, creating a more
about creating standard “buckets” of ideal time and
efficient and effective estimation.
story points.
More accurate estimations and optimal user stories.
There are different scales that can be used to assign
estimates. The key to any scale used is that there are
sufficient gaps between the numbers or sizes so there
is no wasted time in discussing insignificant “It is better to be
differences. Note that most scales have a zero roughly right than
number included. This number allows very short and precisely wrong.”
simple efforts, such as adding a new field to a form to
be estimated without skewing the primary scale John Maynard Keynes
British Economist
beginning at one.
“News flash: An estimate is not a guarantee. An

estimate is simply a prediction based on known
information and input at a given point in time. ”
Ilan Goldstein
Velasquez, Robert. eLearning Industry “5 Reasons Using the Fibonacci Sequence Makes you Better at Agile Development”. Last modified
November 7, 2017. Accessed August 14, 2019. https://elearningindustry.com/using-the-fibonacci-sequence-makes-better-agile-development-
PeopleCert SCRUM Master I - Study
5-reasons
Guide 79
Goldstein, Ilan. Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips. Boston, MA: Pearson Education, 2014.
Planning Poker
A consensus-based approach used to estimate

the relative sizes of product backlog items that
balances group thinking and individual thinking.
Only the development team plays
Numbered Cards: The Scrum Master facilitates
1 – 3 small items 5 – 13 medium items

20-40 large items 100 extra large items
The Product Owner reads the
0: The work will take an insignificant amount of time and won’t affect velocity requirements and provides details
Infinity: The work is too large to assess and must be broken down.
Planning Poker Rules
Owner
Goldstein, Ilan. Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools & Tips. Boston, MA: Pearson Education, 2014, 72.
Morris, David. Scrum in Easy Steps – an ideal framework for agile projects. UK: In Easy Steps Limited, 2017. 80
Triangulation Estimation
The triangulation technique is used for story point

estimates. Having said this, there is no reason we The Product Owner reads a user story “As a user, I
want to be able to filter my calendar to see
couldn’t also use triangulation with ideal time. Note
appointments and tasks completed, so that I can use
that if used with ideal time, then we would be the calendar as an audit trail for my work year.”
blending the concept of story points and relative
estimating with ideal time (which is not a relative If the technical team agrees the new story is larger
than the 1-point reference and smaller than the 8-point
estimating technique – thus the blended approach).
reference, then – if using the Fibonacci scale – the
team would have estimate choices between 2, 3, and
5. As mentioned, the estimate would be more accurate
and faster than having a single reference.
Triangulation makes the reference

activity more accurate and faster
than having a single reference. The
technique gets its name from
having a larger and smaller
reference to a user story being read
by the Product Owner to the
technical team. The third estimate
is the one in between the two
references that the technical team
makes.

81
When Do We Re-Estimate?
As PBIs (user stories) move higher up in the product backlog, they are split into NEW, smaller, and more manageable PBIs.
Each new PBI (user story) needs to be estimated by the development team.
In this way, epic PBIs (user stories) are re-estimated and become
more accurate as they rise in priority and get split apart in the
product backlog.
We also re-estimate during the sprint

planning event. PBIs (user stories) are read
by the Product Owner based on top
priorities in the product backlog.
By this time, the stories have been refined

by the Product Owner and contain both
user acceptance criteria and conditions of
satisfaction (CoS).
The development team will discuss the item further and break it
into the basic tasks needed for completion.
With this deeper understanding, the development team will be

asked by the Product Owner to re-estimate.

82
Module #7
Scrum Artifacts
Learning Objectives
▪ Define release planning, describe its goal, and identify the steps required to complete it.
▪ Identify the timing, participants, and process steps involved in the release backlog.
▪ Define "fixed-scope release" and "fixed-date release“.
▪ Identify the correct length of time for a sprint.
▪ Define the terms "conditions of satisfaction", “definition of done (DoD)”, and “definition of ready”.
▪ Differentiate between DoD and the acceptance criteria.
▪ Define technical debt and distinguish between its types: naïve; unavoidable; and strategic debt, and explain the causes of
technical debt and the consequences of poorly managed levels of technical debt.
▪ Define the terms "development work", "timeboxing", "velocity", "visual management“, and "information radiator" related to a
sprint (in Scrum).
▪ Identify estimation techniques used to calculate velocity and its purpose.
▪ Define the term "capacity" in relation to sprint planning including the various factors that influence a team's capacity.
83
Scrum Artifacts
A Key Artifact: The Release Backlog
Release Backlog
“The release backlog
is the collection of
PBIs that have been
selected or will be
selected for the
current release work
effort.”
The release backlog is a subset of the product backlog and

shares all the same characteristics, including being dynamic
over the life cycle of the release.
The Product Owner is the sole person responsible

for managing the release backlog.
Sutherland, Jeff. Jeff Sutherland’s Scrum Handbook. Scrum Training Institute, 2010. PeopleCert SCRUM Master I - Study Guide
84
Scrum Artifacts
Release Planning
“When will we be done? The goal of release planning is to

determine what constitutes the most
Which features can I get by the end of the year? valuable next release and what the
desired level of quality is. The
How much will this cost?
constraints of scope, date, and budget
Release planning must balance customer value and overall quality are important variables that affect how
against constrains of scope, schedule, and budget.” we will achieve our goal.
Five keys to successful Release Planning
Release Planning Steps
1. Develop a release goal. 4. Refine the requirements estimates, as needed.

2. Identify the target release date. 5. Identify the team’s velocity.
3. Identify the highest‐priority requirements (minimum viable 6. Finalize the release scope.
product, or MVP) on the product backlog that support the
release goal.
Lacey, Mitch. The Scrum Field Guide: Agile Advice for Your First Year and Beyond. Boston, MA: Pearson Education, 2016, 147. PeopleCert SCRUM Master I - Study Guide
85
Scrum Artifacts
Release Planning - Variables that Affect How to Achieve the Goal
The goal of release planning is to

determine what constitutes the most
valuable next release and what the desired
level of quality is. The constraints of scope,
date, and budget are important variables
that affect how we will achieve our goal.
Fixed-Scope Release versus Fixed-Date Release
FIXED
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013. PeopleCert SCRUM Master I - Study Guide
86
Scrum Artifacts
The Release Strategy
An aspect of the release strategy is to choose an appropriate point to deploy the completed increments of the release.
Note that regardless of the strategy chosen, there is nothing to release until the end of the sprint event when work items
are determined to be completed and accepted.
There are multiple individual strategies and blends of strategies:

87
Scrum Artifacts
The Release Planning Steps
88
Scrum Artifacts
The Release Planning Steps: The Factors Affecting the Length of a Sprint
The expected Customers/ The Scrum

duration of the stakeholders team
project
▪ Availability for ▪ Scrum experience
feedback and ▪ Technical capabilities
guidance ▪ The ability to
▪ Cultural barriers and decompose work
Scrum familiarity
▪ Environmental factors
Lacey, Mitch. The Scrum Field Guide: Agile Advice for Your First Year and Beyond.. Boston, MA: Pearson Education, 2016, 84. 89
Scrum Artifacts
The Factors for Selecting a Sprint Length
Frequency required
Product Risk and Scrum Team Risk
for improvement and Scrum Team Risk Work in Progress
Uncertainty and Uncertainty Work in Progress
feedback cycle and Uncertainty
The more frequent this What is your product’s What’s happening in your Generally, the longer the
improvement and feedback technical and business organization? Is this a busy sprint, then the more work
cycle is, the shorter the environment? Are you period where team items are added to that
sprint length should be. working on changes that are members are in short sprint. Too many work items
technically innovative or supply? Are teams become too much work in
Does the customer require complicated? Are you constantly reforming with progress, which distracts
frequent updates? working on products whose new or outgoing members? the technical team from
Does the technical team feel business requirements and Each team change affects being able to focus and be
disconnected from the value change often? There team productivity, as will be productive.
overall release? is more risk and uncertainty evidenced by the team’s
with more volatile velocity. As with the product
environments. This is best environment volatility, team
managed with short sprint volatility is best managed
lengths. with short sprint lengths.

90
Scrum Artifacts
Release Best Practices: Conditions of Satisfaction (CoS)
Conditions of Satisfaction (CoS)

“The conditions of satisfaction could be considered the “user business rules” and the “Product Owner
objectives”.
These are the additional details that are typically discovered in subsequent conversations.
These conditions operate at three levels:”
Conditions of Satisfaction can be seen as part of acceptance criteria, which are part of a user story.
Lowe, David. Scrum & Kanban in the Real World. “Acceptance Criteria and Conditions of Satisfaction”. Last modified October
26, 2015. Accessed August 13, 2019. https://scrumandkanban.co.uk/acceptance-criteria-and-conditions-of-satisfaction/ PeopleCert SCRUM Master I - Study Guide
91
Scrum Artifacts
The Definition of Done (DoD)
Definition of Done (DoD)

The DoD is:
▪ a list of all the processes, procedures,
and activities that add value, and need
to be completed for a user story to be
considered done.
▪ produced for each product and specifies
the consistency for what must be done
for every user story of that product.
The DoD is:

▪ ever evolving and continually updated
▪ established collaboratively by the entire
Scrum team
▪ focused on non-functional requirements
▪ common for all the User Stories whereas
the Acceptance Criteria is applicable to
specific User Story
The Benefits of the Definition of Done (DoD)

▪ Helps the team bond together
▪ Good for removing ambiguity when communicating with stakeholders
▪ Helps to reduce risk
▪ Helps the team stay focused
92
https://www.visual-paradigm.com/scrum/definition-of-done-vs-acceptance-criteria/#:~:text=Definition%20of%20Done%20(DoD)%20is,software%20is%20working%20as%20expected.
Scrum Artifacts
The Three Levels of the Definition of Done
Goldstein, Ilan. Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips. Boston, MA: Pearson Education, 2014. PeopleCert SCRUM Master I - Study Guide
93
Scrum Artifacts
Technical Debt
Technical Debt
“Technical debt (also referred to as Shipping first-time code is like going into debt. A little debt speeds
design debt or code debt) refers to development so long as it is paid back promptly with a rewrite….
the work that teams prioritize lower,
omit, or do not complete as they The danger occurs when the debt is not repaid. Every minute spent
work towards creating the primary on not-quite-right code counts as interest on that debt. Entire
deliverables associated with the engineering organizations can be brought to a stand-still under the
project’s product. Technical debt debt load of an unconsolidated implementation…
accrues and must be paid in the (Cunningham 1992)
future.”
Letouzey, Jean-Louis and Declan Whelan. “Introduction to the Technical Deb Concept”. Agile Alliance. May 2016. Accessed August 12, 2019.
https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf
SCRUMstudy.com. “Technical Debt”. Last modified: November 18, 2013. Accessed: October 13, 2019. http://blog.scrumstudy.com/technical-debt/
94
Scrum Artifacts
The Causes of Technical Debt
Consequences of Technical Debt

▪ An unpredictable tipping point
▪ An increased time to delivery
▪ A significant number of defects
▪ Rising development and support costs
▪ Product atrophy
▪ Decreased predictability
▪ Underperformance
▪ Universal frustration
▪ Decreased customer satisfaction
95
Scrum Artifacts
The Definition of Ready (DoR)
Definition of Ready (DoR) Suggested Rules for Definition of Ready

“The definition of ready (DoR) 1. The story is defined and written.
is a checklist to assert that a 2. The acceptance criteria and conditions of satisfaction have been fully
PBI in the product backlog is identified for the story.
ready for the sprint planning 3. The story is traceable to source documents (where appropriate).
event. ” 4. The user interface experience is included (where appropriate).
5. The performance criteria is identified (where appropriate).
6. The team has a good idea about how to demo the user story.
7. The story has been estimated and is under a certain size. For
example, often the maximum story size allowed is half of the team’s
velocity.
8. All external dependencies have been resolved, whether the
dependency was on another team or on an outside vendor.
A strong definition of ready will substantially improve the Scrum

team’s chance of successfully meeting its sprint goal.
Care must be taken not to make this DoR bureaucratic and a stage-
gate that stops stop work from happening.
The DoR benefits the development team by allowing them to "push

back" on accepting poorly defined PBIs to be worked on during the
sprint.
Cohn, Mike. Mountain Goat Software. “The Dangers of a Definition of Ready” Last modified: August 9, 2016. Accessed: October 31, 2019.
https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013. 96
Scrum Artifacts
Velocity
To reiterate, velocity is a metric for how much planned work gets done. The word
“planned” is added in the definition because in Agile and Scrum, one doesn’t revise
Velocity
estimates during the sprint work cycle. Revising estimates after work has started,
causes too much overhead and a waste of time. When done, work effort is credited as
“At the end of each iteration,
the planned amount upon start.
the team adds up their effort
estimates associated with
Velocity is a key concept and driving factor for success in Scrum estimating and
user stories that were
planning. It’s simple, easy to understand, and easy to use. Velocity is specific to each
completed during that
development team as it is a measure for how much of their planned work they get done.
iteration. Velocity is a metric
Thus, velocity is not used to compare one team or project (release) to another. It is
for how much planned work
simply used to measure how well each development team is working and how well the
gets done.”
project (release) is progressing. What counts is that the velocity is steady or increasing.
A critical aspect to using velocity is knowing how to credit “work done” to calculate velocity.
97
Scrum Artifacts
Capacity
Capacity
“The team’s capacity is the

number of available hours they
have to work in a sprint. It can
be thought of as their budget
for the sprint. Limiting the
amount of work per sprint to the
team’s capacity creates a
sustainable pace.”
How to Calculate Capacity
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013, 341.
98
Module #8
Iteration Level Planning
Learning Objectives
▪ List the key steps involved in a Scrum cycle.

▪ Identify the five events that are part of the larger sprint in Scrum.
▪ Describe the overall purpose, process steps, and roles of the Scrum team involved in the following Scrum events:
▪ Sprint planning
▪ Sprint execution
▪ The daily Scrum
▪ The sprint review
▪ The sprint retrospective
▪ Explain the process steps involved in the daily Scrum event in Scrum including a description of the timing.
▪ Identify the attributes of an effective daily Scrum meeting.
▪ Define the "artifact" product increment.
▪ Identify the attributes of a potentially shippable product increment, and describe its purpose in Scrum.
▪ Describe the most likely outcome for the Scrum if the Scrum team fails to include any single event.
99
The Scrum Practices
Master
Adapted from Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013, 14. PeopleCert SCRUM Master I - Study Guide
100
Timeboxing
Timeboxing is a time management technique where an activity is allocated a fixed

period of time. The six main sprint activities are timeboxed for the reasons of focus and
productivity in getting the work done, as well as establishing a regular cycle for being
agile and adaptive. The critical rule for timeboxed work is that work stops at the end of
the time box, followed by a review of progress.
Coaching the Scrum team and organization to keep activities in strict timeboxes and maintaining Scrum events is one
of the major responsibilities of the Scrum Master role. The main benefit for timeboxing is productivity – teams can
focus better and work faster when they have regular routines and a regular cadence for these routines. A quote from
Mike Cohn states the benefits of timeboxing: “Teams benefit greatly from having a rhythm to their projects. Any
regular iteration length can provide this rhythm.”
There is also one critical error to be aware of that is often

associated with timeboxing – that of expecting all Development Work
development work to be completed in the timebox. This is The work required to create
not an Agile or Scrum principle! The end of a timebox is a
a releasable increment of
time to collect feedback, review, learn, improve, and adapt
product every sprint.
before beginning the next cycle. In this next cycle, if
priorities and goals remain consistent, then unfinished work
from the last timebox is continued in the next timebox.
Cohn, Mike. Mountain Goat Software. “Selecting the Right Iteration Length”. Last modified March 4, 2006. Accessed August 13,
2019. https://www.mountaingoatsoftware.com/articles/selecting-the-right-iteration-length PeopleCert SCRUM Master I - Study Guide
101
The Sprint Contains and Consists of the Following Time-Boxed Events
Accessed February 13, 2021. https://www.thescrummaster.co.uk/scrum/the-five-scrum-events/ PeopleCert SCRUM Master I - Study Guide
102
Work Not Completed
For work not completed, it goes back into the release backlog for the next
sprint planning event (which is typically the next business day).
Due to its previous priority, it will more than likely be picked up again for the
next sprint.
When we bring it into the sprint, the technical team will estimate the effort left
to complete the story (which is necessary to determine how many stories can
fit in the sprint). However, the story will retain its original effort estimate. When
it is completed according to the definition of done (DoD), it is credited with the
full and prior estimate.

103
Sprint Events
All events in the Sprint are:
▪ time-boxed, including the

sprint itself
▪ a formal opportunity to inspect

and adapt.
▪ specifically designed to enable

critical transparency and
inspection

104
The Sprint Backlog
Sprint Backlog
“The sprint backlog is
the set of product
backlog items selected
for the sprint, plus a
plan for delivering the
product increment and
realizing the sprint
goal.”
The Sprint Backlog is a plan with enough detail

that changes in progress can be understood in the
Daily Scrum. The Development Team modifies the
Sprint Backlog throughout the Sprint, and the
Sprint Backlog emerges during the Sprint. This
emergence occurs as the Development Team
works through the plan and learns more about the
work needed to achieve the Sprint Goal.
The sprint backlog makes visible all the work that
the development team identifies as necessary to
meet the sprint goal and provides a real-time
picture of the work that the development team
plans to accomplish during the sprint.
Agile Alliance. ”Agile Glossary”. Last modified: 2011. Accessed: October 30, 2019. https://www.agilealliance.org/agile101/agile-glossary/]
Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum: The Rules of the Game. ScrumAlliance, 2017. PeopleCert SCRUM Master I - Study
Guide 105
The Sprint Backlog
Only the development team can

change its sprint backlog during a
sprint.
The development team modifies the

sprint backlog throughout the sprint,
and the sprint backlog emerges during
the sprint.
The sprint backlog is a highly visible,

real-time picture of the work that the
development team plans to
accomplish during the sprint, and it
belongs solely to the development
team.
The Evolution of a Product Backlog Item
The development team determines how to achieve the sprint goal and develops the
actual sprint backlog of supporting tasks.
As new work is required, the development team adds it to the sprint backlog. As
work is performed or completed, the estimated remaining work is updated. When
elements of the plan are deemed unnecessary, they are removed.
As new work is required the development team adds it https://www.coursehero.com/file/p6unj35u/As-new-work-is-required-the-Development-Team-adds-it-to-the-Sprint-Backlog-As/

107
Sprint Backlog Information
A sprint backlog might contain the following information:

108
Sprint Planning
The sprint planning meeting is

conducted at the beginning of a
sprint as part of the sprint
backlog creation process, and is
divided into two parts – objective
definition and task estimation.
The Product Owner and Scrum

team (with facilitation from the
Scrum Master) review the
product backlog, discuss the
goals and context for the items,
and the Scrum team selects the
items from the product backlog to
commit to complete by the end of
the sprint. The list of tasks is
recorded in a document called
the sprint backlog.
109
Sprint Planning
Master
(2-week sprint)

110
Sprint Planning Has Two Parts
Sprint Planning answers the following questions:

• What can be delivered in the increment resulting from the upcoming
sprint?
• How will the team achieve the work needed to deliver the increment?
111
The Product Owner’s Role in Sprint Planning
▪ Make sure the product backlog is well groomed – its items prioritized and its high-priority items
detailed.
▪ Help the team understand what must be done – describe what they want to see built for the next
sprint.
▪ Clarify requirements and answer questions.
Do not tell the team how much work should be pulled into the sprint, or
identify tasks on behalf of the team.

112
What Is the Sprint Goal?
Sprint Goal
“The sprint goal is a high-level summary
of an objective set for the sprint that
can be met through the implementation
of the product backlog.”
It provides guidance to the development team on

why it is building the increment.
Completing all items in the sprint backlog is always a development team goal, but there are quite often additional goals to be
accomplished. Such additional goals might include:
▪ Completing a theme and being able to deploy to the customer
▪ Trying and learning new development technology or techniques
As the development team works, it keeps the sprint goal in mind
as well as simply completing user stories.
113
The Approaches to Sprint Planning – Two-Part Sprint Planning
Part 1 (“What”) Part 2 (“How”)
Determine the
capacity
Forecast Acquire YES YES

product confidence Can we At Finalize the
backlog items the forecast is commit? capacity? commitment
to fill capacity reasonable
NO
NO
Refine the Adjust the

sprint goal forecast

Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson 114
Education, 2013, 339.
The Approaches to Sprint Planning – One-Part Sprint Planning

Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular 115
Agile Process. Boston, MA: Pearson Education, 2013, 340.
Sprint Execution
The sprint execution is the

work the Scrum team
performs to meet the sprint
goal. It begins after the sprint
planning and ends when the
sprint review starts.
116
Sprint Execution
Inputs: Participants:
§ The Sprint backlog
Master
ScrumMaster
§ The Sprint goal Standard
Workday
Sustainable Development Team
Outputs: Pace
§ A potentially
shippable product
increment Time-Box

117
The Sprint Execution Process
Adapted from Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013. 348. PeopleCert SCRUM Master I - Study Guide
118
Daily Scrum
The daily Scrum meeting is a

critical Scrum practice within
the sprint execution. This
meeting is a 15-minute long,
time-boxed activity for daily
planning that is focused
around the three pillars of
Scrum: transparency,
inspection, and adaptation. It
optimizes team collaboration
and performance. During this
time, the development team
plans work for the next 24
hours and inspects progress
toward the sprint goal.
Everyone on the team
attends. At this meeting, the
information needed to
inspect progress is
presented. This information
may result in re-planning and
further discussions
immediately after the daily
Scrum.
119
Daily Scrum
Master
First ask the MAIN 3 questions:

1. What did we accomplish yesterday?
2. What will we accomplish today?
3. What obstacles do we need to remove?
Then ask a NEW fourth question:
The Scrum Master is responsible for clearing 4. What is my confidence, on a scale of
any roadblocks for the development team so
they can focus on delivering the work one to ten, that the team will
identified in the sprint planning.
accomplish the goal of this sprint?
Lacey, Mitch. The Scrum Field Guide: Agile Advice for Your First Year and Beyond. Boston, MA: Pearson Education, 2016. PeopleCert SCRUM Master I - Study Guide
120
The Rules of Daily Scrum
All team members are required to attend (online or physically).
The meeting should be held in the same place at the same time.
The Scrum Master teaches the development team to keep the daily Scrum within the 15-
minute time-box.
Any impediments raised during the meeting are recorded and the team moves on.
Anyone with the knowledge or skills to discuss potential solutions to the impediments
waits until after the meeting, “taking it offline”.
The Benefits of Daily Scrum
• Improves communications
• Eliminates other meetings
• Identifies impediments to development for removal
• Highlights and promotes quick decision-making
• Improves the development team’s level of knowledge
• Optimizes team collaboration and performance by inspecting the work since the last
daily Scrum and forecasts upcoming sprint work
• Optimizes the probability that the development team will meet the sprint goal
Sutherland, Jeff. Jeff Sutherland’s Scrum Handbook. Scrum Training Institute, 2010 121
The Sprint Review
After the sprint ends, there is

the sprint review, where the
Scrum team and
stakeholders inspect what
was done during the sprint,
discuss it, and figure out
what to do next. Present at
this meeting are the Product
Owner, team members, and
Scrum Master, plus
customers, stakeholders,
experts, executives, and
anyone else interested.
122
The Sprint Review
Master
(2-week sprint)
“This meeting at the end of each and every sprint ensures that the
stakeholders have a fantastic forum for delivering feedback directly to
the Product Owner, with the development team listening in.”
Marc C. Layton
Scrum for Dummies
Layton, Marc C. Scrum for Dummies. New Jersey: John Wiley & Sons, 2015. PeopleCert SCRUM Master I - Study Guide
123
The Inputs and Outputs of the Sprint Review
The Benefits of the Sprint Review

The sprint review is a critical inspect-and-adapt activity and helps the team:
▪ Build and maintain trust with the stakeholders and customers
▪ Make project course corrections in near-real time
▪ Identify risks and issues
▪ Gather feedback
Lacey, Mitch. The Scrum Field Guide: Agile Advice for Your First Year and Beyond. Boston, MA: Pearson Education, 2016. PeopleCert SCRUM Master I - Study Guide
124
The Sprint Review Steps
The following steps outline the flow, content, and roles involved in the sprint review:
1) Convene and lead the review:

• The Scrum Master will convene the meeting as the coach for Scrum.
• The Product Owner will lead the meeting.
• The development team will prepare for and demo the completed PBIs.
• Other relevant stakeholders will attend, including the customer and project sponsor.
2) Review the sprint backlog:

• The Product Owner explains what PBIs have been “done” and will be demonstrated, as well as which ones are not
completed and which ones are not demonstrable (such as bug fixes or code refactoring).
• The Product Owner and development team discuss achievements toward the sprint goal.
3) The development team demonstrates completed PBIs:

• The team demonstrates completed PBIs and asks for feedback of what went well during the sprint, what problems it ran
into, and how those problems were solved.
4) Review the release and product backlog:

• The Product Owner discusses the updated release and product backlogs, as well as discuss likely completion dates,
timelines, budgets, and other project issues.
5) Collaborate on what should be done next:

• This is a critical ending conversation for all roles
present at sprint review
• This becomes a critical conversation for input to the
next day’s sprint planning meeting.
• This is also a last chance to be adaptive before the
next sprint begins, where all key stakeholders are in
the same room at the same time.

125
The Scrum Team’s Role in the Sprint Review
The Product Owner The Development Team The Scrum Team

discusses the product backlog as it discusses what went well during the The entire group collaborates on what
stands. He or she projects likely sprint, what problems it ran into, to do next, so that the sprint review
target and delivery dates based on and how those problems were provides valuable input to subsequent
progress to date (if needed). solved. sprint planning.
The Product Owner explains what The development team A review of how the marketplace or
product backlog items have been demonstrates the work that it has potential use of the product might have
“done” and what has not been “done” and answers questions changed what is the most valuable
“done”. about the increment. thing to do next.
A review of the timeline, budget,

potential capabilities, and marketplace
for the next anticipated releases of a
functionality or capability of the product.
The Scrum Master acts as a facilitator and ensures that the
event takes place and that attendees understand its purpose.
The Scrum Master teaches everyone involved to keep it within
the time-box.
126
A Potentially Shippable Product Increment
Potentially
Shippable Product
Increment
“Results that are completed to a

high degree of confidence and
represent work of good quality
that is potentially shippable to end
customers at the end of a sprint.”
Release backlog PBIs that are completed

with a status of “done” are described as
increments of the release.
Increments are the output of the sprint

review event where the PBI is presented to
all stakeholders, accepted, and meets all the
definition of done criteria. These increments
are potentially shippable/deployable.
“The perfection vision of Scrum is that the product

is potentially shippable at the end of each sprint.”
- Jeff Sutherland
127
The Sprint Retrospective
The sprint retrospective

is the last event of the
sprint. As with all other
main sprint events, it is
timeboxed, where the
length is determined by
the sprint duration (see
the sprint description).
It is a review meeting
for the entire Scrum
team.
Retrospective means
to look back, reflect,
and learn to improve
moving forward. The
The sprint retrospective is retrospective should be
an opportunity for the conducted as a
Scrum team to discuss brainstorming activity,
and the Scrum Master
what’s working and what’s should encourage all
not working, and agree on team members to
changes to try and speak and contribute.
improve.
Further reading on this subject: Cohn, Mike. Mountain Goat Software. “Sprint Retrospective”. Accessed: October PeopleCert SCRUM Master I - Study Guide
30, 2019. https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-retrospective 128
The Sprint Retrospective
Master
(2-week sprint)
The retrospective should be conducted as a brainstorming activity, and the Scrum Master should encourage all team
members to speak and contribute. We ask three basic questions that are centered around four basic performance
elements, as follows:
Regarding (1) people and relationships, (2) Scrum processes and techniques, (3) supporting Scrum tools, and (4) the
definition of done (quality):
What is working and we won’t change?

What is not working and we want to stop or change?
What is new or innovative that we can be doing?

129
The Inputs and Outputs of the Sprint Retrospective
Issues that could impede the success of a sprint retrospective:

• A poor facilitator
• Not doing the retrospective
• Development Team not fully contributing with transparency

130
The Scrum Team’s Role in the Sprint Retrospective
The Scrum Master The Scrum Team

▪ Ensures that the meeting is positive and The entire group collaborates on ways
productive to increase product quality by
▪ Teaches all to keep it within the time-box improving work processes, or adapting
▪ Participates as a peer team member in the the definition of “done”, and identifying
meeting improvements that will be implemented
▪ Encourages the Scrum team to improve within in the next sprint.
the Scrum process framework, its development
process, and practices to make it more
effective and enjoyable for the next sprint.
131
Inspect and Adapt
The failure to include any of the

sprint events is a failure to take full
advantage of the opportunity to
inspect and adapt, which results in
reduced transparency.
132
Module #9
Staying in Control with
Information Radiators
Learning Objectives
▪ Define the term "information radiator" as related to a sprint.

▪ Describe the purpose of visual management tools in relation to Scrum and identify attributes of effective visual
management tools, including kanban and task boards, and explain the benefits of each.
▪ Define the terms "development work", "timeboxing", "velocity", "visual management", and "information radiator"
as related to a sprint (in Scrum).
▪ Define "burndown chart and "burnup chart" and explain the purpose of each.
133
Staying in Control with Information Radiators
Information Radiators
Scrum Board (Task Board)
What Is an Information Radiator?

A visual display presents up-to-date,
sufficiently detailed, and important
information to a passersby in an easy,
self-interpretable format.
Information Radiators can be both
physical or digital.
Most teams use a combination of a Scrum board (task

board) and a burn-down and/or burn-up chart as their
principal information radiators.
Sprint Burndown Chart
Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013. PeopleCert SCRUM Master I - Study Guide 134
The Types of Information Radiators
The Product and Release Backlog Must Be Visible and Transparent
All backlogs are meant

to be published and
visible to all.

The Release Burn-down Chart
A graphical, real-time picture of what work is remaining in the

release and allows easy visualization of whether the release The Difference between a Burn-Down
is on track to finish on time and in scope. and Burn-Up Chart
A burn-down chart shows how much work

is remaining to be done in the project,
whereas a burn-up shows how much work
has been completed, as well as the total
amount of work.
136
Lacey, Mitch. The Scrum Field Guide: Agile Advice for Your First Year and Beyond. Boston, MA: Pearson Education, 2016, 431.
The Scrum Board
Scrum Board (Task Board, Kanban Board, Sprint Wall, or Sprint Backlog Wall)
Method:
1. Written sticky notes or index cards are placed in
the first two columns for the PBI user stories and
their tasks.
2. The development team collaborates on which PBI

and tasks to work on and moves them to the “In
Progress” column
Note: Agile principles prefer the team working

together on tasks rather than assigning one
task to one person.
3. As the “team” completes each task, they move it

to the “done” column and select another until
eventually the entire PBI is done per the definition
of done.

137
The Sprint Burn-down Chart
A graphical, real-time picture of what work is remaining in the

sprint. Difference between a Burn-Down
and Burn-Up Chart
These charts communicate how much work is remaining and
how task completion is trending throughout the sprint. A burn-down chart shows how much work
y axis – number of hours/points remaining is remaining to be done in the project,
whereas a burn-up shows how much work
x axis – number of days in the sprint remaining has been completed, as well as the total
amount of work.
Can easily visualize whether the team is on track to complete
all the work remaining
138
Lacey, Mitch. The Scrum Field Guide: Agile Advice for Your First Year and Beyond. Boston, MA: Pearson Education, 2016, 431.
Module #10
Scrum Rules
Learning Objectives
▪ List the 13 Scrum rules
139
Scrum Rules
Scrum Rules
1. Every sprint is of the same duration; usually two weeks.

2. There are no breaks between sprints.
3. Every sprint has time set aside for Scrum events, time-boxed as follows for the typical two-week sprint:
Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum: The Rules of the 140
Game. ScrumAlliance, 2017. Accessed August 12, 2019. https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide
Scrum Rules
Scrum Rules and Canceling a Sprint
4. The goal is to produce a potentially shippable product increment by the end of every sprint.
5. Once the sprint has started, no change is permitted that would affect the sprint goal – except for the decision to cancel it.
6. Product backlog items are sized by the team who will implement them.
7. The daily Scrum occurs every day in the same place at the same time, unless it clashes with another critical Scrum event.
8. At the daily Scrum, team members discuss only what they have progressed with and what is blocking progress.
9. All stakeholders are invited to attend the sprint review.
10. A Scrum team includes only the Product Owner, Scrum Master, and delivery team members.
11. A delivery team has between three and nine people.
12. Team membership cannot be changed during the sprint.
13. The Scrum Master is responsible for ensuring that everyone follows the rules of Scrum related to a project.
It is very unusual for a sprint to be canceled. A sprint may be canceled – at

the discretion of the Product Owner if the sprint goal has become obsolete.
This is a decision based on serious and pressing product, customer, and
business reasons.
When a sprint is cancelled, it should be identified as an “abnormal

termination” and not be used for velocity calculations.
All completed work should be reviewed and, if reusable, accepted. Anything

left undone is moved back onto the product backlog or discarded.
The sprint should end immediately and all items that are completed as per
the definition of done should be reviewed.
Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum: The Rules of the 141
Game. ScrumAlliance, 2017. Accessed August 12, 2019. https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide
Module #11
Introduction to Scaled
Scrum
Learning Objectives
▪ Describe the purpose of Scaling Scrum

▪ List the roles in Scaling Scrum
▪ Describe the Scaled Artifacts and Events
142
Scaling Scrum
What Does “Scaling Up” Mean?
The purpose of
Team scaling Scrum is to
Location
The Scrum move from a single team and
Framework Team small product combination to
Location a combination of one or more
Product
teams and/or a medium or
large product combination.
Product
Team Team The goal is to ensure the

Location Location
synchronization and
consistent behavior between
Product Product all the roles and their
activities, as well as ensure
the consistent application of
the Scrum events, artifacts,
and rules between the teams.

143
Roles in Scaling Scrum
Scaled Product Owner Roles
Flat Scaled Approach Hierarchical Scaled Approach
Chief Product Owner Chief Product Owner
Product Line Owner Product Line Owner

Team A Team B Team C
Team A Team B Team C Team D

The Chief Product Owner - Responsibilities
Communication Product vision and Budgeting of Coordinates

with key strategy requirements product
stakeholders and development on a
product sponsors high level
Coordinates split of Business themes, Integrated product

Definition of MVPs requirements into features and and the overall
system’s parts and sometimes for epics release
into other related definition
products
Coordinate and Attending and

collaborate with observing separate
lower-level Product team meetings
Owners
Scrum Desk. “Chief Product Owner Role”. Accessed Jan 23, 2020. https://www.scrumdesk.com/start/manual-for-
scrumdesk-start/chief-product-owner-role/
Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2013.
Scaled Product Owner and Scrum Master Roles
Flat Scaled Approach Hierarchical Scaled Approach

Chief Scrum Master Chief Scrum Master
Chief Product Owner Chief Product Owner
Product Line Owner Product Line Owner

Team A Team B Team C
Team A Team B Team C Team D

The Chief Scrum Master - Responsibilities
Cohesive Coordinate and Coordinate and Ensure the

performance of all collaborate with collaborate with synchronization
roles involved in all product level lower Scrum Master and consistent
the release roles roles behavior between
all the roles
Ensure the Attending and Coordinate Facilitate the

consistent observing multiple Scrum Scrum of Scrums
application of the
Scrum events, separate team teams to work in (SoS) meeting
artifacts, and rules meetings parallel
Addressing
impediments that
impact more than
one Scrum team

SCRUMstudy.” Role of a Chief Scrum Master”. Last modified May 3, 2017. Accessed February 27, 2020. 147
http://blog.scrumstudy.com/role-of-a-chief-scrum-master
Integration Development Team Role
Flat Scaled Approach

Chief Scrum Master Dedicated integration
development teams are
appropriate on large
Chief Product Owner
projects with ten or more
teams.
Team C
Team A
Integration
Team
Team B

The Scaled Product Backlog

149
Why Should Multiple Teams Share the Same Definition of Done?
Ensure code Understand how

is ready to be much work is
Minimize
deployed to needed to truly
last-minute
production at complete a story
delays
any time
Schwendler, Tom. “The Importance of Sharing the Same ‘Definition of Done’ with Your Software Development Partner”.
Ascendle. Last modified August 21, 2019. Accessed March 2, 2020.
https://www.ascendle.com/insight/blog/the-importance-of-sharing-the-same-definition-of-done-with-your-software- PeopleCert SCRUM Master I - Study Guide 150
development-partner/.
Suggested Reading
Suggested Reading
▪ Goldstein, Ilan. Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, &
Tips. Boston, MA: Pearson Education, 2014
▪ Lacey, Mitch. The Scrum Field Guide: Agile Advice for Your First Year and
Beyond. Boston, MA: Pearson Education, 2016.
▪ Layton, Mark C. Scrum for Dummies. New Jersey: John Wiley & Sons, 2015.
▪ Morris, David. Scrum in Easy Steps – an ideal framework for agile projects. UK: In
Easy Steps Limited, 2017.
▪ Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile
Process. Boston, MA: Pearson Education, 2013.
▪ Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to
Scrum: The Rules of the Game. ScrumAlliance:
2017. https://www.scrumalliance.org/learn-about-scrum/the-scrum-guide
For a complete bibliography,
see the course syllabus.

151

PeopleCert Scrum Master I (Study Guide)

Uploaded by

Copyright:

Available Formats

You might also like

PeopleCert Scrum Master I (Study Guide)

Uploaded by

Document Information

Original Description:

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

PeopleCert Scrum Master I (Study Guide)

Uploaded by

Copyright:

Available Formats

PeopleCert SCRUM Master I

Copyright © 2021 PeopleCert International Ltd.

✓ Web & Paper based exams in 25 languages

70% pass mark (28/40)

The PeopleCert Scrum Master I examination will consists

1 - Introduction to Agile Projection Management (5%)

2 - Scrum as an Agile Framework (2.5%)

3 - The Scrum Framework & Team (25%)

4 - Scrum Artifacts (25%)

5 - Scrum Planning (12.5%)

6 - Scrum Events (25%)

7 - Information Radiators (2.5%)

8 - Scaled Scrum (2.5%)

Module #1: An Introduction to Agile Project Management 7

Module #2: An Introduction to Scrum as an Agile Framework 18

Module #3: An Introduction to the Scrum Framework 21

Module #4: Scrum Roles 28

Module #5: Multilevel Planning 48

PeopleCert SCRUM Master I - Study Guide

Module #6: Preparing the Product (Planning Level) 51

Module #7: Scrum Artifacts 83

Module #8: Iteration Level Planning 99

Module #9: Staying in Control with Information Radiators 133

Module #10: Scrum Rules 139

Module #11: Introduction to Scaled Scrum 142

PeopleCert SCRUM Master I - Study Guide

PeopleCert SCRUM Master I - Study Guide

The Agile Manifesto – The Twelve Principles

Key factors in the success of

PeopleCert SCRUM Master I - Study Guide

Traditional development models and organizational structures follow

PeopleCert SCRUM Master I - Study Guide

• Written documents have their limitations

• Too much work and no fun

Disadvantages of Traditional Waterfall Development

This chart provides a

▪ Explain how Scrum has been used extensively worldwide.

PeopleCert SCRUM Master I - Study Guide

The successful use of Scrum depends on people becoming

▪ Research and identify viable ▪ Scrum offers a team-based approach to

▪ Sustain and renew products. ▪ Supports a rapid response to changing

PeopleCert SCRUM Master I - Study Guide

The Scrum framework is based on the principle

PeopleCert SCRUM Master I - Study Guide

Adaptation is about being flexible;

A prime example of adaptation occurs

Adaptation and Scrum are friendly

Transparency means that everything is

Strategies, goals, and objectives are

A prime example of this transparency is

Empirical Process Control

Work needs to be transparent and

Decisions and functions are fact-

Inspection refers to “review and

Actual results and the progress towards

Inspection needs to be balanced and

A prime example of inspection occurs at

“Scrum artifacts provide key