Physical Percent Complete is a primary measure of progress to plan for all project work. For Agile projects, this is a critical success factor. Here's how

1. PS-03
Calculating Physical Percent Complete for the PMB
Using an Agile Tool
Glen B. Alleman
galleman@primepm.net
303 241 9633
EVM World 2017
New Orleans, LA
1

2. Learning Objectives
§ Show how measuring Physical Percent Complete for produced
software is THE critical success factor for integrating Earned
Value Management with Agile sofwtare development.
§ Show how to define Physical Percent Complete to calculate
BCWP (EV) from progress to plan at the Sprint level.
§ Show why using Story Points do not provide measures of physical
percent complete beyond a single Scrum team in a limited time
window.
The object is to seamlessly connect agile software development with Earned
Value Management

3. 1. What Does DONE Look
Like?
2. How Do We Get to DONE?
3. Is There Enough Time,
Money, and Resources, To
Get to DONE?
4. What Impediments Will Be
Encountered Along The
Way to DONE?
5. What Are The Units Of
Measures For Progress To
Plan for each Deliverable?
All Successful Projects Require Credible
Answers To These 5 Questions …
3 Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017

4. 4
The question asked of every parent and
every software development project is …
Are We There Yet?

5. Looking for Simple Solutions to Questions?
They’re Aren’t Any …
The $20M Question ‒ How can we seamlessly integrate Agile with Earned Value Management?
The answer is to calculate BCWP in the PMB using BCWS at the Sprint level as
BCWP = BCWS × Physical Percent Complete

6. What’s the Motivation to Integrate Agile and EVM?
This integration provides credible EAC and ETC for large
Software Intensive System of Systems (SISoS) needed to
manage in the Fog of Emergence.
Navigation
Communications
Fire Control
Engine Controls
Counter Measures
Visualization
Flight Controls
Life Support
Delivering Business Value is a Critical Success Factor.
Knowing the cost to deliver that Value and the Date that Value will arrive is
equally critical.

7. 1. What Does DONE Look Like?
2. How Do We Get to DONE?
3. Is There Enough Time,
Resources, And Money To Get
to DONE?
4. What Impediments Will Be
Encountered Along The Way
to DONE?
5. What Are The Units Of
Measure For Assessing
Progress Toward Done for
each Deliverable?
Let’s start with Immutable Principles of
Project Success with Five Easy Questions …
Performance-Based Project Management®, Copyright © Glen B. Alleman, 2017, All Rights Reserved
QUESTIONS

8. We are successfully applying the Five Immutable Principals of
Project Success to Agile Programs if we …
1
… have a defined Mission, Vision, Capabilities, and High Level
Technical and Operational Requirements ‒ by which to create …
2
… a Product Roadmap for delivering these Capabilities and
connecting the Requirements and Release Plan for producing the
needed outcomes to meet this Roadmap ‒ and have …
3
… allocated enough Time, Money, and Resources to increase the
probability of the project’s success ‒ and we …
4
… know what Risks are in front of us and their plans for retirement
or handling ‒ and we can …
5
… confirm progress to plan with measures of Physical Percent
Complete for each Deliverable in the Release Plan with confidence of
“on or before the planned time and “at or below” the planned cost. 6Performance-Based Project Management®, Copyright © Glen B. Alleman, 2017, All Rights Reserved

9. One Notion Before We Continue
§ For Earned Value Management to be appliable, the program is
Large compared to the typical software development project
§ $20M for self-assessment (SA)
§ $100M for DCMA Validation (VR)
§ For the typical Agile development effort, a small team of 5 to 7
developers ‒ at typical burden rates ‒ runs $600K to $800K a
year for the team.
§ The typical agile project is 30 times smaller then the starting
point of an EVMS IAW 748-C.
§ So Agile + Earned Value Management starts at the Enterprise and
At Scale environment. In this domain, process compliance is king.

