Chp 9.0 pb&e agile+evm (v10.3)

+
9.0 Planning, Budgeting, and
Estimating in Agile
In Agile, Story Points can be used as measures of effort.†
In Earned Value there is no concept of Story Points, rather Dollars
and Hours are the measures of effort and duration for the work.
When using Agile on EVM projects, each unit of measure has value
to the benefits produced through the integration, IF there is a
proper segregation of these concepts.
Estimating on agile development projects is mostly
about planning.
The planning process must itself be agile.
Without agile estimating and planning,the notion of
an agile project makes no sense ‒ Mike Cohn
† https://www.scrumalliance.org/community/spotlight/mike-cohn/october-2014/story-points-are-a-measure-of-effort-period
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 ― 2017 475
476
Without a Plan, you
may arrive at the
wrong destination
without knowing soon
enough to change
your course
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2002 ― 2017
The Product Roadmap and
Release Plan provide the
direction to the destination.
Features and their measures
of Physical Percent Complete
provide measures of
progress to that plan
9. PB&E

9. PB&E
477
The primary purpose of software
project Planning, Budgeting, and
Estimating is not to predict a
project’s outcome. It is to determine
whether a project’s targets are
realistic enough for the project to
be controlled to meet them.†
† adapted from Steve’s original quote for estimating alone
9. PB&E

+ Planning, Budgeting, and
Estimating, in Agile
n 9.1 Planning
n 9.2 Principles of Agile Estimation
n 9.3 Estimating work for the Sprint
n 9.4 Budgeting
n 9.5 PB&E on Kanban
9. PB&E
479
Estimating develops the confidence intervals for possible
outcomes (cost, schedule, deliverables) of the work in the
presence of reducible and irreducible uncertainties.
Estimates provide informed assessments for uncertain
events or statistical processes.
All projects are impacted by these Uncertainties.
9. PB&E

Planning and
Estimating is NOT
Magic.
It’s an skill
requiring
knowledge,
experience, and
practice with
standard
principles,
procedures, and
practices
Estimating is how the impact of decisions are
assessed in the presence of project uncertainty
481
9. PB&E
+
9.1 Planning
n Capabilities Plan ‒ Capabilities are
system-level work that
encompasses many user stories.
n Product Road Map ‒ A product
roadmap describes how
the product grows to aligns with the
stakeholders needs, and to acquire a
budget for the product.
n Release Plan ‒ is a plan for delivering
an increment of product value. It is a
collaborative effort involving Scrum
Masters, Product Owners, delivery
teams, and stakeholders.
n Sprint Planning ‒ is a plan to achieve a
specified level of functionality and
meet additional specific criteria with a
particular Sprint of a system.
Planning is Strategy Making.
Strategy Making is a hypothesis.
Hypotheses require tests to confirm the
project is moving in the desired
direction.
Project planning is an important basis
for cost estimating. An accurate plan will
provide an accurate cost estimate.
Proper planning will reveal tasks,
durations, resources required and other
factors that will be taken into account
during the cost estimation process.
9. PB&E
482

In Preparing for Battle I Have Always Found Plans are
Useless, But Planning is Indispensable
— Field Marshal Helmuth Graf von Moltke
9. PB&E
+ Levels of Planning in Scrum
n Two Levels of Planning
n Strategic Planning ‒ Product Roadmap, Release Plan
n Tactical Planning ‒ Product Backlog, Sprint Backlog
n Requirements elicitation ‒ Needed Capabilities to fulfill the Mission
and Vision of the Project
n Estimating processes ‒ for all resources, facilities, tools, and other
enabling processes.
n Release Planning ‒ when will the Capabilities be available for use to
start delivering Value in exchange for the cost to produce that
Value?
n Sprint Planning ‒ what Stories are needed to produce the Features
that enable the Capabilities to delivered as needed to fulfill the
Mission of the Project?
9. PB&E
484

+ Product versus Project
9. PB&E
485
+ Requirements Elicitation
9. PB&E
486

+ Product Roadmap
9. PB&E
If you don’t know where you are going,you’ll end up
some place else.
487
+
When you’re exploring in new territory, a map keeps you
out of trouble.Without the Map it’s going to get ugly
Purpose of Product Roadmap
9. PB&E
488

