ASE Course Supplement 2.2.1 August 2022

Celebrating over 40 Years
of Training Excellence
Agile Scrum EssentialsTM
Course Supplement
Course Supplement
Course Supplement
Agile Scrum Essentials – Course Supplement 2
Table of Contents
How to Use This Document........................................................................................................ 4

Introduction to Agile Project Management .................................................................................. 5
The Agile Manifesto ................................................................................................................ 5
The Three Characteristics of Value ........................................................................................ 8
Agile versus Predictive Development ..................................................................................... 9
An Introduction to Scrum ...........................................................................................................10
The Key Benefits of Scrum ....................................................................................................10
The Three Pillars of Scrum ....................................................................................................10
The Five Scrum Values .........................................................................................................12
The Scrum Framework ..........................................................................................................12
The Scrum Team ......................................................................................................................13
The Scrum Team ...................................................................................................................13
The T-Shaped Professional ...................................................................................................13
The Developers, Product Owner, and Scrum Master .............................................................14
Other Responsibilities of the Scrum Master ...........................................................................14
Agile Work Environments ......................................................................................................15
Scrum Artifacts..........................................................................................................................15
The Product Backlog .............................................................................................................15
Product Backlog Items and Labels ........................................................................................15
Acceptance Criteria ...............................................................................................................16
Product Backlog Refinement .................................................................................................16
Sizing Techniques .................................................................................................................17
The Fibonacci Sequence .......................................................................................................17
Planning Poker® ....................................................................................................................17
Sizing with Triangulation ........................................................................................................18
The Sprint Backlog ................................................................................................................18
The Increment .......................................................................................................................19
Scrum Events ...........................................................................................................................19
Product Planning before the Sprints ......................................................................................19
The Sprint..............................................................................................................................20
Timeboxing ............................................................................................................................20
Sprint Planning ......................................................................................................................21
©Pink Elephant, 2022 unless otherwise stated.

Calculating Capacity ..............................................................................................................21

Velocity..................................................................................................................................22
Sprint Planning Addresses Three Topics ...............................................................................22
Sprint Execution ....................................................................................................................23
Task Planning and Flow Management ...................................................................................23
The Scrum Board ..................................................................................................................24
The Sprint Burn-Down Chart .................................................................................................24
The Expanded Scrum Board .................................................................................................25
The Daily Scrum ....................................................................................................................25
Sprint Review ........................................................................................................................26
The Sprint Retrospective .......................................................................................................27
Improvement Stories .............................................................................................................27
Improvement Board ...............................................................................................................28
Releasing the Increment ...........................................................................................................28
Release Planning ..................................................................................................................28
Fixed-Scope Release versus Fixed-Date Release .................................................................28
The Release Backlog ............................................................................................................28
All rights reserved. No patent liability is assumed with respect to the use of the information contained herein. While
every precaution has been taken in the preparation of this publication, the copyright holder cannot be held liable for
damages caused by use of the information contained herein.
The contents of this workshop are protected by copyright and can be reproduced under Pink Elephant’s Terms of Use
only.
5575 North Service Road, Suite 200, Burlington, Ontario L7L 6M1, Canada
Telephone: 1-905-331-5060
Fax: 1-905-331-5070
Agile Scrum Essentials™ certification is governed by Professional Designations. All rights reserved.
ASE Course Supplement 2.2.1 August 2022

How to Use This Document

This document is your Course Supplement. It contains detailed information to supplement key
areas that are examinable related to the Agile Scrum Essentials course.
The information contained here is designed to supplement the course presentation by providing
examples and additional details where needed. It follows the flow of the presentation but does
not cover all content presented in the course.
This document is designed to enhance your understanding of the presentation content and
better prepare you for your exam.

Introduction to Agile Project Management

“Agile is a project management style focused on the early delivery of business value,
continuous improvement, scope flexibility, team input, and delivering well-tested products that
reflect customer needs.”1
The Merriam-Webster dictionary definition of agile emphasizes the following two aspects of
what being agile is about:
▪ Having an agile mindset to be quick, resourceful, and adaptable in character
▪ Being physically ready and able to move with speed and grace
The Agile Alliance defines agile in a business sense “as the ability to create and respond to
change [to succeed] in an uncertain and turbulent environment.”2
The Agile Manifesto

The Agile Manifesto states that it helps in
“uncovering better ways of developing software
by doing it and helping others do it.” The Agile
Manifesto includes the four values indicated in
the diagram on the left.3
Agile principles emphasize building working
software that people can actively use instead of
spending a lot of time writing specifications
beforehand. In addition, Agile development
focuses on cross-functional teams that are
Beck, Kent et al. “Manifesto for Agile Software empowered to make decisions as opposed to
Development”. big hierarchies and compartmentalization by
function.
Agile development also emphasizes rapid iteration with continuous customer inputs. Often,
when people learn about Agile development or Scrum, they seem to recognize it as a hands-on
style used by start-ups4.
1 Layton, Mark C. and Steven J. Ostermiller. Agile Project Management for Dummies, 2nd Edition. Hoboken, NJ: John Wiley & Sons,
2017.
2 Agile Alliance. “Agile 101.” Agile Alliance, 2011. https://www.agilealliance.org/agile101/
3 Beck, Kent et al. ”Manifesto for Agile Software Development.” Accessed April 23, 2021. http://agilemanifesto.org/
4 Sutherland, Jeff. Jeff Sutherland’s Scrum Handbook. Scrum Training Institute, 2010.

