Agile development and Earned Value Management have mutually supporting principle, processes, and practices

1. Glen B. Alleman
Agile Program Planning and Controls
303 241 9633
galleman@primepm.net

2. § Framing assumptions for EVM and Agile.
§ What are the elements of the Intersection?
§ Connecting Business Value with Earned Value.
§ Taxonomy of this intersection.
§ Connecting the Principles of Agile with EVM.
§ Structure of an Integrated system.
2
§ Generating Physical Percent Complete in the Agile
System to generate BCWP
§ The Dark Side Agile Development.
§ Principles. Practices, and Process of EVM + Agile
Success ‒ in place before tools.

3. Agile software development is a group of
methodologies based on iterative development, where
requirements and solutions evolve through
collaborative self-organizing cross-functional teams.
Agile methods promote disciplined project
management processes using frequent inspection and
adaptation, teamwork, self-organization and
accountability, to rapidly deliver high-quality software,
with a business approach aligning development with
customer needs and company goals.
Scrum is an Agile software development method
3

4. From a recent DCMA Implementation Review out brief,
the Earned Value Management System must …
4
Properly relate cost, schedule, and technical
accomplishment, to provides valid, accurate, timely
data, that can be used as an integrated program
management tool to inform the decision makers.
The Intersection of Earned Value Management and
Agile Software Development must integrate these two
paradigms to produce actionable information in units
of measure meaningful to the decision makers.

5. Work Breakdown
Structure (WBS)
Work Packages and
Planning Packages
ProductBacklog
SprintBacklog
IMP and IMS define the
order of work needed to
implement the Product
Road Map and through the
Release Plan.
Release Plan shows when
the needed Features in the
WBS will be delivered to the
customer in accordance
with the Product Roadmap.
IMS shows the sequence of
Work Packages containing
the Features contained in
the Product Backlog.
Sprints implement the
Features in the Work
Packages on short
boundaries usable by
customer.
Integrated Master
Plan (IMP)
Integrated Master
Schedule (IMS)
ProductRoad
Map
ReleasePlan
Measure BCWP
with Physical
Percent
Complete at the
Feature Level
5

6. The Secret to Agile is Ceremony,
which is another name for Process …
… Just like the Secret of Earned Value Management …
… in the Process Ceremonies described in …
EIA-748-C, FAR 34.2, DFARS 234.2, OMB A-11, Part 7, NASA/SP-2012-599,
HHSAR 352.234, 48 CFR 1852.234-1, DOE G 413.3-10 A 6

7. … in Units of Measure Meaningful to the
Decision Makers. 7

8. Each Feature Release is a Business
Value Earning opportunity
The next step connects
Agile’s definition of Value with
Earned Value’s definition of Value
Integrating EV+Agile so …
Business Value ÙÚ EV
8

9. Key Principles of Agile Key Principles of EVM
Active user involvement Hierarchical decomposition of the work
Team empowered to make decisions Work Package managers guide the work
Requirements evolve but time scale is fixed Capabilities baselined, requirements emerge in
Rolling Waves on fixed boundaries
Requirements at high level, lightweight and
visible
Deliverables define as Capabilities with
measures of Effectiveness and Performance
Develop small, incremental releases and
iterate work rhythm to produce outcomes Integrated Master Plan (IMP) and Schedule
(IMS) define increasing maturity of
deliverables through Significant
Accomplishments (SA) and Accomplishment
Criteria (AC) with continuous application of
Systems Engineering and Risk Management to
increase the probability of program success.
Focus on frequent delivery of working
products for customer to evaluate
Complete each feature before moving on
Pareto’s law for what’s important to customer
Test integration throughout life cycle
Collaborative and cooperative approach IPTs with integrated handoffs 9

10. Before Moving to the Integration of Agile and EVM,
Let’s Look at the Business Management Practices …
…That Must Be in Place Before Connecting Agile and EVM
Relate time phased
budgets to specific
contract tasks
Enable statistical
estimation of
completion cost
Track and
monitor discrete
project metrics
Communicate
project status
Provide
quantitative data
for decision making
Provide a
documented project
performance trace
Alert project managers
to potential schedule
and cost risk
Provide managers with
information at a practical
level of summarization

