Agile, Scrum, PMI - ACP, Adaptive Planning in Agile

1. 8/18/21
1
DOMAIN V
Adaptive Planning
(version 2.2)
MSc. PMP. Nguyen Thanh Phuoc
phuocnt@gmail.com
Key Topics about Adaptive Planning
• Affinity estimating
• Agile discovery
• Agile sizing and estimating techniques
• Daily stand-ups
– Ground rules; Three questions
• Defining and testing acceptance criteria
• Estimating initial velocity
• Estimating tasks
• Fast failure; Ideal time
• Iteration planning process
• Planning poker
• Product roadmap
• Wideband Delphi
2
• Progressive elaboration
• Relative sizing; T-shirt sizing
• Release planning process
• Rolling wave planning
• Slicing stories
• Spikes
– Architectural spike
– Risk-based spike
• Story maps, Story points
• Timeboxing
• User stories; User story backlog
– Refining (grooming) the backlog
– Requirements reviews
• Value-based analysis and
decomposition
Tasks TO DO
1. Use progressive elaboration and rolling wave planning to plan at
multiple levels.
2. Make planning transparent and involve key stakeholders
3. Manage expectations by refining plans as the project progresses
4. Adjust planning cadence based on project factors and results
5. Inspect and adapt the plans to changing events
6. Size items first, independent of team velocity
7. Adjust capacity for maintenance and operations demands to
update estimates
8. Start planning with high-level scope, schedule, and cost range
estimates
9. Refine ranges as the project progresses
10. Use actuals to refine the estimate to complete
3
Agile Planning Concepts

2. 8/18/21
2
Agile Planning Concepts
5
• Adaptive planning approach is an on going process and provides
multiple mechanisms to pro-actively update the plan
• Predictive planning or static approach is created up front and re-
planning is done primarily in response to exceptions to the plan
and change requests
• Adaptive planning focuses on value delivery; and minimize any
non-value-adding work
Agile Planning Concepts
• Agile vs Non-Agile Planning
– Agile planning differs from
traditional planning in three
key ways
1. Trial and demonstration
uncover the true
requirements, which then
require re-planning
2. Agile planning is less of an up-
front effort, and is instead
done through out the project
3. Mid course adjustments are
the norm
6
Agile Planning vs Non-Agile Planning
• Trial and Demonstration Uncover the True Requirements, Which
Then Require Re-planning
– So instead of creating very detailed specifications and plans,
agile projects build a prototype to better understand the
domain and
– Use this prototype as the basis for further planning and
elaboration
• Agile Planning is less of an up-front effort, and is instead done
throughout the project
– distribute the planning effort throughout the project’s
lifecycle
– Executing a knowledge work project is a complex, creative,
and high-risk endeavor and often intangible
7
Agile versus Non-Agile Planning (cont.)
8

3. 8/18/21
3
Agile versus Non-Agile Planning (cont.)
9
Agile versus Non-Agile Planning (cont.)
• Time and Effort Invested in Plans
– The dotted line on this diagram represents the risks involved in
doing too much up-front planning
– The risk of creating a very detailed, brittle plan increases—as does
the risk of delaying the delivery of value and return on investment
because of the amount of time spent planning
– Boehms conclusion is that
we should aim for the sweet
spot where the sum of these
two risks is lowest
è We need to do enough up-front
planning to minimize the risk of
duplication and rework
11
Agile versus Non-Agile Planning (cont.)
• Midcourse Adjustments are the Norm (constant)
– When aiming at a static target, the best approach is to aim very carefully
and then fire directly at the fixed target
– However, when aiming at a moving target that isn’t following a predictable
path, we need more of a guided-missile approach, making a lot of mid-flight
adjustments to ensure our efforts reach their goal
12
Agile versus Non-Agile Planning (cont.)
• Agile methods don’t shy away from planning è suited to a quickly
changing environment
• Planning occurs on agile projects first with a high-level plan, and then
at regular points through out the project for subsequent releases and
iterations.
• Agile teams also factor a lot of feedback into these ongoing planning
processes. For example:
– Backlog reprioritization affects iteration and release plans.
– Feedback from iteration demonstrations generates product
changes and new requirements
– Retrospectives generate changes to the team’s processes and
techniques.
13