10. The Framework for Agile Performance
Management using Earned Value
Cadence Release 1 Cadence Release n
Feature 1, 2, 3
Feature 4, .. ,8
Feature 9, …,12
Release 2 PP’s
WP
PP
SLPP
in IMS
CA
Sprints
Time Now
Performance Measurement Baseline
Agile Software Development Lifecycle
Feature n’s
The Bright Line
Milestones
Data Items
Releases
Capabilities in a Release
Agile Development Control Account
Task
Task
Task
Task
Task
Task
Task
Task
Task
…
Starting with a Product Roadmap and Cadence Releases, Earned Value Management + Agile
Integration is straight forward when progress to plan is measured as Physical Percent Complete
BCWS (PV) is the labor
spread at the Sprint level
contained in the Work
Packages.
BCWP (EV) = BCWS ×
Physical Percent Complete
of Features produced by
Sprints.
Physical Percent
Complete from Planned
Stories that implement
the Features in each
Sprint.
In this paradigm, BCWS held in the IMS, is flat spread across the Sprints from
the FTE assigned to the Features in the Work Packages.

11. 10 Steps to an Integrated Agile and Earned Value
Management System Using Physical Percent Complete
Each step provides information needed to plan, execute, assess and correct
performance of an Agile Development project using Earned Value Management
Capabilities Defined
in Product Roadmap
Release Plan Defines Work
Packages assigned to
Sprints
Work Packages Contain
Features in Sprint
Measure Physical
Percent Complete for
Each Feature
Perform Work IAW
Roadmap and Backlog
Earned Value Defines
Progress
Adjust EV for Technical
Performance
Measure
Use Past Performance to
Forecast Future
Performance
1
2
3
5
6 7
8
9
10
IMS Describes
Work Sequence of
Features in Roadmap
4
9
Assess the capabilities being provided through the delivered Features
Fulfill the requirements through effort held in the Work Packages
Produce deliverables from
Work Packages
Planned BCWS
Physical % Complete
WP’s produce deliverables
that fulfill requirements
Capabilities
topology defines
requirements flow
down
WP flow must describe the
increasing maturity of the
product or service
Producing the deliverables in the planned
sequence maintains the value stream to
the customer
Performance–Based Project Management®, Copyright © Glen B. Alleman, 2012 - 2017

12. 10 Steps to an Integrated Agile and Earned Value
Management System Using Physical Percent Complete
Principles to Integrate Agile with EVM in Order of Increasing Maturity
1 Capabilities drive system requirements. All requirements must be traceable to a capability.
Requirements identify technical and process deliverables. All deliverables must be traceable to a
requirement.
Work Packages describe the work to produce the deliverables.
Integrated Master Schedule (IMS) arrange the Deliverables, Accomplishments, Criteria, and Work
Packages into a logical – risk adjusted – activity network.
Work Package progress is measured as Physical Percent Complete against the planned progress at time
of the performance assessment.
Work Authorization assures the sequence of Work Packages produce progress at the planned rate for
the planned cost, with the planned product maturity at each assessment point in the IMS.
Earned Value describes the current performance and provides information about future performance.
Conformance with Technical Performance Measures (TPM) adjusts Earned Value for rework, quality, or
delayed features, using Units of Measure meaningful to the decision makers.
Performance feedback from each WP and program level Earned Value adjusts the WP sequence and
resource allocation to reestablish an on–time, on–budget master schedule.
Future performance is based on the To Complete Performance Index (TCPI), Independent Estimate At
Complete (IEAC), and the adjusted work sequence.

13. Forecasting Future Performance needed to successfully
manage the project Starts with …
What Value did we plan to Earn? (BCWS)
Where are we now? (Physical Percent Complete)
What Value have we Earned to date? (BCWP)
BCWP = BCWS × Physical Percent Complete
Determining where we are now.
Is determined with a simple calculation

14. A Popular Bumper Sticker in
Boulder, Colorado (my home
town), says
Measures of Physical Percent
Complete are required to assess
progress to plan in presence of
uncertainty.
Trouble is, it’s not true.
— J. R. R. Tolkien
We need a target to steer
toward, and we need
measures of progress toward
that target.
That target is a statistcally
random number, so estimates
of the target and progress to
the target are needed.
Those estimates must be in
units meaningful to the
decision makers.

15. Measuring Physical Percent Complete …
§ Product Effectiveness ‒ a measure of success that are closely
related to the achievements of the mission or operational
objectives evaluated in the operational environment, under a
specific set of conditions. †
§ Product Performance ‒ a physical or functional attribute relating
to the system operation, measured or estimated under specific
conditions. †
Means Compliance With Planned Attributes Of Each
Deliverable Defined as Exit Criteria in the User Story
Physical Percent Complete requires measures meaning to the decision makers.
Effectiveness and Performance are the starting point.
† www.acqnotes.com