11. Needed Capabilities
defined as Features in
Product Roadmap and
Release Plan
Prioritized Agile
Product Backlog
Software
Development with
Scrum or Kanban
Status Physical
Percent Complete
of Stories for each
Sprint
EV Data in PMB for Work
Packages and Planning
Packages of Features with
BCWS spread by headcount
Agile Development System, with Product Backlog of Features and Stories for the Release
11
Product Roadmap
Product Release
Plan
at Feature Level
IMP/IMS, WBS,
Work Packages in
Rolling Waves
BCWP, ETC, EAC at
WP from Physical
Percent Complete
Report Physical
Percent Complete
at Work Package
Rough Order of
Magnitude
Estimate for
Features
Refined
Estimates flowed
to Work
Packages
Estimate assigned
to Prioritized
Features in
Product Backlog
PMB, with Control Account, Work Package, Product Roadmap, and Release Plan

12. 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
…
n Starting with Releases, Capabilities are flowed to the PMB
n Capabilities produce the value from each Release
n Control Accounts and Work Packages on baseline in the PMB
n Work Packages contain Features produced in each Release by Sprints
n Release Planning baseline for period of performance and PV
n Feature P%C = Completed work / Planned work
n Feature hours = Bottom Up from Task Estimate
n Feature remaining hours = TO DO hours in agile tool
for Tasks, rolled to Stories, to Features
EVM Reporting from
Work Package
Performance
EVM Performance
• PV – from WBS Basis of
Estimate
• AC – from time cards
• EV – from completed
Story Points
12

13. # EVM Guideline Agile Approach
1 Define WBS Features and Stories in the Backlog
2 Identify Organization Self organizing teams
5 Integrate WBS and OBS Self organized teams with a customer
6 Schedule Work Roadmap, Release Plan, Sprints
7 Identify Products & Milestones Working software at the end of Sprint
8 Set time phased budget Budget across Releases
16 Record direct costs Fixed staff = Level of Effort
23 Determine variances Measures missed features
25 Sum data and variance Missed features moved to next Sprint
26 Manage action plans Replan missed features, adjust velocity
28 Incorporate changes Replan missed features, adjust velocity

14. Closed Loop Feedback Control
for Agile at Scale†
❶ Engineering
Estimate
❷ Product
Roadmap
❸ Release Plan
❺ Product
Backlog
❻ Sprint Backlog
❹ IMS with
Features
in WP
❼ Story and Task
Estimates During
Sprint
❽ TO DO Updates Produce
Physical Percent Complete
❿ Update Physical
Percent Complete in
Cobra®
❾ Update Feature in IMS
with Physical Percent
Complete
Plan
Do
Check
Act
Continuous feedback at each step with
corrective actions for Root Cause of
Performance Variances
† This is not the INCOSE Vee, it’s just to save
space on this page
14

15. A full cycle estimating process, starting at the Top, but continuously
reassessing past performance with new understanding emerging from
the Bottom
Reference Class
Estimates from
Past Performance
Confirmation of
Estimates based on
Team Input and
Current
Performance 15

16. 16

17. Doing, Is The Hard Part
Knowing, Is The Easy Part

18. Task Estimate in Hours (Do
not edit after Sprint begins)
Task TO DO in Hours.
Edit after Daily Standup
18

19. 19
Original
Engineering
Estimate in Hours
Estimate of
Hours for User
Stories in Sprint
Remaining
Hours for Story
0 Hours Remaining
Means Story Done
10 Hours of 10
Remaining Means Story
Not Started
Sprint-1 100% Complete
After Sprint-1 Feature 42%
Complete, with 60 Hrs
remaining
Sprint-2 50% Complete
At this point in Sprint-2,
Feature is 44% Complete

20. IMS Updated from the Physical Percent
Complete at Story and Task level, provides
visibility to ETC and EAC as Progress Proceeds
in the presence of uncertainty
It’s the measure of Physical
Percent Complete to Plan that
lets us see into the future
20

21. § IMS is the book of record for
an agile development
program.
§ Work Packages, with Features
held in the IMS.
§ Features moved to Product
Backlog in Rally.
§ Bi-directional exchange
between MSFT Project and
Rally fully integrates PMB with
agile work processes.
§ Physical Percent Complete
represented by Working
Software calculated in Rally
and sent to the IMS.
§ Percent Complete used to
calculate BCWP in IMS for
completed Features from
Sprints.
The Performance Measurement Baseline held in the IMS statused from Release, Sprint,
and Task activities in the Agile system.
This is forwarded to Cobra® for production of the IPMR.
21