The Manifesto for Agile Software Development5 is based on the twelve principles below:
According to the first principle, customer satisfaction is achieved

through:
Customer ▪ The early delivery of products to customers for testing and

satisfaction by the feedback
early and ▪ Continuous delivery to let customers know the progress
1. continuous ▪ The delivery of values to customers by fulfilling high-
delivery of valuable priority requirements first
software
The output of each iteration is a working code that can be used
to evaluate and respond to changing and evolving user
requirements.
This principle emphasizes the responsiveness to change as
opposed to a tight alignment to approved plans. The change
Welcome changing control process is simplified, and no formal documentation or
requirements, even approval is required. This principle helps customers gain a
2. late in competitive advantage, because it encourages a quick response
development. to the latest changes in the external environment and improves
customers’ chances of taking advantage of emerging
opportunities.
This principle is about providing immediate value to customers
by delivering working features. Each iteration (or sprint in
Deliver working
Scrum) results in a fully working increment that is releasable, if
software frequently
required. The teams make sure that each feature is fully
3. (weeks rather than
developed, tested, and accepted by the product owner before
months).
considering it as completed. The project team activities can be
structured better with a fixed timebox to focus on the delivery of
value.
Agile development principles also include keeping requirements
Close, daily
and documentation minimal, as well as acknowledging that
cooperation
changes are normal, acceptable realities in software
between
4. businesspeople
development. This principle makes close collaboration
particularly important to clarify requirements regularly and to
and developers
keep team members in agreement and aligned with the
business throughout the development.
According to this principle, projects are executed successfully
around motivated individuals who are given the environment
Projects are built and support they need and are trusted to get the job done.
around motivated Team members choose the jobs in which they are most
5. individuals who interested and competent in through self-organization and not
should be trusted. through the influence of external management.
Micromanagement and a top-down management approach are
avoided.
5 Beck, Kent et al. ”Manifesto for Agile Software Development.” Accessed April 23, 2021. http://agilemanifesto.org/

Face-to-face This principle states that it is best to obtain direct feedback by

conversation is the going to the source of the problem or confusion and to use oral
6. best form of communication at the workplace for allowing osmotic
communication. communication. Virtual team conversations can be facilitated via
video conferencing.
Agile measurement of progress is based on the completion of
Working software
work. It is an all or nothing approach that recognizes that
is the primary
anything not finished has no value and should not be counted
7. measure of
as progress, even if it is at 99% complete. For management and
progress.
reporting purposes, we trend and forecast development work
based on 100% completed working software only.
Agile methodologies seek a work-life balance among team
Sustainable members and promote satisfaction by avoiding burnout or
development, able exhaustion. Through close collaboration and by being alert and
8. to maintain a creative, these practices help employees avoid long nights and
constant pace weekends, while ensuring development maintains a constant
pace.
The best architectures, requirements, and designs emerge from
Continuous self-organizing teams. At regular intervals, such teams reflect on
attention to how to become more effective, then tune and adjust their
9. technical behavior and work practices accordingly. For example, in
excellence and Scrum, the retrospective event ensures that the lessons learned
good design during the sprint are captured and shared before the start of the
next sprint.
This can be explained by considering the Pareto principle, also
Simplicity, the art
known as the 80/20 rule, which means that typically 80 percent
of maximizing the
of the results may come from only 20 percent of the efforts. It
10. amount of ‘work
prioritizes the essential elements needed to create value for the
not done’, is
project and customer, instead of focusing on distractors that do
essential.
not add value.
The best
Self-organizing teams have the autonomy and commitment to
architectures,
meet the goals of the sprint and to determine ways to
requirements, and
11. designs emerge
accomplish work goals. This basic principle suggests that self-
organizing teams know best how to carry out the work, as
from self-
compared to project managers or human resource departments.
organizing teams.
Being agile means maintaining a degree of flexibility and only
doing what is necessary to be successful. There are always
Regularly, the team better ways of accomplishing work and working together. The
reflects on how to team must meet regularly to honestly discuss current practices,
become more evaluate potential alternatives, and then experiment with
12. effective and alternatives to prove (or disprove) their value and suitability. As
adjusts such, sprint retrospectives are important to review what has
accordingly. been done and what will be done in the next iteration. This will
help the team steadily evolve and adapt to changing business
needs and circumstances.

The Three Characteristics of Value