+ Levels of Program Planning
9. PB&E
489
Capability
+ Release Planning
n Is the process of creating high level plans that cover periods of
performance longer than Sprints.
n The Release Plan conveys what is likely to be developed by the
teams and over what period of performance this work will take
place.
n The Release Plan is the guide for measuring progress by the team.
n Without a Release Plan, the teams can only move from one Sprint to
the next, without visibility of how the Stories and Features they are
producing fit into the larger picture of how the business’s needed
Capabilities are maturing.
9. PB&E
490

+ Sprint Planning with User Stories
n User Stories highlight negotiation to happen between the customer
and the team.
n User stories help deferring details till later
n Tasks start the process of detailed planning
n User Stories speak to problems not solutions
n User Stories fit nicely into the Product Backlog items
9. PB&E
491
+ Start Estimating with Simple sizing
n Start by segregating the Large
parts from the Small parts.
n Repeat this segregation process,
until all the parts can be sized
with sufficient confidence to
make decisions about the
approximate cost, schedule, and
technical feasibility.
n This can be supported by:
n Reference class forecasting
n Parametric modeling
n Monte Carlo Simulation
492

+ User Stories Detailed in Iterations
during Planning Processes
As a User I want
to Make a Travel
Reservation
As a User I can
reserve a hotel
room
As a User I can
cancel a
reservation
As a Vacation
Planner I can see
photos of hotel
As a User I can
restrict searches
to available rooms
As a premium site
member, I can cancel a
reservation at last minute.
As a non-premium
member, I can cancel up
to 24 hours in advance.
As a site visitor, I am
emailed a confirmation of
any cancelled reservation.
9. PB&E
493
Top Level First Level Detail Second Level Detail
+ Attributes of a Good User Story
INVEST
Independent
Negotiable
Valuable
Estimable
Small
Teastable
9. PB&E
494

+ The User Story
495
9. PB&E
n As a <type of user>, I want <some goal> so that
<some reason>
n As a Government Technical Software Manager I want
to Properly Estimate the Features in the CONOPS so
that I have a Credible Baseline
n As a Government Technical Software Manager I want
assure that Features in ConOps can be delivered
within Cost and Schedule so that we’re delivering
capability according to plan
Before Contract Award
After Contract Award
+
Sprint Plans
Release Plans
Release and Sprint Planning†
† Agile Estimating and Planning, Mike Cohn, Pearson Education, 2006
Conditions of
Satisfaction
(Stories, Budget,
Schedule)
Release Planning
Conditions of
Satisfaction
(Stories, Budget,
Schedule)
Sprint Planning Development
Stories
Completed
9. PB&E
496

+ Definition of Ready†
n Business value is clearly articulated in units of measure meaningful
to the decision makers.
n Details are sufficiently understood by the team so it can make an
informed decision if it can complete the Product Backlog Item (PBI).
n Dependencies are identified and no external dependencies will
block the PBI from being completed.
n Team staffed appropriately to complete the PBI.
n PBI estimated and small enough to be completed in one sprint.
n Acceptance criteria are clear and testable.
n Performance criteria, if any, are defined and testable.
n Team understands how to demonstrate the PBI at the sprint review.
497
† Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth Rubin, Addison-Wesley
9. PB&E
Planning Must Be Credible For Business Value To Be Delivered As
Needed. No Guessing. Statistically Sound Estimates Required.

+
9.2 Principles of
Agile Estimation
Estimating takes place in the
presence of two types of
uncertainty
n Reducible Uncertainty (Epistemic) ‒
the event based (probability of
occurrence) outcomes that have
unfavorable impacts on the work.
n Irreducibility Uncertainty (Aleatory)
– the naturally occurring variances in
the work processes, technologies, and
outcomes.
Estimating in the presence of these
uncertainties, requires identifying the
characteristics of both uncertainty classes
‒ probability distributions and underlying
statistical processes and assessing the
risks they create to cost, schedule, and
technical performance.
The primary purpose of software
estimation is not to predict a project’s
outcome; it is to determine whether a
project’s targets are realistic enough
to allow the project to be controlled
‒ Steve McConnell
9. PB&E
499
+
Estimating is about unraveling the interconnections between Cost, Schedule, Risk,
and Technical Performance to produce credible confidence intervals of how long,
how much, and what, will be produced from the project as it proceeds to produces
business value in exchange for the project’s funding.
Then using these estimates in a Closed Loop control system to increase the
Probability of Project Success
Estimating is Not About Guessing
9. PB&E
500