22. § Being Agile creates Cost Growth in response to the
emerging requirements in the presence of
Uncertainty
§ Late changes mean prior work may never be
deployed.
§ Prior work is recorded as scrap and rework on the
book and replaced with the new deliverables.
§ Effort to re-purpose the prior work is also a non-
recoverable sunk cost.
§ With the $20M EVMS threshold, the program is likely a Software Intensive
System of Systems (SISoS), with complexities beyond simple self-organized
Agile teams with an on site customer, exploring for new business value.
§ Not simple straight forward development with independent work
activities – it’s an integrated complex system.
§ Coupling and cohesion considerations overwhelm the simple task of
writing software to meet the short term needs of an on site customer.
You may dispense with the
pleasantries commander, I’m here
to put you back on schedule

23. § Story points are not Scope, Cost, or Duration, they
represent relative (UN‒calibrated) Ordinal values,
whose meaning can only be determined by
comparing them to other Story Points that have
the basis basis of comparison.
§ Story Points are not units of measure meaningful
in Earned Value – which uses Cardinal Values
We have, ahem, rather strong views on the implementation of EV on our
Agile–managed projects. To be succinct: if done properly and in accordance
with our policies and procedures we see no conflict between EV practice and
Agile. Indeed, EV can be just as useful as it is on any other project *if* the
Story Points are defined and baselined upfront, and proper accounting of
AC, PV, and EV is done in execution, by Story point. As you would expect,
this requires some discipline upfront and attention to execution details, but
that is the price of admission for any organized and coherent management
approach.
‒ email from Mr. Gary Bliss, 15 September 2015

24. Ordinal numbers
only have
meaning for their
current use ‒
unless calibrated
to a baseline that
does not change
over time

25. ü Baseline
Budget
ü Contractual
Performance
EVM Agile
ü Emerging
Capabilities
and Features
ü Rolling Wave
ü Risk Management
ü 748-C Compliance
ü Releases and Sprints
ü Physical Percent
Complete
ü EAC/ETC at Feature Level
Integrating Agile development is Earned Value Management is straight
forward if we focus on the strengths of each domain and the ONE shared
attribute – Physical Percent Complete compared against BCWS at the Sprint
level for the development of each Feature
25

26. 1. Define a Work
Breakdown Structure
2. Identify the
Organizations doing
the work
5. Integrate WBS and
OBS into a RAM
6. Schedule all
Planned Work
7. Identify Products
and Milestones
8. Time Phase the
Budget
16. Record all Direct
Costs
23. Determine all
Variances
25. Sum These
Variances
26. Manage Action
Plans
28. Incorporate Changes 26

27. 27

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

29. 29† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014
Principle Practice Process
❶ Define Done in units of
measure meaningful to the
decision makers.
❶ Identify needed capabilities
and their measures of
effectiveness and
performance.
❶ Organize resources to
assure they are properly
assigned and effective.
❷ Develop risk adjusted plan
to reach Done with business
success.
❷ Identify technical and
operational requirements to
fulfill capabilities.
❷ Plan and Budget all costs,
facilities, and risk reduction
activities.
❸ Identify resources needed
to reach Done as planned.
❸ Establish Risk Adjusted
Performance Measurement
Baseline.
❸ Account for direct and
indirect costs against the
planned budget.
❹ Identify impediments to be
removed along the path to
Done.
❹ Execute Performance
Measurement Baseline as
planned.
❹ Analyze performance and
take corrective actions to stay
on plan.
❺ Measure progress to Done
as Physical Percent Complete.
❺ Perform Continuous Risk
Management.
❺ Manage all changes to
baselined plans.

30. Back Up

31. Principle Practice Process
❶ Define Done in units of
measure meaningful to the
decision makers.
❶ Identify needed capabilities
and their measures of
effectiveness and
performance.
❶ Organize resources to
assure they are properly
assigned and effective.
❷ Develop risk adjusted plan
to reach Done with business
success.
❷ Identify technical and
operational requirements to
fulfill capabilities.
❷ Plan and Budget all costs,
facilities, and risk reduction
activities.
❸ Identify resources needed
to reach Done as planned.
❸ Establish Risk Adjusted
Performance Measurement
Baseline.
❸ Account for direct and
indirect costs against the
planned budget.
❹ Identify impediments to be
removed along the path to
Done.
❹ Execute Performance
Measurement Baseline as
planned.
❹ Analyze performance and
take corrective actions to stay
on plan.
❺ Measure progress to Done
as Physical Percent Complete.
❺ Perform Continuous Risk
Management.
❺ Manage all changes to
baselined plans.
31† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