4. 8/18/21
4
Principles of Agile Planning
1. Plan at multiple levels
– Product => Release => Iteration => Task
2. Engage the team and the customer in planning
– a leader or the manager will have all the information required to satisfy
customer’s needs
– knowledge and technical insights and also generate their plan and
commitment for the plan
3. Manage expectations by frequently demonstrating progress and
extrapolating velocity
4. Tailor processes to the project’s characteristics.
– Large projects will need more planning and small projects
– If there are a lot of uncertainties, the team will need to plan for spikes to
explore options and confirm that the proposed technological approach will
work.
14
Principles of Agile Planning (cont.)
5. Update the plan based on the project’s priorities
– Be reflected in the backlog priorities created by the product
owner in collaboration with the development team
– need to re-examine our backlog and release plans to see if it
means that anything else needs to be changed
6. Ensure encompassing estimates that account for risk, distractions,
and team availability
– Sponsors want to know when things will be done; therefore,
estimates that don’t take into account known variables are
unrealistic and unhelpful
– To produce better estimates, we start with base historical
averages (such as velocity trends), and then factor in future team
availability and the distractions, diversions, and other calls on the
team’s time that will inevitably occur.
15
Principles of Agile Planning (cont.)
7. Use appropriate estimate ranges to reflect the level of
uncertainty in the estimate
– Recording my time should take 15 to 20 minutes
– I hope to complete the portrait painting of your family in 5 to 8 days
8. Base projections on completion rates.
– based on actual completion data for the project
– show our real, rather than ideal, rate of progress
– so are more likely to be replicated in the future than plans based on
theory rather than reality
9. Factor in diversions and outside work.
– to support old projects; go on vacation
– both planned and unplanned absences
==> So our plans should not assume year-round availability or 100 percent
dedication to a project; we need to factor in some nonproductive time
16
[K&S] Agile Discovery
• The concept of “agile discovery” is an umbrella term that
refers to the evolution and elaboration of agile project plans
in contrast with an up-front approach such as:
– Emergent plans and design vs. predictive plans and design
– Estimating uncertain work vs. certain work
– The characteristics of new product development vs. well-
understood and repeatable projects
17

5. 8/18/21
5
[T&T] Progressive Elaboration
• Progressive elaboration refers to the process of adding
more detail as new information emerges.
• Agile methods rely on progressive elaboration to first
create, and then refine, many kinds of project assets to
make them increasingly accurate as the team learns
more about the project.
• These “progressively elaborated” assets might include:
– Plans - Estimates
– Risk Assessments - Requirements definitions
– Architectural designs - Acceptance criteria
– Test scenarios
18
[T&T] Progressive Elaboration (cont.)
19
Progressive Elaboration versus Rolling Wave Planning
• The difference between “rolling wave planning” and
“progressive elaboration”
– Rolling wave planning
• Planning at multiple points in time as more information
about the project becomes available.
• Rolling wave planning is the game plan that says “We won’t
try and do all our planning up front. We recognize that it will
be better to plan a bit, and then revisit and update our plans
multiple times throughout the project”
– Progressive elaboration
• It Is how we implement the rolling wave planning approach.
20
[K&S] Value-Based Analysis
• Agile planning is based on value-based analysis
1. Assessing and prioritizing the business value of
work items
2. Then planning accordingly
21

6. 8/18/21
6
[K&S] Value-Based Decomposition
• Value-based decomposition is a continuation of the
process of value-based analysis
22
[T&T] Time-boxing in Planning
• Time-boxing is setting a fixed time limit to overall
development efforts and letting other characteristics
such as scope vary.
• Time-box can be any length of time [1 year, 1 month, 1
day]
• Control is achieved at the lowest level of time-boxing
• If you are running behind the schedule, postpone it to
the next time-box
• Fixes the length of the iteration and the team
determines how much functionality can be delivered in
that fixed length of time
[T&T] Time-boxing (cont.)
24
Estimate Ranges
• In traditional project, we estimated by expert-knowledge-based;
parametric (calculation-based); analogy
• In agile projects are typically more difficult to estimate than other
types of projects
– The organization might not have undertaken a similar project before
– The approach or technology being used might be new
– There might be other significant unknowns
è more problematic to provide estimates for knowledge work
projects.
• To help manage this uncertainty, agile teams avoid using single-
point estimates; instead, we present estimates in ranges to
indicate our level of confidence in the estimate and manage our
stakeholders’ expectations.
26

