Developing software using Scrum still needs the ability to determine the Estimate to Complete (ETC), the Estimate at Completion (EAC), and the Estimated Completion Data (ECD) when there is a fixed deliverable date, a fixed budget for that software, and a minimal set of Features and Capabilities on that date for that budget

1. 1
CALCULATING PHYSICAL PERCENT
COMPLETE FOR THE NES PROJECT USING
SCRUM AND ATLASSIAN STRUCTURES
Developing software using Scrum still needs the ability to determine
the Estimate to Complete (ETC), the Estimate at Completion (EAC), and
the Estimated Completion Data (ECD) when there is a fixed deliverable
date, a fixed budget for that software, and a minimal set of Features
and Capabilities on that date for that budget

2. Learning Objectives
§ Show how measuring Physical Percent Complete for
produced software is THE critical success factor for
integrating Performance Management with Agile
sofwtare development.
§ Show how to define Physical Percent Complete to
calculate Project Performance from the 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.

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

4. Looking for Simple Solutions to Questions?
They’re Aren’t Any …
The $20M Question ‒ How can we seamlessly integrate Scrum Development with
Project Performance Management measured in Dollars and Hours?

5. 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

6. 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. 6

7. 10 Steps to an Integrated Agile and Performance
Management System Using Physical Percent Complete
Capabilities Defined
in Product Roadmap
Release Plan Defines Work
assigned to Sprints
Release Contains Features
in Sprint
Measure Physical
Percent Complete for
Each Feature
Perform Work IAW
Roadmap and Backlog
Physical Percent
Complete Defines
Progress
Adjust P&C for Technical
Performance
Measure
Use Past Performance to
Forecast Future
Performance
1
2
3
5
6 7
8
9
10
Work Sequence of
Features Defined in
Roadmap
4
9
Assess the capabilities being provided through the delivered Features
Fulfill the requirements through effort held in the Product Backlog
Produce deliverables from
Product Backlog
Planned Budget
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

8. 8
10 Steps to Integrating Agile Development and Performance
Management System Using Physical Percent Complete
Principles to Integrate Agile with Project Performance Management in Order of Increasing Maturity
1 Capabilities drive system Features. All Features must be traceable to a capability.
Features and their Stories and Tasks identify technical and process deliverables.
Sprints contain the work activities used to produce the deliverables.
Product Roadmap arranges the Capabilities and their Features – risk adjusted – into activity
flow, from which Stories can be developed as the Basis of Estimate for the Sprint teams.
Work progress is measured as Physical Percent Complete against the planned progress at
time of the performance assessment.
Work Authorization (Backlog Grooming and Sprint Backlog) assures the sequence of Work
produce progress at the planned rate for the planned cost, with the planned product maturity at
each assessment point in the IMS.
Performance Measures describes the current performance and provides information about
future performance.
Conformance with Technical Performance Measures (TPM) adjusts Program Performance for
rework, quality, or delayed features, using Units of Measure meaningful to the decision makers.
Performance feedback from each Sprint and resulting Stories and Features, sequences the
Product Roadmap 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.

9. 9
Forecasting Future Performance needed to
successfully manage the project Starts with …
What Stories and Tasks did we plan to produce?
Where are we now? (Physical Percent Complete)
What Stories and Tasks have been completed
now?
Produced = Planned × Physical Percent
Complete
Determining where we are now.
Is determined with a simple calculation

10. 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 statistically
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.

11. Measuring Physical Percent Complete …
§ Product Effectiveness ‒ a measure of success that
are closely related to the achievements of the
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 meaningful to the decision makers.
Effectiveness and Performance are the starting point.

12. 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
replanning of the project.
§ 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 (Exit Criteria)

13. 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

14. 14
Project Performance 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
Project
Performance
Reporting
Agile Team
Reporting
Summing Physical Percent Complete from Tasks and Stories
to Features to Release.

15. Physical Percent Complete …
§ The Project Performance completion criteria must be based on technical
performance, the quality of work must be verified, and criteria must be
defined clearly and unambiguously.
§ The PO/PM ensures that this 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 Budget to follow them.
§ But in Agile, Budget is flat spread connected with the labor assigned to
each Sprint that implements the Features.
… means compliance with planned Technical
Performance of Deliverable

16. 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

17. Let’s Pause for an Interlude to Address the
Cardinal and Ordinal Estimating Problem
§ 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.
Ordinal versus Cardinal is a critical understanding for success of Physical Percent Complete.

18. 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 ‒ Features and Capabilities.

19. 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.