The business objectives of becoming more agile and
using Agile development practices are ultimately
connected to providing more value to customers as
well as organizations. More value means growing
sales and remaining competitive, as well as
implementing continual improvements and continual
innovations. All organizational activities should link
back, directly or indirectly, to value for itself, its
customers, and other stakeholders. Value is unique to
each customer. A one-size-fits-all approach is seldom
successful in today’s market. The more organizations
address the value needs of their customers, the more
they can grow and maintain their business growth. Customer satisfaction is an often-used
measure of the customers’ overall perception of value. Further, value is never static. It is always
changing over time in response to changing customer needs and expectations, as well as
competition. The three main characteristics or dimensions of value are cost, quality, and speed:
▪ Cost is often measured against how much customers are willing to pay. Services need to be
affordable to customers and profitable for the business.
▪ Quality is a combination of enabling customer objectives, as well as meeting customers’
functional and nonfunctional requirements.
▪ Speed is the pace at which organizations deliver quality products and services. It is
important to deliver quality and results to stakeholders without undue delays.
When looking at value using these three dimensions, it is necessary to strike a balance between
them.
Note that a lack of good information technology or IT practices can impact all three dimensions
of value. For example, it can result in increased costs because of rising maintenance
overheads, stagnation of growth, and/or the inability to map costs to value. Poor IT practices
can also lead to reduced quality because of escaped defects, poor service availability, and the
inability to integrate data. In addition, a lack of effective IT practices can eventually reduce the
speed of deliverables, causing a slow speed to market due to a lack of shared priorities and a
wrongly prioritized backlog of work.
Being agile means to shorten the overall development and delivery cycle, decrease costs
associated with development, and increase quality. Ultimately, Agile development practices
deliver on all three dimensions of value – cost, quality, and speed.

Agile versus Predictive Development

Generally, development models can be divided into two popular approaches: adaptive and
predictive. Some organizations manage to adopt a hybrid approach combining both styles.
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.
Adaptive development models are iterative and incremental in their approach to planning,
developing, and delivering. These models use collaboration as a foundation to their success.
These models are seen as circular and repetitive because they break a large deliverable into
smaller, more manageable deliverables, and they also circulate the development through the
repeated activity of requirements, design, development, integration, and testing. Deployment is
a separate phase that follows iterative development.
Waterfall or Agile: which to use?

Most of the driving factors leading to the emergence of adaptive development models lie in the
criticisms of traditional development models, such as the waterfall model, to address two basic
problems. The first issue begins at the requirements phase during which customers do not know
their exact requirements. This concern leads to changing requirements, redesign,
redevelopment, retesting, and increased costs. The second problem is the increasing
complexity and time to deliver traditional software development projects, where time to market is
too long to withstand any changes.
In the case of Agile and Scrum, the breakdown and visibility of work are present but without the
heavy overhead amounts of detail that traditional project management requires. Scrum seeks to
maximize the time spent on work and planning – just in time and just enough – versus traditional
project management, which spends a significant amount of time by planning in advance in an
exhaustive and detailed way.
The major value difference between the two approaches is that the traditional side is calculated,
controlled, managed, and focused on the schedule. Fundamentally different, the Agile side
focuses on delivering maximum value to customers by collaborating on release backlog and
sprint backlog items.
Traditional development models are best suited to predictive projects and products where the
requirements and scope are fixed, the product itself is firm and stable, and the technology is
clearly understood. Traditional development models are well suited to situations where contracts
are involved and are of a fixed price and scope.
Adaptive development models are best suited to chaotic projects and products where
requirements and scope will evolve over time, and/or the product itself will evolve over time,
and/or the technology will evolve over time.

An Introduction to Scrum
Scrum is “a lightweight framework that helps people, teams, and organizations generate value
through adaptive solutions for complex problems.”6
Scrum provides a structure of roles, artifacts, events, and rules for developing products. Scrum
is not a defined process, but an empirical knowledge approach driven by observations. Work is
done in increments by one or more self-managing, cross-functional, and high-performing teams
responsible for creating and adapting their processes within this framework.
Scrum is not limited to a specific process or set of techniques. It is a framework within which
organizations can employ processes and techniques. Like all frameworks, Scrum is best
adopted when tailored to an organization’s environment.
The Key Benefits of Scrum

When implemented effectively, Scrum:
▪ Offers a team-based approach to project work that allows a product development process to
benefit from iterative self-reflection
▪ Helps a team learn how to estimate their own ability to address unfamiliar tasks
▪ Exposes metrics about team effectiveness
▪ Encourages dialog about feature implementation instead of static specifications
▪ Supports a rapid response to changing market conditions in a sustainable manner
The Three Pillars of Scrum

The three pillars of Scrum are principles that uphold every implementation of 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.
Transparency means everyone involved in an Agile project has open access to information,
creating a trust-enriched environment.
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 technical 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.
6 Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum: The Rules of the Game. Scrum.org,
2020. Licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Inspection means the monitoring and evaluation of the products and processes to ensure that
the project conforms to established requirements.
Inspection refers to reviewing and inspecting the work. 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 toward 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.
Adaptation means improvements and changes are made quickly to minimize problems.
Adaptation is about being flexible, adjusting, and 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 developers may have been
working with a customer or 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.
Scrum, like Agile, is friendly towards change. Although late in the process, the developers
welcome the change as a way to ensure they produce a product that fully meets customers’
needs and values.

The Five Scrum Values

The successful use of Scrum depends on people
becoming more proficient in living the five values identified
in the diagram to the right.
The Scrum team personally commits to achieving its
goals and supporting each other. 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
people7.
The Scrum Framework