7. 8/18/21
7
Estimate Ranges (cont.)
pically move from a very broad
27
Key points in Estimation (cont.)
• Why do we estimate?
– Estimates are necessary for scheduling the project and determining which pieces of
work can be done within a release or iteration
• When do we estimate?
– Agile teams continuously refine their estimates until the last responsible moment
before the work is done. Up-front estimates are certainly necessary, but they are
also the least accurate since that is when we know the least about the project.
• Who estimates?
– In agile methods, the team members who will be doing the work are responsible for
estimating their own work
• How are estimates created?
– Estimates are created by progressing through the stages of sizing, estimating, and
planning
• How should estimates be stated?
– There is always some degree of uncertainty in our estimates. Therefore, estimates
should be stated in ranges (e.g.,“$4,000 to $4,500,”or “16 to 18 months”) that show
their degree of certainty, to manage stakeholder expectations.
28
Tools for Sizing
and Estimating
[K&S] Tools for Sizing and Estimating
• Sizing, Estimating, and Planning
• We need a way to break down large chunks of work into
smaller units that we can size, estimate, and plan
Decomposing Requirements
32

8. 8/18/21
8
[K&S] Tools for Sizing and Estimating (cont.)
• Decomposing Requirements
• Requirements Are Decomposed “Just in Time”
33
[T&T] User stories
• A user story is defined as a “small chunk of business functionality
within a feature that involves roughly 1 to 3 days’ worth of work”
• Agile teams typically break the product features down in to user
stories and write them on index cards or enter them into a
requirements management tool
• Although there is no one “right” template for user stories, they
are often written in the following format:
– “As a <Role>, I want <Functionality>, so that <Business
benefit>”
Example: As a Movies Online customer, I want to search movies
by actor , so that I can more easily find movies I would like to
rent.
34
[T&T] User stories (cont.)
• And another user story format
- “Given, When, Then” can be used to document non-
functional or system- based requirements and then
also used for acceptance tests.
Given the account is valid and the account has a MoviesOnline
balance of greater than $0,
When the user redeems credit for a movie,
Then issue the movie and reduce the user’s MoviesOnline
balance.
35
[T&T] User stories (cont.)
• The Three C’s
– The card:
• just enough text to identify the story;
• doesn’t provide all-inclusive requirements
è contract for a conversation
– The conversation
• The details of the story are communicated via a conversation
- a verbal exchange of ideas, opinions, and information
between the customer and the development team
• When the story is prepared for development then this
conversation might be supplemented with documents
– The confirmation
• “Confirmation” means that the product increment passes
the customer’s acceptance tests
36

9. 8/18/21
9
[T&T] User stories (cont.)
• The Three C’s
37
[T&T] User stories (cont.)
• INVEST (Characteristics of Effective User Stories)
Software Stories Should
Include All Relevant Architectural Layers
38
[T&T] User Story Backlog (Product Backlog)
39
• This tool helps the stakeholders coordinate the project and
keeps everyone working toward the agreed-upon mission
[T&T] Refining (Grooming) the backlog
There are three types of changes that
may need to be made to the backlog:
1. New stories may be added
2. Existing stories may be
reprioritized or removed
3. Stories may be sliced into smaller
chunks or resized
Any changes to the backlog should be
discussed in the next planning meeting
to ensure that they are understood by
everyone.
• [T&T] Requirements Reviews it is
essentially another name for the
process of refining or grooming the
backlog
40

10. 8/18/21
10
[T&T] Relative Sizing and Story Points
41
• People are not very accurate at making absolute estimates, they
are better at making comparative (relative) estimates è estimate
more efficiently and accurately, agile teams rely on relative sizing
• They do most of their estimating not in hours or days, but in a
relative unit called “story points.”
• Estimating in terms of relative size
rather than absolute size allows
us to make useful estimates
• Story point estimating is typically based on the Fibonacci
sequence of numbers
6
6
Story Points
§ The “bigness” of a task is influenced by,
• How hard it is (complexity)
• How much of it there is (effort involved)
• How risky it is?
§ Relative values are what is important:
• A login screen is a 2, A search feature is an 8.
§ Estimate using the relative values
• Select the smallest story and estimate as 1 story point
• Select a medium-sized story and estimate it as 5 story
points
7
7
Estimate byAnalogy
• Comparing a user story to others
o “This story is like that story, so its estimate is what that story’s
estimate was.”
• Don’t use a single gold standard
o Triangulate instead
• Compare the story being estimated to multiple other stories
Affinity estimating is a technique many teams use to quicklyand
easily estimate (in story points) a large number of user stories.
• Is quick and easy
• Decision making process is visible
• Creates a positive experience rather than confrontational one
[T&T] Affinity Estimating