+ Why We Needed Estimates 501
Creating reliable cost, schedule, and technical
performance estimates is a critical success factor
for all business projects.
Without these estimates, business value is at risk of
experiencing cost overruns, missed deadlines, and
performance shortfalls—all recurring problems that
projects assessments too often reveal.
As well, cost increases often mean that the
business cannot fund needed projects or deliver
them when promised.
www.gao.gov/new.items/d093sp.pdf
9. PB&E
+ Basic Characteristics of Credible
Estimates
502
Characteristic Description
Identification of needed
capabilities.
A description of needed capabilities, ground rules and
assumptions, and technical and performance
characteristics.
Broad participation in
preparing estimates.
All stakeholders involved in confirming mission need,
requirements, system parameters, and other
characteristics.
Availability of valid data.
Sources of suitable, relevant, and available data directly
related to the system’s performance characteristics.
Standardized structure
for the estimate.
Standard work decomposition ensures no portion of the
estimate are omitted ‒ all in work.
Provision for project
uncertainties.
Uncertainties identified and allowance developed to cover
the cost. Known costs included. Unknown costs allowed for.
Independent review of
estimates.
Independent review of an estimate crucial to establishing
confidence in the estimate.
Revision of estimates for
significant changes.
Estimates updated to reflect changes in a system’s
requirements.
9. PB&E

+ Problems with Estimating on Agile
Programs
Problem Solution
It’s hard to know exactly how long a task
will take.
All project work contains uncertainty.
Probabilistic models are starting point for
credible estimates.
People are not very good at estimating.
Standard techniques applied ‒ Wide Band
Delphi is standard Agile process.
Reference class, and parametrics.
Sometimes we get interrupted and it takes
longer than expected.
Margin required for all project work.
Sometimes we find unexpected problems.
Risk management is adults manage projects
– Tim Lister
Planning by the hour or day is the wrong
incentive.
Plan for deliverables with capacity for
work estimates
Activities are interdependent.
Product Roadmap and Release Plan reveal
interdependencies needed to show
delays.
9. PB&E
503
+ Why Estimate on Agile Programs?
n All project work is random, even on fixed periods of performance, with
fixed resources, and fixed scope.
n What are the irreducible uncertainties for each work activity that will
unfavorably impact the probability of success when they come true?
n Estimates for Cost and Effort of each Release and Sprint
n It is essential to know the cost and effort of the release before the project
committed to the Customer.
n Estimates of Demand and Capacity Management.
n Demand management and capacity planning is a critical success factor for all
projects. Agile projects are no different.
n Estimating the Cost of the Minimal Marketable Features is needed
before committing to their development.
n Without knowing this cost to some level of confidence jeopardizes the
production of the needed value of the deliverable
9. PB&E
504

+ Let’s Pause for a Cardinal and Ordinal
Interlude to Address the Estimating Problem
n When we use a measure of something we
need to know if it is Cardinal or Ordinal.
n Ordinal measures tell us the relative
difference between items.
n Uncle Scrooge is relatively rich compared to
Huey, Dewey, and Louie is an Ordinal
measure.
n Cardinal measures are numbers that say how many of something there
are, such as one, two, three, four, five.
n Uncle Scrooge has $1,250,000,000 dollars of Gold
n In Project Performance Management we use Cardinal numbers,
measured in Dollars, Hours,Technical Performance compliance.
n Story Points are NOT a unit of measure used in Project Performance
Management.
9. PB&E
505
+ Arithmetic on Cardinal and
Ordinal Numbers
When hear about adding Story Points, caution is needed
n An Ordinal number ‒ a Story Points ‒ denote the position of an element in
an ordered sequence
n Ordinality involves sets and order relations on those sets.
n Cardinal numbers ‒ natural numbers ‒ measure the size or Cardinality of
sets.The possible collection of values describing an entity – the cost, the
duration, the performance or effective measures
n There is a cardinal number for every possible cardinality.
n A cardinal number is a family consisting of all sets that can be put into
one-to-one correspondence with each other.
506
9. PB&E