The Scrum framework consists of the Scrum team and their associated accountabilities, events,
and artifacts. Prescribed events are used in Scrum to create regularity and to minimize the need
for meetings that are not defined in Scrum. All events are time-boxed events, such that every
event has a maximum duration. Scrum artifacts provide key information that the Scrum team
and stakeholders need to be aware of to understand the product under development, the
activities being planned, and the activities completed in the project. The rules of Scrum bind
together the components of the Scrum team, events, and artifacts, and govern the relationships
and interactions between these components.
Like all practices and frameworks, Scrum is an integration of its components. It is dependent on
collaboration and cooperation between the Scrum team and stakeholders over the course of the
Scrum events, as well as the use of its defined artifacts.
Because the Scrum framework is based on empirical process control, it ensures that the work is
transparent and visible and that actual work results are the only true measure of progress.
Adapted from Rubin, Kenneth. Essential Scrum: A Practical Guide to the Most Popular Agile Process.
Boston, MA: Pearson Education, 2013, 14.
7 Schwaber and Sutherland, 2020

Ken Schwaber and Jeff Sutherland state in The Scrum Guide: “Each element of the framework
serves a specific purpose that is essential to the overall value and results realized with Scrum.
Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of
Scrum covers up problems and limits the benefits of Scrum, potentially even rendering it
useless.”8
The Scrum Team

The Scrum Team
The Scrum team consists of a maximum of ten people with one serving as the Scrum Master,
one as the product owner, and the rest as developers.
The Scrum team is responsible for all product-related activities from stakeholder collaboration,
verification, maintenance, operation, experimentation, research and development, and anything
else that might be required. They are structured and empowered by the organization to manage
their own work. Working in sprints at a sustainable pace improves the Scrum team’s focus and
consistency.
The entire Scrum team is accountable for creating a valuable, useful increment every sprint9.
The T-Shaped Professional

T-shaped skills describe specific attributes of desirable
workers. The top of the T refers to an ability to collaborate
with experts in other disciplines and a willingness to use
the knowledge gained from this collaboration. The vertical
bar of the T refers to expert knowledge and experience in
a particular area.
Scrum encourages multiskilled workers, rather than only
‘working to job title’, such as a ‘tester’ only doing testing.
In other words, team members actively seek out work and
help as much as possible.
If there are many testing tasks, then all team members
can help. This expectation does not imply that everyone
Moghaddam, Yassi et al. “T-Shaped: The New is a generalist, but team members are encouraged to
Breed of IT Professional.” Last modified work together and learn new skills from each other.
September 26, 2016. Accessed October 31, Pairing proves to be a valuable approach to sharing
2019. https://www.cutter.com/article/t-shaped-
new-breed-it-professional-492976 knowledge.


The Developers, Product Owner, and Scrum Master
Developers Product owner Scrum Master
DESCRIPTION
The people in the Scrum The person accountable for The person accountable for
team that are committed to maximizing the value of the the Scrum team’s
creating any aspect of a product resulting from the effectiveness, who enables
usable increment each sprint work of the Scrum team and the Scrum team to improve
effectively managing the its practices within the Scrum
product backlog framework
ACCOUNTABILITIES
▪ Creating a plan for the ▪ Developing and explicitly ▪ Coaching the team
sprint, the sprint backlog communicating the members in self-
▪ Instilling quality by product goal management and cross-
adhering to a definition of ▪ Creating and clearly functionality
done communicating product ▪ Helping the team focus
▪ Adapting their plan each backlog items on creating high-value
day toward the sprint goal ▪ Ordering and prioritizing increments that meet the
▪ Holding each other product backlog items definition of done
accountable as ▪ Ensuring that the product ▪ Responsible for the
professionals backlog is transparent, removal of impediments
visible, and understood to the team’s progress
▪ Ensuring that all Scrum
events take place and are
positive, productive, and
kept within the timebox
Other Responsibilities of the Scrum Master
Service to the product owner Service to the organization

▪ Helping find techniques for effective ▪ Leading and coaching the organization in
product goal definition and product its Scrum adoption
backlog management ▪ Planning Scrum implementations within
▪ Helping the Scrum team understand the the organization
need for clear and concise product ▪ Helping employees and stakeholders
backlog items understand and enact Scrum and
▪ Helping establish empirical product empirical product development
planning for a complex environment
▪ Facilitating stakeholder collaboration as
required or needed

Agile Work Environments

Collaboration through easy face-to-face discussions is the backbone of Agile practices and the
Scrum framework. Conversations and interactions need to be encouraged and facilitated by
environments in which Scrum teams work. However, it has become difficult to achieve the
required goals and objectives through collocated teams in today’s virtual and distributed
workplace.
Characteristics of effective colocation Characteristics of effective virtual teams

▪ Workspace that promotes collaboration ▪ Appropriate collaboration and
and face-to-face communication but also communication tools (videoconferencing,
allows for an uninterrupted focus shared screens, instant messaging, and
▪ Visible information radiators digital Agile management tools)
▪ Plenty of flexible and physical ▪ Negotiating work hours across time zones
collaboration tools ▪ Cultural connectedness
▪ A one-off, in-person team formation or
project kickoff gathering
Scrum Artifacts
“Scrum’s artifacts represent work or value. They are designed to maximize the transparency of
key information. Thus, everyone inspecting them has the same basis for adaptation”10.
The Product Backlog

