Evm+agile (8.8).chapter 9

+
Integrating Agile Software Development (Agile) on
EarnedValue Management Programs
Starting with an EIA–748–C compliant Earned Value Management System,integrating an Agile Software
Development Lifecycle (Agile) is straight forward when there is a Bright Line between the
Performance Measurement Baseline (PMB) and the Sprints andTasks of the Agile Software
Development Process.
AGILE AT SCALE
for
FAR 34.2 / DFARS 234.2
Acquisition Programs
V8.8
1
Performance–Based Project Management®
, Copyright© Glen B. Alleman, 2002 - 2016

+
is a registered trademark of Niwot Ridge, L.L.C.
Performance–Based Project Management ® ISBN 978–0–8144–3331–7
is a publication of American Management Association,
Copyright © 2014
CMMI® is a Registered Trademark of Carnegie Mellon University,
Pittsburg, PA
All material in this document is Copyright © 2002 - 2016
Glen B. Alleman, Niwot Ridge L.L.C.
This publication may not be reproduced, stored on a retrieval system, or
transmitted in whole or in part, in any form or by any means, electronic,
mechanical, photocopying, recording, or otherwise, without prior
written permission from Niwot Ridge L.L.C.
Send requests for reuse to glen.alleman@niwotridge.com
2

+
Table of Contents
§ Content Page
1 Introduction 6
2 Opening Background 52
3 Start With The End in Mind 133
4 Framing Assumptions 146
5 Foundations of Earned Value and Agile 187
6 Performance Planning and Measurement 214
7 Connecting the Dots Between Agile and EVM 253
8 The Requirements Elicitation Problem 298
9 Planning, Estimating,and Budgeting 314
10 Building the PMB for an Agile Project 346
11 Dependency Management in Agile 374
12 Risk Management on Agile Programs 380
13 Change Control in Agile and EVM 417
14 Physically Connecting the Dots 474
15 The Dark Side and EVM and Agile 484
16 Failure Modes of Agile + Earned Value Management 502
17 Maturity Models for Agile and Earned Value Management 554
18 Root Cause Analysis 518
19 Agile Contracts 645
20 Conclusion 646
21 Resources 665
3

+
Earned Value provides EAC and ETC for large software intensive systems.
Agile provides mechanisms for emergent software development
Why Agile + Earned Value
Management?
4
Navigation
Communications
Fire Control
Engine Controls
Counter Measures
Visualization
Flight Controls

+
9. Planning, Estimating and
Budgeting in Agile
In Agile, Story Points are 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 is a Critical Success Factor for
Increasing the Probability of Program Success
315Performance–Based Project Management®

Estimatingdevelops the confidence intervals for possible
outcomes (cost,schedule,deliverables) of the work in the
presence of reducible and irreducible uncertainties.
Estimatingprovides informedassessments of uncertain events
or statistical processes.All projects are impactedby these
Uncertainties
9. PB&E

+
Planning
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 Epic Plan ‒ Epics are feature-level work
that encompasses many user stories.
Epics are almost always delivered over
a set of sprints.
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.
317
9. PB&E

In Preparing for Battle I Have Always Found
Plans are Useless, But Planning is
Indispensable
9. PB&E
318

+
Product Roadmap
319
9. PB&E

+
Epic Planning
320
9. PB&E

+
Release Planning
321
9. PB&E

+
Sprint Planning
322
9. PB&E

+
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
323

+
Principles of Agile
Estimation
n Reducible Uncertainty ‒ the event
based (probability of occurrence)
outcomes that have unfavorable
impacts on the work
n Irreducibility Uncertainty – the
naturally occurring variances in the
work processes, technologies,and
outcomes
n Estimating in the presence of
uncertainty ‒ requires identifying both
reducible and irreducible uncertainties
and assessing the risks they create
For all projects, no matter if they are
Agile or Traditional,estimates are
critically important.
Estimates are needed to make
decisions in the presence of the
uncertainties encountered by the
project participants and management
324
9. PB&E

+
Estimating about unraveling the interconnections between Cost,
Schedule, Risk, and Technical Performance to produce a credible
estimate of how long, how much, and what will be produced from
the project. Then use these estimates in a Close Loop control
system to increase the Probability of Success
Estimating is Not About Guessing
325

+
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
326

+ 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 is a number that says 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 Earned Value Management we use Cardinal numbers, measured in
Dollars and maybe Hours.
n Story Points are not a unit of measure used in Earned Value
Management.
9. PB&E
327

+ 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 BCWS 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
328

+ Two Very Different Meanings of the
Word Estimation†
n Sprint level: Decide which stories to commit to defining in detail and
developing in the next sprint (which is a fixed length).
n Often referred to as “agile estimation” in the literature
n Project 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 do course corrections and learn
n Stories were 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
329

+
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’s Weather
There are two primary ways to
Estimate work at the Sprint Level
9. PB&E

+
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 either.
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 BCWS starting at
the proposal BOE’s.
n From the labor rate,that BCWS can be converted to Hours of effort as well
as material costs.
n BCWS are Cardinal units of measure – absolute measures, uniformly
applicable across the program – Dead Presidents.
Agile + EngineeringPractices:Experiences ofThree Microsoft Teams, Laurie WilliamsNorth CarolinaUniversity, Gabe Brown,
Adam Meltzer, Nachiappan Nagappan, MicrosoftCorporation
9. PB&E
331

+
Story Points …
n Are arbitrary measures used by Agile teams to determine the
Relative (Ordinal) effort of the work.
n Tell the team how hard a Story is, from it’s perceive complexity, risk,
unknowns – each related to effort.
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
332

+
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
333

+
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
334

+ 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 BCWS 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 BCWP.
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
335

+ 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 BCWS 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
336

+ Ordinal Story Point cannot be basis
of BCWS higher than a Feature
Feature 1
Story
Story
Story
Story
Story
Story
Team 1’s
Uncalibrated
Ordinal SP
estimates
Feature n
Story
Story
Story
Story
Story
Story
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
337

+
When to Assign Story Points
n The PMB’s WBS defines the Program Level Control Accounts with BCWS,
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 BCWS is.
n Putting Story Points on product Backlog during sprint planning is too
late.
n The BCWS 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
338

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 out 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
340

+
Capacity Based Sprint Planning (2)†
n After identifying the tasks and roughly estimated the 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 a Commitment,Not a Guarantee
“If you want a guarantee,buy a
toaster.”
‒ Clint Eastwood
9. PB&E
341

+
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
342

+
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
343

All Estimates Must Be Done As a Agile Team
No Flow Down from the Top
9. PB&E

+
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
345
9. PB&E

+ Budgeting Starts With The Business
Case
n Ongoing Funding
n Product Roadmap Funding
346

Evm+agile (8.8).chapter 9

More Related Content

What's hot

Viewers also liked

Similar to Evm+agile (8.8).chapter 9

More from Glen Alleman

Recently uploaded

Evm+agile (8.8).chapter 9