11. 8/18/21
11
Affinity Estimation - Process
• Product backlog is provided by the product owner
• Team members are expected to size each item
relative to other items on the wall considering the
effort involved in implementation
• Stories are arranged horizontally
Affinity Estimation - Process
• Involves editing the relative sizing on the wall
• Involves discussions as all the items in the
product backlog are placed on the wall and
moved in either direction according to the
relative sizing
Affinity Estimation - Process
• Depending upon the nomenclature that the
team(s) decided to use, place the sizes along
the spectrum at the top of the wall between
smaller and larger.
Affinity Estimation - Process
• The product owner discusses the size of the stories of
the product backlog
• Following approaches can be taken in case of
changing sizes,
a. When team members decide that an item should
be resized put it onto a separate wall for resizing
after challenge has completed.
b. Have team members decide on the spot with the
product owner what the new size is.

12. 8/18/21
12
Affinity Estimation - Process
The estimates are documented
[T&T] T-Shirt Sizing
50
[T&T] T-Shirt Sizing
51
[T&T] Story Maps
• A story map is a high-level planning tool that agile stakeholders
can use to map out the project priorities early in the planning
process
52

13. 8/18/21
13
[T&T] Product Roadmap
• A product roadmap is a visual depiction of the product releases
and the main components that will be included in each release
• Although there are various ways of depicting a product roadmap,
story maps are a commonly used approach, as popularized by Jeff
Patton
53
[T&T] Product Roadmap
54
• Affinity estimating, T-shirt sizing, story maps, and roadmaps— are
sizing tools used for high-level planning
• Experts submits estimates anonymously so that none of the
participants know who has made which estimate.
• This anonymity produces improved estimates because it minimizes
the cognitive and psychological biases that can result in flawed
estimates, including:
o The Bandwagon effect è it doesn’t reflect their own opinion
o HIPPO decision making (HIPPO=Highest-Paid Person’s People
Opinion): gravitate to the ideas of experts or superiors, rather
than judging ideas on their own merit)
o Groupthink: People make decisions to maintain group
harmony rather than expressing their honest opinions
[T&T] Wideband Delphi
Wideband Delphi estimation reflects agile values, because it is:
• Iterative: The process is repeated several times, until a consensus is
reached.
• Adaptive: Team members have a chance to update and improve
their next round of estimates based on discussion with other
participants
• Collaborative: A team based collaborative process improves
participants’ buy-in to theresults
[T&T] Wideband Delphi

14. 8/18/21
14
12
1
2
Ø An iterative approach to estimating
Ø Steps
1. Each estimator is given a deck of cards, each card has a valid
estimate written on it
2. Customer/product owner reads a story and it’s discussed briefly
3. Each estimator selects a card that’s his or her estimate
4. Cards are turned over so all can see them
5. Discuss differences (especially outliers)
6. Re-estimate until estimates converge
[T&T] Planning Poker
13
1
3
[T&T] Planning Poker (cont.)
Release and Iteration Planning
Release and Iteration Planning
• An iteration is a short, timeboxed development period, typically
one to four weeks in duration.
• A release is a group of iterations that results in the completion of a
valuable deliverable on the project.
• An agile project will have one or more releases, each of which will
contain one or more iterations, as illustrated below
70