The product backlog is “an emergent, ordered list of what is needed to improve
the product. It is the single source of work undertaken by the Scrum team”11.
The product backlog is at the center of the Scrum framework. Everything in

Scrum is derived and driven from it.
A product is a vehicle to deliver value. It has a clear boundary, known
stakeholders, and well-defined users or customers. A product could be a service,
a physical product, or something more abstract.
The product goal is the long-term objective for the Scrum team and is in the
product backlog. It describes a future state of the product, which serves as a
target for the Scrum team to plan against.
Accountability for effective backlog management lies with the product owner.
Product Backlog Items and Labels

The Scrum Guide does not prescribe labels for different types of product backlog items, and the
terms used to describe product backlog items can vary from one organization to another. Labels
are only important from the perspective of standardizing their use in an organization.12


Common examples include:
Epic Feature User story

▪ Typically describes an ▪ A collection of related ▪ A story describes a discrete
entire workflow; is large user stories part of the overall product’s
and broadly defined ▪ Used for products that functionality. These act as
▪ Is broken down into are large and/or the building blocks for the
smaller PBIs (features complex product.
and user stories) when it ▪ Used as a planning and ▪ The story describes a
is time to plan the work decomposition level functionality that enables a
into sprints between an epic and its customer to achieve a
▪ Can span more than one stories specific job.
project if multiple ▪ Use language that is
projects are included in understandable to both
the project board to business and technical
which the epic belongs people
▪ Useful when starting a
product for the first time
or when gathering a new
set of requirements for a
release update
Acceptance Criteria
Acceptance criteria are based upon what is necessary to satisfy the needs of the stakeholders.
Acceptance criteria can be thought of as the criteria necessary to pass user testing in the
development process and used to demonstrate the requirement to the user, customer, or
stakeholder during the sprint review event.
Product Backlog Refinement

It is the responsibility of the product owner to make sure the product backlog is ready for the
start of a sprint planning meeting. This involves the refinement, which is done in conjunction
with the developers, although it is not a separate event. The Scrum Master can facilitate the
refinement as needed.
Refinement is the first opportunity for the developers to size the items. Sizing can be refined
during the actual sprint planning session.

Sizing Techniques
Ideal time
The use of an ideal time approach may be easier to start with since people are most familiar
with it. The key to success with Scrum ideal time is to accept that ideal time is simply a number,
where a larger number requires more effort than a smaller number. This approach is based on
an assumption that all knowledge, resources, and anything else that’s required will be available
when and where needed. There will be no interruptions, and the PBI is the only thing being
worked on. We know such estimates will not equate to clock time. There will always be
interruptions due to company meetings, sick days, non-sprint related activities, and other
events. Again, the key to success is to recognize that ideal time is simply a number for
comparison.
Story points
To do this type of sizing, story points require a reference story of a defined size. Using this
reference story, a new PBI is read and then compared to the reference story. The PBI will then
be assessed for a magnitude of difference for how much larger or smaller it is compared to the
reference story. Comparison to a reference story is the key difference between a story point and
ideal time sizing, where ideal time does not require a reference story.
The Fibonacci Sequence

An exponential scale (one that grows at an increasing rate) provides more detail for smaller
tasks, and forces uncertainty for larger tasks. This helps build your estimates through the use of
increasing uncertainty because the time estimates get longer, creating a more efficient and
effective estimation.
Planning Poker®
A consensus-based approach used to size product backlog items that balances group thinking
and individual thinking.
Numbered Cards:
▪ 1-3 small items
▪ 5-13 medium items
▪ 20-40 large items
▪ 100 extra-large items
Only the developers play.
The Scrum Master facilitates.
The product owner reads the requirements and provides

details.
Planning Poker® is a registered trademark of Mountain Goat Software, LLC.
Cohn, Mike. “What Is Planning Poker?” Mountain Goat Software. Accessed 2/2/2021.
https://www.mountaingoatsoftware.com/agile/planning-poker

Sizing with Triangulation

The triangulation technique is used for story point sizing and results in faster and more accurate
results.
The product owner reads a user story, “As a
user, I want to be able to filter my calendar
to see appointments and tasks completed,
so that I can use the calendar as an audit
trail for my work year.”
If the developers agree the new story is
larger than the 1-point reference and smaller
than the 8-point reference, then – if using
the Fibonacci scale – the team would have
to estimate choices between 2, 3, and 5.
Cohn, Mike. “How to Prevent Estimate Inflation,” Mountain Goat
Software (blog), last modified May 3, 2016.
https://www.mountaingoatsoftware.com/blog/how-to-prevent-
estimate-inflation
The Sprint Backlog

“The sprint backlog is composed of the sprint goal (why) and the set of product
backlog items selected for the sprint (what), as well as an actionable plan for
delivering the increment (how)”13.
The sprint backlog is a plan by and for the developers created during the sprint
planning event. It is a highly visible, real-time picture of the work the developers
plan to accomplish during the sprint to achieve the sprint goal, which is updated
throughout the sprint and should have enough detail that progress can be inspected during the
daily Scrum.
The user stories selected for the sprint make up the sprint backlog. In essence, the sprint
backlog is the team’s short-term plan (duration of the sprint) for turning selected product backlog
items into an increment.