32. What Does
Done Look
Like?
❶
What’s The
Plan To
Reach Done?
❷
What
Resources
Do We
Need?❸
What
Impediments
Prevent
Reaching
Done?❹
How is
Progress To
Plan
Measured?
❺
Organize all
Resources
❶
Plan and
Budget all
Costs
❷
Account for
Direct Costs
❸
Analyze
Performance
for Corrective
Actions
❹
Manage all
Changes to
Baseline
❺
Identify
Needed
Capabilities
❶
Identify
Requirements
❷
Establish Risk
Adjusted PMB
❸
Execute PMB
❹
Continuous
Risk
Management
❺
32

33. 33
Principles Practice Beneficial Outcome
What Does Done
Look Like?
Identify Needed
Capabilities
The customer bought the
capability to accomplish a mission
or provide business value.
What are these and what are their
measures of Effectiveness and
Measures of Performance
Identify
Requirements
Technical and operation
requirements fulfill the needed
Capabilities.
What are their Technical
Performance Measures?
Establish Risk
Adjusted PMB
Each measure has uncertainty that
creates risk, what are these?
Execute the PMB Execute this plan
Organize all
Resources
Do we have the right resources at
the right time?
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

34. 34
Principle Practice Beneficial Outcome
What’s the Plan
to Reach Done?
Identify the
needed
Capabilities
With a roadmap for what
Capabilities are needed at what
time, a Plan is developed to
making that happen
Establish the
Risk Adjusted
PMB
For each needed capability, risks
that reduce the probability of
success must be identified along
handling plans
Execute the PMB The Plan shows what work is
performed in what order. For Agile
the Plan is the Product Roadmap
and Release, showing what
Capabilities will be delivered in
what Release
Continuous Risk
Management
Risk Management is How Adults
Manage Projects – Tim Lister
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

35. 35
Principle Supported by Beneficial Outcome
What resources
are needed to
reach Done?
Establish Risk
Adjusted PMB
Staff planning is a critical success
factor. For agile teams consistency
across the life of the project is a
critical success factor
Identify
Requirements
For each of the requirements,
specific skills may be needed.
Planning for these skills is required
to address the risk management
processes.
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

36. 36
Principle Practice Beneficial Outcome
What
Impediments
prevent
reaching
Done?
Continuous Risk
Management
Risks are created by uncertainty.
Uncertainty comes in two forms
Reducible uncertainty –
probabilistic events create
uncertainty. These can be
addressed with redundancy,
testing, alternative processes.
Irreducible uncertainty – is the
naturally occurring processes of
the project. These are reduced
with margin to cover the range of
outcomes for cost, schedule, and
technical performance.
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

37. 37
Principle Practice Beneficial Outcome
Measuring
progress to
Done?
Physical Percent
Complete is the
basis of measure
progress to plan
Measures must be tangible
evidence compared to planned
measures
Physical Percent
Complete is
defined in units of
measure
meaningful to the
decision maker
MOE - measures of success that
are closely related to the
achievements of the mission or
operational objectives
MOP - characterize physical or
functional attributes relating to the
system operation.
KPP - characteristics so significant
that failure to meet them can be
cause for reevaluation
TPM - determine how well a
system is satisfying a technical
requirement or goal
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

38. 38
Practice Process Beneficial Outcome
Identify Needed
Capabilities
Define the
Measures of
Effectiveness for
each Capability
Define
capabilities as
Operational
Concepts
The customer wants to put the
resulting software to work to solve
a problem, not the technical
outcomes.
Define
operational
concepts with
scenarios
Scenarios are a good way to
describe what the Capabilities will
do when they are complete and
delivered.
Assess needs,
cost, and risk of
capability
simultaneously
The trade offs for cost, needs, and
risk all impact each other. Define
how this takes place
Define explicitly,
balanced, and
feasible
alternatives
Have alternatives for each
Capability and the requirements
that implement those capabilities
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