+ WhyYou Can’t Add Ordinal Values
(Story Points) in Number Theory
507
Recall the definition α + β = sup { α + γ | γ < β } when β is a limit ordinal.
Means that:
1 + ω = sup { 1 + n | n < ω } = sup { n | n < ω } = ω
On the other hand, ω + 1=(ω + 0)ʹ = ω + 1 ≠ ω because α≠αʹ for all α.
This is because α αʹ therefore these sets are distinct.
Therefore the ordinals are not order isomorphic either (because every well-
ordered set is isomorphic to a unique ordinal).
What this means in English
It means adding or doing any kind of arithmetic on Story Points (Ordinal
Numbers) is a category error.
This error occurs when we ascribe properties to a thing that can’t possibly have
that property.
9. PB&E
For example
Your breath smells like a funny color
or
The number 9 is slippery
+
n Story Points are Ordinal numbers ‒ relative measures of effort or
complexity defined by the Scrum Team members for a specific
Sprint, Feature, and perhaps a Release
n Story Points are not scope, they not are they calibrated to Time and
Money outside an individual Scrum Team.
n Counting Story Points is like counting Tasks in the IMS
n We have 40 tasks to do for this delivery which is 9 weeks long (3, 3 week
Sprints).
n We’ve done 20 Tasks so far
n Are we 50% complete for the planned task work?
n Not likely unless each Task is of the same effort and duration.
… Outside a single Scrum Team, which calibrates Story
Points to their own usage and need …
Stories and Story Points are not
Units of Performance …
508
9. PB&E

+
n In this release we have 12 Stories to implement the Feature
n We’ve completed 6 or the 12 Stories.
n Are we 50% complete with the Feature?
n Not likely, unless each Story is of equal effort and duration and each
story has identical irreducible and reducible uncertainty that impacts
cost and duration
Stories are sized with Ordinal measures as well. So those
measures are localized ordinal values as well
Counting Stories has the same
issue, since …
509
9. PB&E
+ Ordinal Story Points cannot be basis of PV
higher than a single Feature developed by a
single team
Feature 1
Story 1
Story 2
Story 3
Story 4
Story 5
Story 6
Team 1’s
Uncalibrated
Ordinal SP
estimates
Feature n
Team 2’s
Uncalibrated
Ordinal SP
estimates
∑ F1(SP) ∑ Fn(SP)
Release 1 ∑ of SP’s
• • •
§ At the Story level,
relative effort defines
individual estimates.
§ At the Feature level,
lower level SP’s don’t
have the same unit of
measure in the way
Dollars do.
§ When Features
summed to the
Release, relative
measures do not
provide basis of
Physical Percent
Complete.
Not same units of measure between
Features – Uncalibrated SP’s
9. PB&E
510
Story 1
Story 2
Story 3
Story 4
Story 5
Story 6• • •

+ A Caution for using Story Points to Measure
Progress Beyond a Single Feature
Ordinal
numbers only
have meaning
for their current
use ‒ unless
calibrated to a
baseline that
does not
change over
time
511
9. PB&E
+
n Story Points used for relative assessment in prioritizing work in the Product
Backlog ‒ Ordinal numbers
EIA-748-C, page 1 bullet 5 says …
Objectively assess accomplishments at the work performance level – Tasks in the
Sprint.
EV Calculated by Physical Percent
Complete
512
9. PB&E
n Hours used to define actual effort and
duration during Story Time,Tasking, and
Sprint Execution ‒ Cardinal numbers
n Mixing the Story Points with Hours is
fine when prioritizing the work in
Product Backlog and Sprint Backlog
n Measuring progress to plan needs to be with Cardinal values meaningful to
the decision makers.
n The IPMR (DI-MGMT-81861) has no units of measure in Stories or Story Points
n Measures of Physical Percent Complete must used Cardinal Values as well

+ During Execution, Hours Used to
Measure Physical Percent Complete
513
Original
Engineering
Estimate
Estimate of User
Stories in Sprint
Remaining Work
for Story
0 Remaining Means
Story Done
10 of 10 Remaining
Means Story Not Stated
Sprint 1 100% Complete
After Sprint 1 Feature 42%
Complete, with 60 Hrs remains
Sprint 2 50% Complete
At this point in Sprint 2, Features
44% Complete
9. PB&E
+
n If a Story was estimated to be 6 Story Points, how would we measure
progress to plan during the Sprint?
n Can we accumulate incremental Story Points?
n Can we be 50% complete if we have accumulated 3 SPs out of the 6?
n If we use hours ‒ as shown above ‒ we can measure progress in the
same way EVM does with 0/100 at the Task level.
n This is then rolled to the Story level as Physical Percent Complete from the
Tasks
n How do we assess progress at Month End when the Sprint crosses that
Month End boundary?
Using the spreadsheet in the previous chart, what would be the
measure of Physical Percent Complete using Story Points or Stories?
Story Points as Physical Percent
Complete?
514
9. PB&E