The Increment
An increment is a concrete stepping-stone toward the product goal. Each increment
is additive to all prior increments and thoroughly verified to ensure that all increments
work together. In order to provide value, the increment must be usable”14.
The definition of done is a formal description of the state of the increment when it
meets the quality measures required for the product. It is the commitment for the increment.
Scrum Events
Product Planning before the Sprints
On Agile projects, we plan at multiple levels of detail and at multiple times throughout product
development.
All planning and priority decisions for an enterprise emanate from the highest levels. The
mission or organizational purpose describes the reason the organization exists. In support of the
mission is the vision (the anticipated future) for the organization – usually set for five to 10 years
– setting an inspirational tone for the organization and expectations around future planning.
The strategies then support the accomplishment of the vision, which in turn will drive changes to
the product portfolio, which will drive product changes, etc. The rationale for decisions that must
be made eventually at the sprint level are hierarchically linked to organizational direction.
Priority decisions around product backlog refinement and what should be included in the next
sprint are not random in nature but driven by a perspective of the big picture.
The planning onion is also a brilliant way to
describe the three pillars of Scrum.
Transparency must happen at all levels –
from planning to progress reporting – for the
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
Adapted from: Roach, Thomas. “What Does the Planning and adapt to the new reality.
Onion Mean to You?” My Agile Mind. Last modified October
28, 2011. Accessed August 13, 2019.
https://myagilemind.wordpress.com/2011/10/28/what-does-the-
planning-onion-mean-to-you/

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
team, artifacts, and events. 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.15
The Sprint
Iterations in the Scrum framework are referred to as sprints and are comprised of several
events: sprint planning, daily Scrums, the sprint review, and the sprint retrospective. During
each sprint the Scrum team performs the work necessary for turning ideas into increments of
value for the stakeholders.
Sprints have a fixed duration of one month or less to establish a consistent pace. Once a sprint
concludes, a new sprint starts immediately.
All events in the sprint:
▪ Are timeboxed, including the sprint itself
▪ Enable predictability by ensuring inspections and the adaptation of progress toward a
product goal
Timeboxing
Timeboxing is a time management technique where an activity is allocated a fixed period of
time.
The goal is to define and limit the amount of time dedicated to an activity. The
sprint events are timeboxed to ensure a focus on and high levels of productivity in
accomplishing the work, as well as for establishing a regular cycle for being agile
and adaptive. The critical rule for timeboxing is that work stops at the end of the
specified time limit, followed by a review of progress.
15Doshi, Hiren. “The Three Pillars of Empiricism (Scrum),” Scrum.org (blog), last modified December 4, 2016, accessed August 13,
2019. https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum

Sprint Planning
Sprint planning initiates the sprint by laying out the work to be performed for the sprint. This
resulting plan is created by the collaborative work of the entire Scrum team.
The product owner ensures that attendees are prepared to discuss the most important product
backlog items and how they map to the product goal. The Scrum team may also invite other
people to attend the sprint planning to provide advice16.
Calculating Capacity
An important factor in sprint planning is the capacity of the developers. An example of how to
calculate capacity is shown in this simple equation: the number of team members multiplied by
the number of days in the sprint multiplied by the number of productive hours in a day. In most
cases, more complex parameters are considered in the capacity planning equation, but this
calculation can be used for teams that have achieved a consistent velocity of story points
completed per sprint. Even with these ideal teams, additional parameters will need to be taken

into account if a team member is unavailable for some or all of the sprint, if members are added
or leave the team, and if the technology and domain knowledge change ahead of the next
sprint.
Velocity
The points completed per sprint is called the velocity of the team. A realistic release plan is
always based on the velocity of the team.
Velocity, while not formally a part of the Scrum framework, is a concept used by many Scrum
teams. It is an extremely powerful, yet simple concept based on the theory that a Scrum team’s
past performance and productivity will be the same for current projects. This assumption is
made realistic in Scrum due to timeboxing and the consistency with which a Scrum team works.
The developers work at a consistent pace, which means that each workday is timeboxed to a
consistent time, such as eight hours per day. Each work cycle is defined by a consistent sprint
timebox, typically two to four weeks in length. The events within each sprint cycle are
consistently repeated and timeboxed. This overall consistency of behavior and timeboxing
makes the use of velocity in Scrum very reliable.
A critical aspect of using velocity is knowing how to credit ‘work done’ to calculate velocity.
Work gets done in Scrum during the sprint event, and it must meet the criteria established as
part of the organization’s or the team’s definition of done (DoD).
At the end of the sprint, work that is only partially done, or work that does not meet the DoD,
cannot be counted toward velocity. Work is only credited in the sprint when it is fully done.
Sprint Planning Addresses Three Topics