15. 8/18/21
15
Type of Iterations
• Iteration 0 typically doesn’t involve building any deliverables
for the customer. Iteration 0 should be limited to “just
enough” for the first development iterations to be successful.
71
Spikes
• Spikes are a key tool that agile teams use to head off problems
and resolve them as early as possible
• A spike is a short effort (usually timeboxed) that is devoted to
exploring an approach, investigating an issue, or reducing a
project risk
• we’ll define two terms for specialized kinds of spikes
– Architectural Spike
• is a short, timeboxed effort dedicated to “proof of concept”
– Risk-Based Spike
• Is a short, timeboxed effort that the team sets a side to
investigate—and hopefully reduce or eliminate
• To test unfamiliar or new technologies early in the project before
we proceed too far with development
72
Spikes
• Fast Failure
– If a proof-of-concept effort isn’t successful, we can try a
different approach. But if none of the approaches we try are
successful, we reach a condition known as “fast failure.”
73 33
3
3
[T&T] Release Planning
Ø A release plan presents a roadmap of how the team intends to
achieve the product vision within the project objectives and
constraints identified in the project data sheet.
o It helps the product owner and the whole team decide how long it
will take before they have a releasable product.
o A release conveys expectations about what is likely to be
developed and in what timeframe.
o A release plan serves as a guidepost toward which the project team
can progress.

16. 8/18/21
16
Steps to Planning a Release
The team and product owner collaboratively explore the product
owner’s conditions of satisfaction that include scope,schedule,
budget, and quality
Determine
conditions
of
satisfaction
Estimate
the user
stories
Select
stories and
a release
date
Do in any sequence
Select an
iteration
length
Estimate
velocity
Prioritize
user
stories
Iterate until the release’s
conditions of satisfaction
can best be met
35
3
5
Release Planning
The purpose of release planning is to define the contents
of a release or a specific shippable product increment.
Slicing the Stories
• …
78
[T&T] Iteration Planning
• …
79

17. 8/18/21
17
38
3
8
Iteration Planning
An iteration plan is a low level view of the product where the team
takes a more focused, detailed look at what will be necessary to
implement, i.e., only those user stories, that have been selected for the
iteration.
• An iteration plan is created during the iteration planning meeting
• It can be as simple as a spreadsheet or a set of note cards with
one task handwritten on each card.
40
4
0
Length of Iterations (%respondents)
82% have iterations between 1 and 4 weeks in length:
41
4
1
Factors in Selecting an IterationLength
• The length of the release being worked on
• The amount of uncertainty
• The ease of getting feedback
• How long priorities can remain unchanged
• Willingness to go without feedback
• The overhead of iterating
• A feeling of urgency ismaintained
Velocity - Driven Iteration Planning
• Velocity is a measure of a team’s rate of progress per iteration.
• It is calculated by summing the number of story points assigned to
each user story that the team completed during the iteration.
Examples:
o The project team completes four stories in one iteration,
Story A – 5, Story B – 3, Story C – 7, Story D – 5.
Calculate the velocity?
=> Summing up the story points assigned to each user story
gives the velocity. Hence velocity = 5+3+7+5 = 20

18. 8/18/21
18
37
3
7
Velocity - An Example with Velocity = 14
42
4
2
Velocity - Driven Iteration Planning
43
4
3
Commitment - Driven IterationPlanning
In commitment-driven iteration planning, the team is asked to add
stories to the iteration one-by-one until they can commit to
completing no more.
44
4
4
Iterations Allow for Mid-CourseCorrections

19. 8/18/21
19
45
4
5
Release Plan vs. Iteration Plan
• The release plan looks forward through the release of the
product while the iteration plan looks ahead only the length of
one iteration.
• The user stories of a release plan are estimated in story points
or ideal days, the tasks on the iteration plan are estimated in
ideal hours.
[T&T] Daily Stand-Ups
90
Key Topics about Adaptive Planning
• Affinity estimating
• Agile discovery
• Agile sizing and estimating techniques
• Daily stand-ups
– Ground rules; Three questions
• Defining and testing acceptance criteria
• Estimating initial velocity
• Estimating tasks
• Fast failure; Ideal time
• Iteration planning process
• Planning poker
• Product roadmap
• Wideband Delphi
91
• Progressive elaboration
• Relative sizing; T-shirt sizing
• Release planning process
• Rolling wave planning
• Slicing stories
• Spikes
– Architectural spike
– Risk-based spike
• Story maps, Story points
• Timeboxing
• User stories; User story backlog
– Refining (grooming) the backlog
– Requirements reviews
• Value-based analysis and
decomposition
References
• PMI-ACP Exam Prep 2015 By Mike Griffiths, PMI-ACP, PMP
• Many other resources from Internet
92

20. 8/18/21
20
Thank you for your attention!
93