39. 39
Practice Process Beneficial Outcome
Identify
Requirements
Define the
Measures of
Performance for
each Requirement
Performance fact
finding
Produce an overall statement of the
problem in the operation context
Gather and
classify
requirements
Build top down Capabilities and
Functional decomposition of
requirements
Evaluate and
rationalize
requirements
Answer the question – why do we need
this?
Prioritize
requirements
Determine criticality for each functions
Integrate and
validate
requirements
Validate requirements are traceable to
the Capabilities
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

40. 40
Practice Process Beneficial Outcome
Establish the
Performance
Measurement
Baseline
Define the
Technical
Performance
Measures of each
Work Package
Deliverable
Decompose
requirements into
Work Packages
Decompose the work into a Work
Breakdown Structure. Decompose the
WBS into Work Packages and Planning
Packages
Assign
accountability for
the deliverables
Assign accountability for Work
Packages to a named owner for
management of resources, cost and
technical performance
Develop BCWS
Develop a time phased budget for the
work
Assign work
package Measures
of Performance
Define the Measures of Performance
define the acceptance criteria for the
deliverables from the work
Set the
Performance
Measurement
Baseline
The PMB for use in forecasting work
package and project performance
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

41. 41
Practice Process Beneficial Outcome
Execute the
Performance
Measurement
Baseline
Maintain Cost,
Schedule, and
Technical
Performance
Perform authorized
work in the planned
sequence
The Product Roadmap and Release Plan
defines the needed Capabilities and
their need dates
Accumulate work
package
performance
For each work package, performance
provides actionable information to the
decision makers
Analyze work
package
performance
With this information, decisions can be
made
Take corrective
actions
Each decision needs to increase the
probability of project success
Maintain PMB
integrity
The integrity of the baseline is needed
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

42. 42
Practice Process Beneficial Outcome
Performance
Continuous Risk
Management
Execute the
Work Packages
Identify Risk
Risks identified through a risk
elicitation process from subject matter
experts
Analyze Risks
Risk decision making information
produced from the analysis
Plan Risk Handling
Risk decision information turned into
action plans
Track Risk Handling
Status and actions monitored for
management intervention
Control Risks
Corrective action eliminates, responds,
or reduces risk impacts to cost,
schedule, and technical performance of
the project’s deliverables
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

43. Principle Earned Value Agile
Define Done in units of
measure meaningful to the
decision makers
SOW, SOO, ConOps, WBS
Product Backlog derived from
the WBS
Develop plan to reach Done
needed for business success
Integrated Master Plan,
Integrated Master Schedule
vertical and horizontal
traceability
Release and Sprint
management
Identify resources needed to
reach Done as planned
Resource loaded IMS
Fixed staffing model for each
Agile team
Identify impediments to be
removed along the path to
Done
Risk Register and Risk
Adjusted IMS with Risk Buy
Downs and Margins
Agile has no formal Risk
Management. Use EVM Risk
Management
Measure progress to Done as
Physical Percent Complete
EVT = 0/100 for QBD’s, MOEs,
MOPs, TPM, and KPPs
Working Software at the end
of each Sprint is
EVT = 1/100
43† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

44. Practice Earned Value Agile
Identify capabilities with
measures of effectiveness and
performance
Integrated Master Plan define
maturity assessment events
Product Backlog with
everything needed in the
product
Identify technical and
operational requirements to
fulfill capabilities
IMS with deliverables from
Work Packages with Exit
Criteria define work
Product Backlog as the single
source of all requirements
Establish Risk Adjusted
Performance Measurement
Baseline
Risk Register traceable to work
in the IMS
Agile doesn’t address Risk
Management, but provide
feedback used by RM
Execute Performance
Measurement Baseline as
planned
Business rhythm on weekly
status of Work Package
progress to plan
Releases and Sprints on “time
boxed” boundaries
Perform Continuous Risk
Management
Risk Management process
External RM uses Agile Story
completions for analysis
44† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