The product owner proposes how the product could increase
its value and utility in the current sprint. The whole Scrum
team then collaborates to define a sprint goal that
communicates why the sprint is valuable to stakeholders.
The sprint goal must be finalized prior to the end of sprint
planning.
Through discussion with the product owner, the developers
select items from the product backlog to include in the
current sprint. The Scrum team may refine these items
during this process, which increases understanding and
confidence. Selecting how much can be completed within a
sprint may be challenging. However, the more the
developers know about their past performance, their
upcoming capacity, and their definition of done, the more
confident they will be in their sprint forecasts.
For each selected product backlog item, the developers plan
the work necessary to create an increment that meets the
definition of done. This is often done by decomposing
product backlog items into smaller work items of one day or
less. How this is done is at the sole discretion of the
developers. No one else tells them how to turn product
backlog items into increments of value.17

Sprint Execution
Sprint execution, while not a formally named event, represents the work the Scrum team
performs to deliver one or more increments that meet the DoD and the sprint goal.
Sprint execution is the work that a Scrum team performs to meet a sprint goal. It begins after
sprint planning and ends when the sprint review starts18.
Task Planning and Flow Management

Planning and managing the tasks and tracking progress is done visually using a variety of
information radiators. Being able to see the flow of the work as tasks and user stories that
progress across the columns of the Scrum board is critical to the developer’s ability to self-
manage their work and adapt when and where necessary. Tracking progress can be
accomplished with burn-down or burn-up charts.
The following questions can be helpful for planning:
▪ What work needs to be done and who should do the work?
▪ How much work should we do in parallel?
▪ When should work begin on a specific item?
▪ How should the task-level work be organized?
▪ What is our work-in-progress limit so that we reduce multitasking and collaborate on tasks
for synergy?
18 Rubin, Kenneth S. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Boston, MA: Pearson Education, 2013.

The Scrum Board

A Scrum board (also known as a task
board, kanban board, sprint wall, and
sprint backlog wall) is a transparent
and visible working plan for the
developers. It is as detailed as is
needed to coordinate and collaborate
on the work being done. It is a visible
and physical display of the sprint
backlog,
On a physical Scrum board, written
sticky notes or index cards are placed in the first two columns for PBI user stories and their
tasks. Developers collaborate on which PBI and tasks to work on and move them to the ‘in
progress’ column. As tasks and user stories/PBIs are completed, each is moved to the ‘done’
column.
The Sprint Burn-Down Chart

Burn-down charts communicate how
much work is remaining and how task
completion is trending throughout
sprints. A sprint burn-down chart is a
graphical, real-time picture of the work
outstanding in sprints. It helps
organizations visualize whether the
developers are on track to complete the
remaining work. As the chart is updated
daily, the y-axis of a sprint burn-down
chart represents the number of points
remaining, whereas the x-axis
represents the number of days
Lacey, Mitch. The Scrum Field Guide: Agile Advice for Your First Year
and Beyond. Boston, MA: Pearson Education, 2016, 431. remaining in the sprint.
A sprint burn-down chart is ideally a downward sloping graph on a trajectory to reach “zero
effort remaining” by the last day of a given sprint and is, hence, called a burn-down chart. It
shows the progress toward the sprint goal in terms of the amount of work to be completed in the
future19.
19 Sutherland, 2010

The Expanded Scrum Board

The expanded sprint board is an aggregation of several key sprint artifacts that includes the task
board, sprint goal, and one or more information radiators such as the sprint burn-down chart.
The Daily Scrum

The daily Scrum is a synchronization, inspection, and adaptive planning activity that optimizes
team collaboration and performance.
This is a meeting by and for the developers, although the Scrum master is likely to facilitate and
guide the team as needed. To keep it brief, it is recommended that everyone remain standing. It
is the team’s opportunity to report to each other and inspect each other’s progress and
obstacles. Because the developers are free to structure this meeting in whatever way they
choose, there is no definitive set of questions or techniques that must be used. An example of
an approach used by some teams is for each developer to report to the team:
▪ What they were able to get done since the last meeting
▪ What they are planning to finish by the next meeting
▪ Any problems or impediments that are in their way
Note that the daily Scrum is not a status meeting to report to a manager; it is a time for a self-
managing team to share with one another what is going on, to help it coordinate its work, and to
optimize its likelihood of meeting its commitments. Impediments can be noted for discussion
outside of the daily Scrum.

Sprint Review
The sprint review is an event during which the outcome of the sprint is inspected, adaptations
are identified, and progress toward the product goal is discussed.
A sprint review is an informal session, not a status meeting, during which the increment
produced during the sprint is presented to stakeholders. The intent of this meeting is to foster
collaboration between the stakeholders and the Scrum team, and to provide an opportunity to
capture stakeholder feedback. Project progress can be reviewed along with any adaptations
that might be required for the product backlog. This can also be an opportunity to discuss the
release of this increment for use by the stakeholders.
A sprint review is also an opportunity to demonstrate the pillars of transparency and inspection.
The only stakeholders to see the finished work prior to the sprint review are the PBI
stakeholders collaborating with the developers. Through a demonstration of the increment,
sponsors and other stakeholders should be brought back into the loop to solicit their overall
feedback.
No one (including the developers) has stopped during sprint execution to holistically inspect the
changes as a whole and observe how the product is evolving. This level of feedback is needed
to ensure we optimize globally (at the product level) and do not get lost in the weeds at the more
granular PBI level.
There is also the sprint goal that needs to be reviewed and – hopefully – celebrated.