16. Measuring Physical Percent Complete …
§ Key Performance Parameters ‒ a capability and characteristic so
significant that failure to meet them can be cause for
reevaluation, reassessing, or termination of the program. †
§ Technical Performance Measures ‒ an attribute that determine
how well a system or system element is satisfying or expected to
satisfy a technical requirement or goal. †
Means Compliance With Planned Attributes Of Each
Deliverable
† www.acqnotes.com

17. Performance Measures Start at the Task Level for each
Story in the Sprint
§ For work Started, what is TO DO
compared to Planned?
§ Physical Percent Complete at the Task Level
o (Planned Estimate ‒ TO DO) / Planned Estimate
§ For Story S70 ‒ Purchase Your Items
o (26 hrs ‒ 16 hrs) / 26 hrs = 38%
o Task S70 has 2 Story Points assigned to it for 26 hours
Task S73 has 3 Story Points and 8 hours
o Story Points can be used to prioritize but not measure
The reason for the disparity in Story Points versus hours is multiple teams
estimated the Stories in this Feature. Rarely are EVM programs a single team.

18. Earned Value Measures at the Feature Level
Feature
25 UoM 10 UoM
15 UoM 25 UoM
Sprint 1 – 25 Sprint 2 – 25 Sprint 3 – 25
Physical Percent Complete (P%C) for the Feature is assessed at the end of each
Sprint. Earned UoM versus Planned UoM. These are ratios starting at the Task level
for each Story in the Sprint.
These UoM’s can be in Story Points, Ideal Days, or Hours as long as they are
consistent across the Feature’s Period of Performance.
Sprint 1 = 33 %
Sprint 2 = 66 %
Sprint 3 = 100%
Feature 1 – 75 Units of Measure (UoM)
EV
Reporting
Agile Team
Reporting
The Bright Line
Assessment of the ratios of Planned versus Actual are the basis of Physical
Percent Complete for any Unit of Measure.

19. Earned Value Measures at the Release Level
Capability
Feature (1-6)
18%
Feature (7-9)
18%
Feature (10-12)
28%
Feature (13-22)
36%
Release 1 Release 2 Release 3
The Bright Line
Physical Percent Complete (P%C) for the Capability
assessed at the end of each Release.
Release 1 = Capability 18% Complete
Release 2 = Capability 64% Complete
Release 3 = Capability 100% Complete
EV
Reporting
Agile Team
Reporting
Summing Physical Percent Complete from Tasks and Stories in the previous
chart to Features to Release.

20. Physical Percent Complete
§ The EV completion criteria must be based on technical performance, the
quality of work must be verified, and criteria must be defined clearly and
unambiguously.
§ The PM ensures that the EVM process measures quality and technical
maturity of technical work products instead of the quantity of work
performed.
§ In Agile Physical Percent Complete means Working Software at the end of
every Sprint.
§ The challenge in Agile is to account for deferred capabilities ‒ moved to the
next Sprint or Release ‒ and moving BCWS to follow them.
§ But in Agile, BCWS is flat spread connected with the labor assigned to each
Sprint that implements the Features.
… means compliance with planned Technical Performance of
Deliverable†
† See CPM 200-C Course Materials for Technical Performance Measures

21. Story Points are NOT a Meaningful
Measure of Physical Percent Complete
https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity
In Agile,
Story Point-based
measures are
about the Relative
effort the work will
take, not the actual
effort or duration

22. § When we use a measure of something we
need to know if it is Cardinal or Ordinal.
§ Ordinal measures tell us the relative
difference between items.
§ Uncle Scrooge is relatively rich
compared to Huey, Dewey, and Louie
is an Ordinal measure.
§ Cardinal measures are numbers that say how many of something there
are, they are counting numbers ‒ one, two, three, four, five.
§ Uncle Scrooge has $1,250,000,000 dollars of Gold
§ In Project Performance Management we use Cardinal numbers,
measured in Dollars, Hours, Technical Performance compliance.
§ Story Points are NOT a unit of measure used in Project Performance
Management.
Let’s Pause for an Interlude to Address the
Cardinal and Ordinal Estimating Problem
Ordinal versus Cardinal is a critical understanding for success of Physical
Percent Complete.