45. Process Earned Value Agile
Organize all resources to
assure they are properly
assigned and effective
Organizational Breakdown
Structure defines teams and
assignments to CA’s
Fixed staffing at the Sprint
level
Plan and Budget all costs,
facilities, and risk reduction
activities
Resource loaded IMS with
Control Account and Work
Packages traced to WBS
Flat spread PV
Account for direct and indirect
costs against the planned
budget
Charge numbers assigned to
all work Flat spread AC
Analyze performance and take
corrective actions to stay on
plan
Earned Value performance
analysis
No CV. SV due to missed
Features, moved to next
Sprint.
Manage all changes to
baselined plans
Baseline Change Control
Self managed between
Product Owner and
Development Team
45† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

46. § Risk Management
◦ Risk impact forecasting on EAC
§ Change Control
◦ Baseline Change Control
◦ Forecast Change control
§ Root Cause Analysis
◦ Corrective actions needed to stay inside BAC
§ Management Reserve
◦ Allocation of funds cannot be used to cover overages
◦ Emerging requirements need careful consideration when
using MR
46† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

47. 47
Define the authorized work elements for the program. A work breakdown
structure
(WBS), tailored for effective internal management control, is commonly used in
this process.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Work Breakdown Structure (WBS).
§ Road Map & Release Plan consisting
of Capabilities, Product Backlog &
Sprint Backlog.
§ WBS dictionary (may or may not be
used, but a method to reconcile the
statement of work to the WBS
structure must be demonstrated).
§ WBS dictionary: agile user stories are
deliverables that you can measure
“done” for, therefore user stories
satisfy WBS dictionary.
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

48. 48
Identify the program organizational structure, including the major
subcontractors responsible for accomplishing the authorized work, and define
the organizational elements in which work will be planned and controlled.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Organization Breakdown Structure
(OBS).
§ CAM just builds a team as usual, but
the team needs to be persistent, and
not interchangeable parts.
§ OBS intersections with the WBS.
§ Team hierarchy definition with
resources associated with their sub–
teams.
§ Done at the level of granularity to
support the basis of estimate (BOE).
§ Persistent teams are needed to apply
throughput benchmarks to Product
Backlogs to validate plans.
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

49. 49
Provide for integration of the program work breakdown structure and the
program organizational structure in a manner that permits cost and schedule
performance measurement by elements of either or both structures as needed.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Control accounts.
§ Evidence that the CA meets the 90% discrete
work rule.
§ Defend schedule & cost performance at the CA
level?
§ Agile CA = one release.
§ Actuals captured at the Story level.
§ Responsibility Assignment
Matrix (RAM).
§ Done at too high a level for the SW
development approach to make a difference.
§ Contract Performance
Reports (CPRs), if applicable.
§ Given an objective of X stories in Sprint Y,
completed stories are earned; all unearned
return to backlog and a new ETC is developed
from the benchmarks & backlog.
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

50. 50
Schedule the authorized work in a manner which describes the sequence of
work and identifies significant task interdependencies required to meet the
requirements of the program.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Integrated network schedules
including master, intermediate (if
any), and detailed schedules.
§ CAM’s agile roadmap becomes the
auditable intermediate schedule
demonstrating significant
accomplishments (SA).
§ MRP or ERP schedules, or planned
order reports.
§ Each task in IMS has associated
resources.
§ Control account plans (may be
separate plans or detail schedules).
§ CAM creates schedules compliant to
DCMA 14 point assessment.
§ Work authorization documents. § Nothing different.
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

51. 51
Identify physical products, milestones, technical performance goals, or other
indicators that will be used to measure progress.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Integrated schedules including
master, intermediate (if any), and
detailed schedules that identify
contract milestones and key events.
§ Agile Development performance
reporting follows the approved
program system description
§ Apportioned technical performance
milestones to reduce risk & roll up
intermediate technical performance.
§ MRP or ERP production planned order
reports.
§ Not relevant to SW development.
§ Control account plans (may be
separate plans or detail schedules)
§ Not relevant to SW development
because we are reporting tasks as
physical % complete, which will
automatically roll up.
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

52. 52
Establish and maintain a time–phased budget baseline, at the control account level,
against which program performance can be measured. Initial budgets established for
performance measurement will be based on either internal management goals or the
external customer negotiated target cost including estimates for authorized but
undefinitized work.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Control account plans.
§ Time phased budget created for the current Sprint(s)
and future work.
§ Summary level planning
packages.
§ Agile summary level planning documented in road map.
Comprises capabilities, features and stories
§ Agile planning packages driven by persistent teams with
proven benchmarks.
§ Performance Measurement
baseline.
§ Is there a target threshold for future work as described
in a PMB? Within 10% OTB?
§ Undistributed budget logs. § Does this have anything to do with SW dev approach?
§ Notification to the customer
of an over–target baseline.
§ Does this have anything to do with SW dev approach?
§ Work authorization
document.
§ Does this have anything to do with SW dev approach?
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