+ Estimating is always possible, accuracy
and precision vary depending on
project phase†
† “Sizing Matters,” QSM Blog, http://www.qsm.com/articles/sizing-matters
9. PB&E
515
+ The Cone of Uncertainty
n The Cone of Uncertainty is a term often used in project management to
describe the phenomenon of how project unknowns decrease over time.
n As the project proceeds and more research and development is completed
the amount of uncertainty decreases, approaching zero.
n Project unknowns, or uncertainty, largely correlate to variances in project
estimates.
n Plotting these variances over time creates a cone or funnel shape.
n The amount of variance (estimated versus actuals) occurring at different
phases of the project can be estimated based on historical project data .
n Starting with an estimate reflecting the Most Likely outcome, historical
variation is used to determine the type of multipliers that should be applied
to create a high to low estimate range.
516
If estimates for cost, schedule, and technical performance of the product or
service is not reducing as the project moves left to right, you’re not properly
managing the project. Find out why and fix that before it’s too late to take
corrective action to Get Back to Green.
9. PB&E

+ Estimating is Required on all Programs
in the presence of Uncertainty
n EVM estimating
n Basis of Estimate (BOE) at Proposal flowed to PMB then to Control
Accounts and Work Packages.
n Hours and Dollars are Cardinal units of measure for all EVM activities
n EVM Estimating connects Bottom Up and Top Down confirming the
proposal’s Basis of Estimate.
n Agile estimating
n Story Points for Backlog work flowed from Work Packages delivering
Features to Sprints and Tasks.
n Story Points are Ordinal units of measure creating relative effort measures
mapped back to PV assigned to the Feature in the Work Package.
n Agile Estimating is Bottom Up in the Story Point Assignment processes.
The Story Point is a relative measurement of how difficult a task is.
This is because humans are actually better at relative estimates than
precise measurements. But the Story Point is NOT Scope
9. PB&E
517
+ Two Very Different Meanings of the
Word Estimation†
n Sprint level: Decide which stories to commit to. Defining the story
details for the next sprint (which is a fixed length).
n Often referred to as “agile estimation” in the literature
n Product Release level: Estimate the time and cost of a project to
develop software that meets chosen business goals
n Help decide what projects to do.
n In some cases, estimating how much functionality can be developed to meet a
fixed deadline.
n Purpose of each Sprint is to get feedback to take course corrections
n Stories are broken down into “developer sized bites” that fit into the sprint.
Not all of a higher-level function must be completed
n Not all the functionality needed to consume and use the software is ready at
each sprint.“Highest priority that fits” is not enough for production use
n Only over multiple Sprints will the functionality be enough to serve a
business purpose for the users –You can’t arbitrarily decide on a time
box for that!
† Agile Estimation: Beyond the Myths Part 2 Andy Berner Quantitative Software Management, Inc.
9. PB&E
518

+ Classic Agile Estimating Starts
with Fibonacci Sequences
519
1 , 1 , 2 , 3 , 5 , 8 , 13 , 21 , 34 , 55 , 89
9. PB&E
+
9.3 Estimating Work
for the Sprint
n Capacity Base Planning – the team
performing the work determines what
their capacity for work is by examining
the Stories assigned to the Sprint from
the Product Backlog
n Velocity Based Planning – the team
uses their past performance in Stories
points to assess what Stories to pull
from the Product Backlog for the next
Sprint.
n This historical data is used to forecast
future work performance.
n In eXtreme Programming this is
called Yesterday’sWeather.
There are two primary ways to
Estimate work at the Sprint Level
9. PB&E
520

