PMI-ACP Domain V: Adaptive Planning v1.0

9/7/19
1
DOMAIN V
Adaptive Planning
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

9/7/19
2
Tasks
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

9/7/19
3
5
• An adaptive approach acknowledges that planning is an
on going process and provides multiple mechanisms to
proactively update the plan
• Predictive planning, static approach in which most of the
plan is created up front and re-planning is done primarily
in response to exceptions to the plan and change
requests
• able to offer increased adaptability over the course of the
project life cycle by Adaptive Planning Approach
• 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
7

9/7/19
4
Agile versus 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
– knowledge work projects are often intangible
– Executing a knowledge work project is a complex, creative, and high-risk
endeavor
8
9

9/7/19
5
10
11
• Barry Boehm illustrates the risks of not doing enough up-front
planning like this:
• shows that when little time and effort is invested in planning, the
risk of oversight and delays due to rework is high. More time and
effort is invested into planning, this risk drops away. But people
sometimes miss is that there is a “corollary risk” of doing too
much up front planning

9/7/19
6
• 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; at the same time, we need
to avoid over planning to minimize
the risk of delayed value delivery and a brittle project plan
12
• Midcourse Adjustments are the Norm
– 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
13

9/7/19
7
• 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.
14
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.
15

9/7/19
8
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.
16
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
17