23. Story Points are all the Rage, but …
§ Are measures of Relative work effort – not duration or actual cost.
§ Story Points are NOT a measures of the cost of scope.
§ Story Points are Ordinal units of measure – relative measures.
§ Hours are measures of effort as well.
§ Hours also are a measure of Scope:
§ From the SOW, each deliverable is assigned a budget PV starting at the
proposal BOE’s.
§ From the labor rate, that PV can be converted to Hours of effort as well as
material costs.
§ PV is a Cardinal unit 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
Even though the NDIA Agile Handbook speaks about using Story Points, care is
needed to not confuse these with Physical Percent Complete.

24. A Caution for using Story Points to Measure Progress
Beyond a Single Feature from a Single Team
Ordinal numbers
ONLY have
meaning for their
current use ‒
unless calibrated
to a reference
that does not
change over time
Without Calibrated values, the numbers have no meaning when collected at
higher levels of the program ‒ WP’s and Control Account.

25. Ordinal Story Points cannot be the 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.
These are Not the same units of measure
between Features – Uncalibrated SP’s
Story 1
Story 2
Story 3
Story 4
Story 5
Story 6• • •
Using Ordinal (uncalibrated values) outside the domain of agreement prevents
comparison of progress to plan. My Story Points aren’t Your Story Points.

26. Stories and Story Points are not Measures of Performance …
§ 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.
§ Story Points are not scope, they are calibrated to Time and Money
outside an individual Scrum Team.
§ Counting Story Points is like counting Tasks in the IMS
§ We have 40 tasks to do for this delivery which is 9 weeks long (3, 3 week
Sprints).
§ We’ve done 20 Tasks so far.
§ Are we 50% complete for the planned task work?
§ Not likely unless each Task is of the same effort and duration.
… Beyond a single Scrum Team, with calibrated Story Points for their
own usage and need …
Let’s keep reminding ourselves Story Points are Ordinal measures.
Useful for relative sizing but not sizing in units of dollars and hours.

27. Counting Stories has the same issue, since …
§ In this release we have 12 Stories to implement the Feature.
§ We’ve completed 6 of the 12 Stories.
§ Are we 50% complete with the Feature?
§ 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
Evidence shows there is little correlation between Story Points and Story Count.
This comes from SRDR efforts to estimate upfront from past performance.

28. Why We Can’t Add Ordinal Values (Story Points) from
Number Theory
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.
For example …
Your breath smells like a funny color or The number 9 is slippery
Formally, doing mathematics on Ordinal numbers is not possible in the way we
need to produce performance measures on Earned Value projects.

29. EV Calculated by Physical Percent Complete
n Story Points CAN be 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.
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 tne 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.
Story Points are useful for prioritizing work, we don’t need them for calculating
Physical Percent Complete. Because we have hour estimates on the contract.

30. Estimating Agile Work in Hours is the start of
Federal contracts issued in Dollars
Dollar and Hour estimates needed for FAR contract work, so we have those
estimates by Feature that can be moved to the Agile management system.

31. Physical Percent Complete During Sprints
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
With the hours allocated to the Story and decomposed to the Task level during
story time on the Sprint, we can now measure Progress to Plan.

32. Story Points as Physical Percent Complete
§ If a Story was estimated to be 6 Story Points, how would we measure
progress to plan during the Sprint?
§ Can we accumulate incremental Story Points?
§ Can we be 50% complete if we have accumulated 3 SPs out of the 6?
§ If we use hours ‒ as shown above ‒ we can measure progress in the
same way EVM does with 0/100 at the Task level.
§ This is then rolled to the Story level as Physical Percent Complete from
the Tasks.
§ How do we assess progress at Month End when the Sprint crosses the
Month End boundary?
Using the spreadsheet in the previous chart, what would be the measure
of Physical Percent Complete using Story Points or Stories?

33. 33
The single source provider of integrated project management processes, services
and toolsets. PrimePM integrates Processes, Toolsets, and Subject Matter
Experts creating Scalable Project Management solutions to address unique
challenges of our clients.
These services include:
§ Agile and EVM process Integration in compliance with EIA-748-C
§ Quick Start Process for System Description and Agile Work Instructions
§ Tool Implementation and Integration for Cost and Schedule integration
§ Program Planning and Control processes for Agile and EVM
§ Hosted Services for Program Management execution