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
2. 8/18/21
2
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
3. 8/18/21
3
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
6. 8/18/21
6
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
7. 8/18/21
7
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
8. 8/18/21
8
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
10. 8/18/21
10
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
13. 8/18/21
13
Estimate Ranges (cont.)
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
15. 8/18/21
15
[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
16. 8/18/21
16
[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
20. 8/18/21
20
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
21. 8/18/21
21
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
22. 8/18/21
22
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.
27. 8/18/21
27
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.)
29. 8/18/21
29
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
31. 8/18/21
31
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.
33. 8/18/21
33
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:
34. 8/18/21
34
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
36. 8/18/21
36
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
37. 8/18/21
37
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
oneiteration.
• 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
38. 8/18/21
38
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