Story Points are NOT Scope
https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity
9. PB&E
In Agile, point-
based estimating
is about the
Relative effort the
work will take
+ Story Points …
n Are measures of Relative work effort – not duration or actual cost.
n Story Points are NOT a measures of the cost of scope.
n Story Points are Ordinal units of measure – relative measures
n Hours are measures of effort as well.
n Hours also are a measure of Scope:
n From the SOW, each deliverable is assigned a budget PV starting at the
proposal BOE’s.
n From the labor rate, that PV can be converted to Hours of effort as well as
material costs.
n PV are Cardinal units of measure – absolute measures, uniformly
applicable across the program – Dead Presidents.
Agile + Engineering Practices: Experiences of Three Microsoft Teams, Laurie Williams North Carolina University, Gabe Brown,
Adam Meltzer, Nachiappan Nagappan, Microsoft Corporation
9. PB&E
522

+ Story Points …
n Are arbitrary measures used by Agile teams to determine the
Relative (Ordinal) effort or complexity of the work.
n Tells the team how hard a Story is, from it’s perceive complexity,
risk, and unknowns.
Agile + Engineering Practices: Experiences of Three Microsoft Teams, Laurie Williams North Carolina University, Gabe Brown, Adam Meltzer,
Nachiappan Nagappan, Microsoft Corporation,
n All these Relative (Ordinal) measures are the antithesis of Earned
Value Management measures of work planning and
accomplishments, which are in Hours for the direct labor needed to
produce the outcome (assuming no material cost).
9. PB&E
523
+ Story Points Don’t …
n Tell us the duration or cost of this relative effort.
n Tell us the absolute effort to performance the work
n Aren’t normalized across work efforts, across teams, or across the
program
n Story Points are developed through Planning Games or Planning Poker
for the work in hand
n Story Point effort estimates are not Calibrated across the program, but
rather are developed for the work at hand
n The calibrated units of measure for Story Points – can and will change –
change as the program progresses.
Agile + Engineering Practices: Experiences of Three Microsoft Teams, Laurie Williams North Carolina University, Gabe Brown, Adam
Meltzer, Nachiappan Nagappan, Microsoft Corporation
n Hour and Dollar estimates will change as the program progresses
as well, but the unit of measure representing this estimate does not.
9. PB&E
524

+ The Killer Issue with Story Points
n What is a Story Point Worth in Dollars in the IPMR per DID–81861?
n What is a Story Point Worth in Hours of duration in the IMS?
n Can we Calibrate Story Points across the entire program? That is,
are Story Points a constant representation of Effort across all
planned Tasks,Work Packages, and Control Accounts?
n The Killer issue with Story Points is they are a relative measure of
effort, not absolute measure of effort.
n Performing schedule analysis, Estimate to Complete, Estimate At
Completion, variance analysis, margin erosion, and other time and
cost assessment is not possible in Story Points
9. PB&E
525
+ How Ordinal Story Points at the Feature
Level can be Turned into P%C
n Story Points are assigned to Stories contained in a Feature by a
unified team of Agile Estimators.
n The assigned SP’s can then meet the PV flowed down from the Work
Package for that Feature.
n This connection can then be used to status the feature as Physical
Percent Complete, and convert that P%C into EV.
n But those Story Points can’t be extended across Features, UNLESS
those developing the Story Point estimate use the same basis of
estimate:
n Story Points are relative measures of effort.
n If different teams assign Story Points, its like they will have a different
calibration paradigm for that effort.
9. PB&E
526

+ Rolling Up Agile Story Points
across the Program is Bad Idea
n Agile teams rarely produce comparable calibrated Story Points for dissimilar or
even similar work.
n This is a key difference between EVM and Agile. Most EVM shops have an
external Basis of Estimate process to calibrate the cost and duration of planned
work
n Agile teams working on different parts of the project, with different assessments
of Effort, different Story point values, and different project costs result in
dissimilar units of measure for a Story Point.
n When Agile teams have different approaches to applying Story Points, Earned
Value can still be calculated for each team, and rolled up to the Total Story Point
count for the project for an individual Feature Physical Percent Complete.
n The program level PV flowed down from the CBB to the Control Accounts and
Work Packages can then be connected with the Total Story Point count built
bottom up from the Agile Planning process.
n From there, all EVM calculations remain the same, with the caveat that the Actual
Cost needs to be the actual cost across teams to calculate a total CPI across a
program.
9. PB&E
527
+ When to Assign Story Points
n The PMB’s WBS defines the Program Level Control Accounts with PV,
flowed to the Work Packages just like it shows in the NDIA Gold
Card.
n Story Points are used to estimate the relative effort of the work at the
Task level, rolled to the Story, and then to the Sprint.
n Dollars and Hours are used to estimate the effort and duration of the
work at the Work Package level, rolled to the Control Account.
n Story Points need to be assigned early in the program planning, in
the same way PV is.
n Putting Story Points on product Backlog during sprint planning is
too late.
n The PV and Story Point estimates Meet at the Bright Line between
the PMB and the Agile Backlog, Sprint, and Release plan
https://www.mountaingoatsoftware.com/blog/assigning–story–points–at–the–right–time–or–not–at–all
9. PB&E
528