9/7/19
9
535
3
Agile Process Tailoring
Process tailoring involves tailoring the Agile
processes to cater toa situation. It is about
roles and procedures
Examples of project specifictailoring:
Ø Adding or removing work products and tasks
Ø Changing milestones and what work products will
be made available at each milestone, and extent
of completion expected at specific times
Ø Responsibilities for review and approval (RACI
table can be used)
Ø Detailed procedures for reporting progress,
performing measurements, managing
requirements, managing change requests, etc.
[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, traditional approach to project planning. It
covers topics such as:
– Emergent plans and design vs. predictive plans and design
– Preplanning activities to gather consensus on the best
approach to follow
– Backlog refinement (grooming) and how it is performed
– Estimating uncertain work vs. certain work
– The characteristics of new product development vs. well-
understood and repeatable projects
19

9/7/19
10
[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
20
[T&T] Progressive Elaboration
21

9/7/19
11
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
• is what we do to incorporate new information into our
plans as we progress with the project. It Is how we
implement the rolling wave planning approach.
22
[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
23

9/7/19
12
[K&S] Value-Based Decomposition
• Value-based decomposition is a continuation of the process of
value-based analysis
24
[T&T] Time-boxing
Ø 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
Focus
Increased
Productivity
Realization
of time
spent
Time
available

9/7/19
13
Time-boxing
26
Time-boxing
27
• Timeboxes can also serve as powerful tools for completing
focused work
• Pomodoro timers (25-minute timers, often shaped like a
tomato) to help keep themselves focused and on task for a
short period of time
• Agile practices such as timeboxes are designed to minimize the
effects of
– Parkinson’s Law: states that work tends to expand to fill the
time available
– Student Syndrome: people are given a deadline, they tend
to wait until they have nearly reached the deadline before
they start working

9/7/19
14
Estimate Ranges
• In traditional project, we estimated by
– expert-knowledge-based
– parametric (calculation-based)
– analogy
• 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.
28
Estimate Ranges
The diagram below shows
Barry Boehm’s Estimate
Convergence Graph, which
shows how the estimates for
software projects typically
move from a very broad range
early in the life cycle to a more
manageable range once the
scope and specifications are
understood and agreed
upon—and then continue to
narrow as the team learns
more about the project
29

9/7/19
15
Key points in Estimation
• 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.
30
88
[T&T] Ideal Days | Ideal Time
Ø How long something would take if
Ø it’s all you worked on
Ø you had no interruptions
Ø and everything you need is available
Factors Affecting Ideal Time:
• Training
• Email
• Reviews
• Interviewing
• Demonstrations
• Meetings
• Sick
• Time
• Phone
• Bug Fixing
• Management review

9/7/19
16
99
Elapsed Time
Ø Estimating in elapsed days requires us to consider all of the
interruptions that might occur while working on the story
Tools for Sizing and Estimating

9/7/19
17
[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
34
[K&S] Tools for Sizing and Estimating
• Decomposing Requirements
• Requirements Are Decomposed “Just in Time”
35

9/7/19
18
[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.
36
[T&T] User stories
• 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.
- “Given, When, Then” is another user story format that can be
used to document nonfunctional 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.
37

9/7/19
19
[T&T] User stories
• 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 (during iteration
planning). This conversation might be supplemented with documents
– The confirmation
• This refers to the customer s confirmation that the story has been
implemented correctly.
• “Confirmation” means that the product increment passes the
customer’s acceptance tests
38
[T&T] User stories
• The Three C’s
39

9/7/19
20
[T&T] User stories
• INVEST (Characteristics of Effective User Stories)
Software Stories Should
Include All Relevant Architectural Layers
40
[T&T] User Story Backlog (Product Backlog)
41
• This tool helps the stakeholders coordinate the project and
keeps everyone working toward the agreed-upon mission

9/7/19
21
[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 42
[T&T] Relative Sizing and Story Points
43
• People are not very accurate at making absolute estimates, they
are better at (and more comfortable with) 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

9/7/19
22
Estimating Size with Story Points
Ø Story Points are the unit of measurement for expressing the overall
size of a user story, feature, or other piece ofwork.
Ø The number of story points associated with a story represents the
overall size of the story.
Story
Estimates
Collective
Wisdom
EffortComplexity
Uncertainty
Common
Reference
66
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

9/7/19
23
77
Estimate byAnalogy
Ø Comparing a user story to others
• “This story is like that story, so its estimate is what that story’s
estimate was.”
Ø Don’t use a single gold standard
• 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

9/7/19
24
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
consideringthe effort involved in
implementation
• Stories are arranged horizontally
• 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

9/7/19
25
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.
• The product owner discusses the size of thestories 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.

9/7/19
26
The estimates are documented
[T&T] T-Shirt Sizing
54

9/7/19
27
[T&T] T-Shirt Sizing
55
[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
56

9/7/19
28
[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
57
[T&T] Product Roadmap
58
• The topics we've discussed so for—such as affinity estimating, T-
shirt sizing, story maps, and roadmaps— are sizing tools used for
high-level planning

9/7/19
29
Wideband Delphi is a group-based estimation technique in which a
panel of 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:
• The Bandwagon effect è it doesn’t reflect their own opinion
• 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)
• 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

9/7/19
30
161
6
Wideband Delphi – Process
1. Choose the team
2. Kick off meeting
3. Individual preparation
4. Estimation session
5. Assemble tasks
6. Review results
The project manager selects the
estimation team and a moderator.
The team should include
representatives from every group
that will be involved in the
development of the work product
being estimated.
171
7
1. Choose the team
2. Kick off meeting
5. Assemble tasks
6. Review results
The moderator prepares the team
and leads a discussion to brainstorm
assumptions, generate a WBS and
decide on the units of estimation

9/7/19
31
181
8
1. Choose the team
2. Kick off meeting
5. Assemble tasks
6. Review results
After the kick off meeting, each
team member individually generates
the initial estimates for each task in
the WBS, documenting any changes
to the WBS and missing assumptions
191
9
1. Choose the team
2. Kick off meeting
5. Assemble tasks
6. Review results
A series of iterative steps are followed to
gain consensus on the estimates. The
estimates are charted on the
whiteboard to show the range of
estimates. The team resolves issues and
revises estimates without revealing
specific numbers. The cycle repeatsuntil
either no estimator wants to change his
or her estimate, the estimators agree
that the range is acceptable or the
specific time has elapsed.

9/7/19
32
202
0
1. Choose the team
2. Kick off meeting
5. Assemble tasks
6. Review results
Works with the team to collect the
estimates from the team
members at the end of the
meeting and compiles the final
task list, estimates and
assumptions.
212
1
1. Choose the team
2. Kick off meeting
5. Assemble tasks
6. Review results
Reviews the final task list with
the estimation team.

9/7/19
33
121
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 (especiallyoutliers)
6. Re-estimate until estimates converge
[T&T] Planning Poker
131
3
[T&T] Planning Poker

9/7/19
34
Example: Estimation (1)
• User story point:
Each item in product backlog like user story or epic will not be estimated by time
but by point. Point of one user story represents the complexity of this user story
comparing with the other. The key here is relative estimation.
Development team will select the simplest user story and assigned 1? point for it.
Other size of user stories will be estimated relatively with this basic.
Common estimating methods include:
– Numeric sizing (1 through 10)
– T-shirt sizes (XS, S, M, L, XL, XXL, XXXL)
– Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.). à The most familiar way.
• Estimation tips and tricks:
– Estimate as a team
– Playing planning poker
– Dealing with conflicts or non-agreement
during estimation
• Task estimation:
– One User Story can be divided into several
smaller tasks.
– Can be used the same technique of playing
poker or work breakdown structure.
– The unit for task is Hour.
Example: Estimation (2)

9/7/19
35
Estimation (2) - Example
Calculate the team s
total manhour capacity
for the upcoming Sprint
1 5 people x 2 wks x 7
hrs/day: 350.0
Vacation / Absence: - 64.0
20% Buffer (for risk, bugs): - 70.0
Commitment Cap: 216.0
Add the manhour
estimates for all the Sprint
Backlog tasks
2
Compare the 2
numbers to help the team
confirm the commitment
is reasonable
3
213
213 ≈ 216 è J
Estimation (3)
• What is user story point used for?
For development team:
Pt: Team’s Productivity
Vt: Team’s Velocity
ATATh: Actual team allocation time
For product owner:
Sprint/Release/Product planning
Ns: Number of sprint needed for a release
Tp: Total point of release backlog
Vt: Team’s velocity
Team’s capability = Velocity
Prioritized item:
“Cheap but value”

9/7/19
36
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
74

9/7/19
37
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.
75
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
76

9/7/19
38
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.”
77
High-Level Planning (Visioning)
• We are trying to do “just enough” estimating to map
out the overall effort required for the project and get
the work started è using tools such as affinity
estimating, T-shirt sizing, story maps, and the
product roadmap that we will progressively refine as
the project continues
• The participants in the high-level estimating process
are likely to include the product owner and sponsor,
as well as key members of the delivery team, and
possibly other major stakeholders
78

9/7/19
39
High-Level Planning (Visioning)
• Outputs of High-Level Planning
– Before we can move on from high-level planning and start
the release-planning process, the following elements need
to be in place
• An updated, prioritized backlog of user stories and risk
response actions
• High-level(coarse-grained) relative estimates for each
user story
• A release goal (i.e, deliverable) focused on customer
value
• A target date for the release
80
333
3
[T&T] Release Planning
Ø A release plan presents a roadmap of how the team intends to
achieve the product vision within the project objectivesand
constraints identified in the project data sheet.
Ø It helps the product owner and the whole team decide how long it
will take before they have a releasable product.
Ø A release conveys expectations about what is likely to bedeveloped
and in what timeframe.
Ø A release plan serves as a guidepost toward which the project team
can progress.

9/7/19
40
343
4
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
353
5
Release Planning
The purpose of release planning is to define the contents of a release or a
specific shippable product increment.

9/7/19
41
Slicing the Stories
• …
84
[T&T] Iteration Planning
• …
85

9/7/19
42
383
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 toimplement,
i.e., only those user stories, that have been selected for theiteration.
Ø 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.
393
9
Iteration Planning
IterationPlan
Spreadsheet
Post it Note Cards
Iteration Plan Meeting
Product Owner
Analysts
Programmers Testers
Database Engineers
UI Designers

9/7/19
43
404
0
Length of Iterations (%respondents)
82% have iterations between 1 and 4 weeks in length:
414
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

9/7/19
44
363
6
Velocity - Driven IterationPlanning
Ø 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.
Ø 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
373
7
Velocity - An Example with Velocity = 14

9/7/19
45
424
2
Velocity - Driven IterationPlanning
434
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.

9/7/19
46
444
4
Iterations Allow for Mid-CourseCorrections
454
5
Release Plan vs. IterationPlan
Ø 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.

9/7/19
47
[T&T] Daily Stand-Ups
96
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
97
• 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

9/7/19
48
References
• PMI-ACP Exam Prep 2015 By Mike Griffiths, PMI-ACP, PMP
• Many other resources from Internet
98
Thank you for your attention!
99

9/7/19
49
Monitoring Planning
(Review in Delivery Incrementally
in Domain II)
474
7
Release Burn-down Chart
Ø The project team tracks its progress against a release plan by
updating a release burn-down chart at the end of each
Iteration.
Ø The graph shows a
hypothetical burn-down for a
project with 200 story points
delivered in 11 iterations.
Ø The vertical axis shows the
numberof story points
remaining in the project.
Ø Iterations are shown
across the horizontal
axis.

9/7/19
50
484
8
Burn-downChart
494
9
Burn-up Chart
The burn-up chart, in addition to showing how much
work is completed also shows the work in the project
(read scope)
The blue line
shows that scope
has increased
around the 5th
iteration

9/7/19
51
Cumulative Flow Diagrams(CFD)
Ø Red area shows total
planned features to
be built which have
increased from
June to August (as
seen in the graph)
Ø Yellow area shows the
work in progress
Ø Green area shows the
total number of
features completed
515
1
CFD – Little’s Law
Ø Little’s Law states that inventory
in a process is the multiplication
of throughput and the flow-
time.
Ø No. of items in the queue
can be determined by
looking at the vertical
(Y) distance
Ø How long the items will take to
complete can be determined
by examining the horizontal (X)
distance; known as cycle time.

9/7/19
52
CFD with Bottleneck
Ø Note that a widening area is created above an activity that is
progressing at a slower rate.
Ø Bottleneck is the activity below the wideningband.
Here, “Analysis” is going OK, but “DB Process” is below the widening
band, indicating a slower rate of progress, and a warning to us that it is
a bottleneck in the system.

PMI-ACP Domain V: Adaptive Planning v1.0

More Related Content

What's hot (20)

Similar to PMI-ACP Domain V: Adaptive Planning v1.0 (20)

More from PhuocNT (Fresher.VN) (20)

Recently uploaded (20)

PMI-ACP Domain V: Adaptive Planning v1.0