The Sprint Retrospective

The sprint retrospective is an opportunity for the Scrum team to inspect itself and create a
plan for improvements to be enacted during the next sprint. The sprint retrospective occurs after
the sprint review and prior to the next sprint planning.
The Scrum team inspects how the last sprint went with regards to individuals, interactions,
processes, tools, and their definition of done. Inspected elements often vary with the domain of
work. Assumptions that led them astray are identified and their origins explored. The most
impactful improvements are addressed as soon as possible. They may even be added to the
sprint backlog for the next sprint.20
Improvement Stories
Improvements should follow the organization’s approach to documenting work as stories.
Below are two possible templates, the one on the left is the same format as user stories seen
earlier. The one on the right leads with the ‘why’ proposition, which can help the team focus on
the value of the improvement.
As with any kind of improvement, it is important to determine how the team is going to measure
the impact of that improvement.

Improvement Board
Like many other things, the technique for capturing and
monitoring improvements is not specified in The Scrum
Guide. The improvement board is an approach seen in
Lean and other practices and helps to make the
improvement opportunities and their progress visible.
Just as we’ve seen with other boards, it’s important for
the team to capture and make visible the improvements
identified during a retrospective. This improvement
board serves as a reminder of what they want to do differently in the next sprint and shows the
progress of chosen improvements.
Releasing the Increment

Release Planning
Note that The Scrum Guide has not addressed release planning since the 2011 version where it
was stated, “Release planning is a valuable thing to do when using Scrum but isn’t required by
Scrum itself.”21 Release planning remains in the bigger context of Agile and, in Scrum, it is
carried out iteratively, often at the end of each sprint.
The goal of release planning is to determine what constitutes the most valuable next release,
and what the desired level of quality is.
Release planning must balance customer value and overall quality against the constraints of
scope, schedule, and budget22.
Fixed-Scope Release versus Fixed-Date Release

Two primary approaches for releases are:
▪ Fixed scope releases are appropriate when the scope of a project is more important than
its date or budget. If time runs out before the completion of all the features, the project’s
date and budget are extended.
▪ Fixed date releases are most closely aligned to Scrum principles. When time runs out on a
project, incomplete features are dropped and moved to the next sprint or iteration.
The Release Backlog

A release backlog is a subset of the product backlog that represents those product backlog
items completed during a sprint and accepted by the customers or key stakeholders. The
product owner is solely responsible for managing the release backlog.
21 Scrum Guides. "Changes between 2010 and 2011 Scrum Guides." Scrumguides.org. Accessed February 4, 2021.
https://www.scrumguides.org/revisions.html
22 Rubin, 2013

References
▪ Agile Alliance. “Agile 101.” Agile Alliance, 2011. https://www.agilealliance.org/agile101/
▪ Beck, Kent et al. “Manifesto for Agile Software Development”. Accessed April 23, 2021.
http://agilemanifesto.org/
▪ Cohn, Mike. “How to Prevent Estimate Inflation.” Mountain Goat Software (blog). May 3,
2016. https://www.mountaingoatsoftware.com/blog/how-to-prevent-estimate-inflation
▪ — . “What Is Planning Poker?” Mountain Goat Software. Accessed 2/2/2021.
https://www.mountaingoatsoftware.com/agile/planning-poker
▪ Doshi, Hiren. “The Three Pillars of Empiricism (Scrum).” Scrum.org. Last modified
December 4, 2016. Accessed August 13, 2019. https://www.scrum.org/resources/blog/three-
pillars-empiricism-scrum
▪ Layton, Mark C. and Steven J. Ostermiller. Agile Project Management for Dummies, 2nd
Edition. Hoboken, NJ: John Wiley & Sons, 2017.
▪ Roach, Thomas. “What Does the Planning Onion Mean to You?” My Agile Mind. October 28,
2011. Accessed August 13, 2019. https://myagilemind.wordpress.com/2011/10/28/what-
does-the-planning-onion-mean-to-you/
▪ Rubin, Kenneth S. Essential Scrum: A Practical Guide to the Most Popular Agile Process.
Boston, MA: Pearson Education, 2013.
▪ Scrum Guides. "Changes between 2010 and 2011 Scrum Guides." Scrumguides.org.
Accessed February 4, 2021. https://www.scrumguides.org/revisions.html
▪ Schwaber, Ken and Jeff Sutherland. The Scrum Guide™, the Definitive Guide to Scrum:
The Rules of the Game. Scrum.org, 2020. Licensed under a Creative Commons Attribution-
ShareAlike 4.0 International License.
▪ Sutherland, Jeff. Jeff Sutherland’s Scrum Handbook. Scrum Training Institute, 2010.

ASE Course Supplement 2.2.1 August 2022

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ASE Course Supplement 2.2.1 August 2022

Uploaded by

Copyright:

Available Formats

Celebrating over 40 Years

Agile Scrum EssentialsTM

How to Use This Document........................................................................................................ 4

©Pink Elephant, 2022 unless otherwise stated.

Calculating Capacity ..............................................................................................................21

©Pink Elephant, 2022 unless otherwise stated.