Estimating ‒ in Story Points, Hours, or any units of measure ‒ is Not a
process of chance. It is the process of determining the range of a value of
interest with a desired precision and accuracy needed to make a credible
decision about an outcome in the future, associated with that value.
9. PB&E
+ Capacity Based Sprint Planning (1)†
n The Product Owner brings the top-priority Product Backlog items
into the meeting and describes them to the team, usually starting
with an overview of the set of high-priority items.
n Team members select a first item to bring into the sprint ‒ which is
almost always the Product Owner’s top-priority item, but it is
possible that the Product Owner’s top priority has too many open
issues.
n After selected a high-priority item, team members discuss the work
involved, and identify the tasks necessary to deliver the Product
Backlog item.
n Either concurrent with identifying the tasks or immediately after
they finish doing so, team members roughly estimate the number of
hours each task will take.
9. PB&E
530

+ Capacity Based Sprint Planning (2)†
n After identifying the tasks and the roughly estimated hours for that
one Product Backlog item, the team members ask,“Can we commit
to this?”
n Repeat this process with more Stories from the Product Backlog,
until the answer to the question “Can we commit to this?” is NO.
n There has been no role for Story Points or velocity in this
commitment process. Either the Story can be committed to be done
in this Sprint or it can’t ‒ the team decides.
It’s an Estimate, Not a Guarantee
“If you want a guarantee, buy a toaster.”
‒ Clint Eastwood
9. PB&E
531
+ Velocity Based Sprint Planning (1)†
n Velocity sprint planning is based on the premise that the amount of
work a team will do in the coming sprint is roughly equal to what
they’ve done in prior sprints.
n This does assume, of course, things such as a constant team size, the
team is working on similar work from sprint to sprint, consistent
sprint lengths.
9. PB&E
532

+ Velocity Based Sprint Planning (2)†
n Steps in Velocity Based Sprint Planning
1. Determine the team’s historical average velocity.
2. Select a number of Product Backlog items equal to that velocity.
Some teams stop there. Others include the additional step of:
3. Identify the tasks involved in the selected user stories and see if it feels
like the right amount of work.
And some teams will go even further and:
4. Estimate the tasks and see if the sum of the work is in line with past
sprints.
† Velocity-Driven Sprint Planning, Mountain Goat Software
9. PB&E
533
All Estimates Must Be Done As a Agile Team
No Flow Down from the Top
9. PB&E

+
9.4 Budgeting
n Stable Agile teams
n Time Boxed Work Periods of
Performance
n Fixed and Reliable sprint burn rates
n Blended Rates
n Using Specific Labor categories
n Peanut Butter Spreads for future work
With the Product Roadmap, the
Staffing Plan, a budget can be
developed.
This is the planned cost for the
development of the Value delivered
by the Project.
This is the Target cost, not the Actual
cost. But this target cost is the
steering point for the Closed Loop
control system needed to manage the
project to success.
9. PB&E
535
+ Budgeting Starts With The Business
Case
n Ongoing Funding
n Product Roadmap Funding
n Incremental funding
n Management reserve
n Contingency funding
9. PB&E
536

+
9.5 PB&E on Kanban
9. PB&E
537
Time is the one thing you cannot get more of on projects
Without Margin, any
project is late on the
day it starts.
In Agile, just as in
traditional projects,
when there is a
minimal set of
Capabilities to be
produced at a
needed time to meet
the business case or
fulfill a mission ‒
Schedule Margin Is
Mandatory
9. PB&E

+ Planning, Budgeting,
and Estimating
539
9. PB&E

Chp 9.0 pb&e agile+evm (v10.3)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Chp 9.0 pb&e agile+evm (v10.3)

Similar to Chp 9.0 pb&e agile+evm (v10.3) (20)

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

Chp 9.0 pb&e agile+evm (v10.3)