53. 53
Record direct costs in a manner consistent with the budgets in a formal system
controlled by the general books of account.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Reconciliation of project costs with
the accounting system.
§ CAM would follow program direction
on these.
§ These are not impacted by SW dev
approach
§ Actual costs are reported at the
control account level at a minimum.
§ Not impacted by SW development
approach.
§ Reconciliation of subcontract
reported actual costs to subcontract
payments.
§ Not impacted by SW development
approach.
§ Internal and external performance
reports for subcontractors.
§ Not impacted by SW development
approach.
§ Subcontractor control account plans,
when utilized.
§ Not impacted by SW development
approach.
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

54. 54
Identify, at least monthly, the significant differences between both planned and
actual schedule performance and planned and actual cost performance, and
provide the reasons for the variances in the detail needed by program
management.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Variance analyses (budget based
schedule variances and cost
variances).
§ Can track & report variances per the
approved program system
description
§ Management action plans. § Actionable recovery plans per issue.
§ Updated schedule task completion
and cost–at–completion forecasts.
§ Agile has a POD and Plan for Sprint.
§ CAM’s monthly EAC reporting
follows the approved program
system description
§ Project schedules and schedule
analysis outputs.
§ PM tracks the dynamic backlog,
which will go up and down based on
sponsor feedback
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

55. 55
Summarize the data elements and associated variances through the program organization
and/or work breakdown structure to support management needs and any customer
reporting specified in the project.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Variance analyses.
§ There is nothing in Agile’s approach to SW
development that precludes reporting variances at
the WP level.
§ Agile is more dynamic than EVM so variances are
less the issue than the evolving baseline, as
approved in governance. The sponsor will want to
track accumulating business value and variances to
total product needs.
§ Schedule and cost performance
reports.
§ Similar – but measures of performance not usually
in dollars
§ Management action plans.
§ Similar – but less formal. Collaborative discussion
of what actions to take include the customer.
§ Updated schedule and cost
forecasts.
§ Similar – but less formal. Planning processes
include the customer.
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

56. 56
Incorporate authorized changes in a timely manner, recording the effects of
such changes in the budgets and schedules.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Contractual change documents.
§ Bug reports, new user stories, but not
necessarily cost sized.
§ User stories above baseline are tracked
as new scope (with a valid BOE) and
require PV
§ Change control logs (management
reserve, undistributed budget,
performance measurement
baseline, and contract budget
base).
§ New or materially altered features or
stories are changes.
§ Control account/work
package/planning package plans.
§ Product and Sprint backlogs are frozen
during the development period
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

57. 57
Incorporate authorized changes in a timely manner, recording the effects of
such changes in the budgets and schedules.
EVMIG Objective Evidence Agile Objective Evidence for EV
§ Master schedules, intermediate
schedules (if any), and detailed
schedules.
§ Sprints and evolutionary planning at the
detailed levels merges with the end to
end planning for agile.
§ Statement of work, WBS, and WBS
dictionary.
§ Customer owner and Planning
processes identify requires work and its
description.
§ Work authorization documents.
§ Planning sessions, authorize a set of
Stories to be developed during the
Sprint.
§ Management reports (contract
performance reports or other
applicable management reports).
§ Big Visible Charts, “sticky notes” display
progress to plan for the agile team.
† Abstracted from Performance-Based Project Management, Glen B. Alleman, American Management Association, 2014

58. 58
Time Page
0:48 1
0:33 2
0:55 3
0:15 4
0:34 5
0:26 6
0:40 7
0:33 8
0:43 9
0:18 10
0:42 11
0:40 12
0:30 13
0:46 14
0:46 15
0:35 16
0:10 17
0:15 18
0:20 19
0:20 20
0:35 21
0:48 22
0:11 23
0:20 24
0:27 25
0:15 26
0:15 27
0:36 28
0:28 29
1:28 10% Slide switching
1:28 10% Pauses and delays
17:40 Total Time