Agile and earned value management

APPROVED FOR PUBLIC RELEASE DISTRIBUTION UNLIMITED: 16-S-1407, March 3, 2016.
Contents
Foreword.......................................................................................................................................................2
Background...................................................................................................................................................2
Introduction..................................................................................................................................................3
Agile and EVM System Compliance ..............................................................................................................4
1. Organization and the WBS................................................................................................................4
2. Planning and Scheduling...................................................................................................................6
3. Measuring progress ..........................................................................................................................8
4. Baseline Maintenance.......................................................................................................................9
Agile and Maintaining EVM System Compliance........................................................................................11
1. Standard terminology and metrics .................................................................................................12
2. Agile metrics and EVM metrics.......................................................................................................12
3. Traceability......................................................................................................................................12
Agile Reference Terms................................................................................................................................13
Figure 1 - SW Development MIL-STD-881C Appendix K WBS breakout.......................................................5
Figure 2 - Possible Agile SW Development MIL-STD-881C WBS breakout. Not prescriptive. ......................5
Figure 3 - Features support the completion and delivery of Capabilities. In the product backlog,
Capabilities directly relate to the Control Account level of the WBS...........................................................6
Figure 4 - A potential representation of an Agile product backlog hierarchy ..............................................7

This document is intended as informative resource for Department of Defense (DoD) personnel who
encounter programs on which Agile philosophies and Earned Value Management (EVM) are applied. It is
not an official policy, nor is it a step-by-step handbook for Agile implementation or the application of
EVM.
Foreword
The DoD acquisition process supports the procurement and production of large, strategic, and
deployable systems to address specific threats. Per the DoD Defense Acquisition System Directive
5000.01, an acquisition system is “a directed, funded effort that provides a new, improved, or
continuing materiel, weapon or information system, or service capability in response to an approved
need… [t]he primary objective…is to acquire quality products that satisfy user needs with measurable
improvements to mission capability and operational support, in a timely manner, and at a fair and
reasonable price.” Constantly evolving threats have presented a demand for an acquisition process that
is able to respond quickly to emerging requirements and rapidly changing environments. To address
this, the DoD has encouraged the following characteristics in acquisitions:
1. Flexibility: tailoring program strategies and oversight
2. Responsiveness: rapid integration of advanced technologies
3. Innovation: adapt practices that reduce cost and cycle time
4. Discipline: use of program baseline parameters as control objectives
5. Effective Management: decentralization to the extent practicable1
These characteristics have led to an increased focus on flexible development approaches that include
Agile philosophies and integrated program management tools such as Earned Value Management.
Background
Agile philosophies promote rapid incremental product deliveries, provide flexibility to respond to
changing requirements, and advocate close customer collaboration. A major aspect of Agile is that
changes to requirements, design details, or functional capabilities can be incorporated based on
customer value, at any stage of the development cycle. While Agile is primarily used on software
development projects, Agile methods are being used for complex system and hardware developments
as well.
Agile for software development in the DoD is still an emerging product development approach. To be
effective, the adoption of Agile methodologies must be integrated with existing DoD program
management (PM) and system engineering (SE) processes. EVM is a disciplined integrated program
management tool used to provide joint situational program awareness. EVM is used to measure
technical progress against a baselined plan, independent of the consumption of resources. EVM is not
tied to any specific development methodology and provides decision-makers with objective cost at
completion forecasting as well as dollarized values of accomplishments and variances to the baseline
plan. The requirement for EVM demands that performing contractors maintain an EVM System (EVMS)
consistent with the 32 guidelines contained in the Electronic Industries Alliance Standard-748 (EIA-748)
document. For DoD programs, EVMS implementations are evaluated in accordance with the DoD Earned
1
DoDI 5000.01, “The Defense Acquisition System,” May 2003

Value Management System Interpretation Guide (EVMSIG)2
. As a result, a contractor’s EVMS provides
the structure to establish and maintain a credible Performance Measurement Baseline (PMB), which is
the plan to accomplish a given contractual scope of work.
Agile and EVM are complementary when properly implemented together, and help enable a robust
overall management process. In order to be effective, Agile must be evaluated for its applicability on a
program-specific basis and tailored to best align with programmatic and contractual requirements.
Introduction
The origins of Agile Development can be traced back to 1957 to the incremental development of a large
simulation by IBM’s Service Bureau Corporation for Motorola.3
By the mid-1980s the DoD formally
recognized the value of “adaptive software development” in the DoD’s Military Standard for Software
Development (DOD-STD-1679A). Throughout the 1990s, several other “lightweight” iterative
development methods emerged including Dynamic Systems Development Method (DSDM), Scrum, and
eXtreme Programming (XP). These methods, along with others, became collectively known as Agile
methodologies. The tenets of Agile were codified with the creation of the Agile Manifesto in 2001. The
Manifesto emphasizes the following major concepts:
• “Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.
…while there is value in the items on the right, we value the items on the left more.”4
For example,
though the ability to respond to change is valued over following a plan, having and adhering to a
plan remains essential for project completion.
In March of 2009, the Defense Science Board Task Force on DoD Policies and Procedures for the
Acquisition of IT recommended that “The USD (AT&L) should lead an effort in conjunction with the Vice
Chairman, Joint Chiefs of Staff, to develop new, streamlined, and agile capabilities (requirements)
development and acquisition processes and associated policies for information technology programs.”5
On October 28, 2009 Congress enacted the National Defense Authorization Act for Fiscal Year of 2010
which required the “Secretary of Defense [to] develop and implement a new acquisition process for [IT]
systems.”6
This included several principles of Agile development such as early and continual
involvement of the user, multiple rapidly executed increments or releases of capability, early successive
prototyping to support an evolutionary approach, and a modular open-systems approach. In 2013, the
Deputy Assistant Secretary of Defense for Systems Engineering stated in a briefing that DoD military
systems must be “designed explicitly to have capacity to adapt and adjust to maintain relevance and
operational advantage in an environment of change.”7
2
Department of Defense Earned Value Management System Interpretation Guide, 2015.
3
C. Larman and V. R. Basili, "Iterative and Incremental Development: A Brief History," Computer, pp. 47-56, 11 June 2003.
4
http://www.agilemanifesto.org/
5
Defense Science Board, "The Report of the Defense Science Board Task Force on Department of Defense Policies and Procedures for the
Acquisition of Information Technology," OUSD (AT&L), Washington, DC, 2009.
6
National Defense Authorization Act for Fiscal Year 2010, 2009.
7
S. Welby, Deputy Assistant Secretary of Defense for Systems Engineering, “Thinking About Agile in DoD,” AFEI Agile for Government Summit,
November 2013,

The origin of EVM can be traced back to the 1967 issuance of DoDI 7000.2 “Performance Measurement
for Selected Acquisitions.”8
Since that time, EVM has been acknowledged by both Industry and the
Federal Government as one of the most effective tools for planning, executing, maintaining, and
reporting integrated cost, schedule, and technical status of an executing contract. EVM is a method for
developing, baselining, and tracking a plan throughout execution and is based on pre-determined
objective criteria. Although EVM is imposed as a contractual requirement, it does not mandate or
prevent the use of other disciplined integrated program management methodologies.
In 2009, DoD established the Performance Assessments and Root Cause Analyses (PARCA), a directorate
in the Office of the Assistant Secretary of Defense for Acquisition, to serve as the DoD focal point for all
policy, guidance, and competency relating to EVM.9
In July of 2014, PARCA met with representatives
from various DoD Services and Agencies to discuss the implementation of both EVM Agile development
practices together on DoD programs. As a result, PARCA launched an initiative to explore the joint
applicability of the two methodologies with stakeholders from the Office of the Secretary of Defense
(OSD), the Services, the Intelligence Community (IC), Defense Acquisition University (DAU), and the
National Defense University (NDU). This initiative included an action to examine issues, synergies,
challenges, and best practices in the utilization of both Agile and EVM in industry.
Agile and EVM System Compliance
The DoD EVMSIG, provides the overarching DoD interpretation of the 32 Guidelines where an EVMS
requirement is applied. It serves as the authoritative source for EVMS interpretive guidance and is used
as the basis for the DoD to assess EVMS compliance to the 32 Guidelines. The DoD EVMSIG provides the
flexibility for contractors to utilize a disciplined development methodology. Agile, as a product
development methodology, can exist within the disciplines required for EVMS compliance. However,
certain considerations must be addressed in order for Agile and EVM to coexist.
1. Organization and the WBS
Within DoD, a Work Breakdown Structure (WBS) is an organized decomposition of a project’s work
scope into manageable, product-oriented elements. The WBS facilitates communication between
the government and the contractor and allows for the assignment of resources and subsequent
tracking of progress. The DoD uses the MIL-STD-881C10
to pre-define the top-level program WBS,
and provides for a common structure across product lines to allow for effective Cost and EVM
reporting.11
The primary purpose of the 881C WBS templates is to support standardized, historical
data across similar program platforms.
a. WBS and 881C: The WBS reported for EVM can align to a workflow-based waterfall
development oriented hierarchy as found in MIL-STD-881C12
(see Figure 1). However,
an outcome-based Agile structure that focuses on customer driven deliverables (see
Figure 2) is also acceptable. Both WBS hierarchies are product-based and supported by
the DoD EVMSIG and MIL-STD- 881C.
8
W. Abba, "How Earned Value Got to Prime Time: A Short Look Back and Glance Ahead," Measurable News , p. 4, 1 March 2001.
9
http://www.acq.osd.mil/parca/
10
“DEPARTMENT OF DEFENSE STANDARD PRACTICE WORK BREAKDOWN STRUCTURES FOR DEFENSE MATERIEL ITEMS,” October 2011
11
Cost and Software Data Reporting (CSDR) requires strict adherence to 881C (see the DoD 5000.04–M–1. Cost and Software Data. Reporting
(CSDR) Manual. April 18, 2007)
12
The waterfall model is a sequential design process in software development in which progress is seen as flowing steadily towards completion
through the phases of design and development

Figure 1 - SW Development MIL-STD-881C Appendix K WBS breakout
Figure 2 - Possible Agile SW Development MIL-STD-881C WBS breakout. Not prescriptive.
b. The product backlog and the WBS: Agile projects often utilize the product backlog to
create the WBS. The product backlog contains 100% of the contract scope and is
commonly defined as “…a list of features or technical tasks which the team maintains
and which, at a given moment, are known to be necessary and sufficient to complete a
project or a release.”13
In the product backlog hierarchy, a capability14
directly relates
to the Control Account level. To understand the relationship of the WBS to the backlog,
the contractor should document the linkage of the WBS to the capabilities in both the
backlog and EVM System Description.
c. Requirements traceability: As system requirements are decomposed into capabilities
and features,15
the derivation should remain traceable and integrated with the
contractor's proposed and extended Cost WBS, control accounts, work packages and
planning packages, as applicable. Each hierarchical level of decomposition should have a
13
Agile Alliance , "Guide to Agile Practices," 2015. [Online]. Available: http://guide.agilealliance.org/guide/backlog.html.
14
The term “capability” refers to a group of features that are traceable to the technical and operational requirements of the product being
delivered

set of clear and documented completion acceptance criteria to ensure that the basis of
performance measurement in the EVMS is consistent and traceable.
2. Planning and Scheduling
The EVMSIG states that “The focus of…Planning, Scheduling, and Budgeting…is to develop plans and
strategies to achieve the desired program cost, schedule, and technical objectives.” This focus
includes how contractual work scope is decomposed and how the integrated master schedule (IMS)
is developed. The establishment of a time-phased Program Performance Measurement Baseline
(PMB) is a critical aspect of EVM. The PMB is the foundation for integrating scope, schedule, and
budgets into a plan against which accomplishments will be measured. The IMS establishes and
maintains the relationship between technical achievement and progress status. EVM requires
establishment of the baseline for all authorized work within the full period of performance, although
detailed planning is only required for the near-term work.
The use of Agile tools or systems for this purpose is supported by the tailoring and system concepts
allowed by EVM. In an Agile environment, a product roadmap16
generally is the basis from which a
plan (IMS/PMB) is established.
Figure 3 provides a representation of the product backlog hierarchy for planning and scheduling.
The capabilities and features define scope and have an assigned budget which is under baseline
control.
Figure 3 - Features support the completion and delivery of Capabilities. In the product backlog, Capabilities directly relate to
the Control Account level of the WBS.
In Figure 4, the stories17
(and any other hierarchical elements) below the dotted line describe the
detailed means of accomplishing the scope of a feature (see section 2.b).
15
The term “feature” in Agile refers to a pre-determined functionality set that delivers value to the customer (see reference section for more
information).
16
The product roadmap is a high-level plan for when capabilities/features will be accomplished over time (see
http://scaledagileframework.com/roadmap/)
17
The term “story” is often used to refer to activities that contribute to the completion of a Feature

Figure 4 - A potential representation of an Agile product backlog hierarchy
a. Decomposition of work scope: In an Agile environment, contractual program
requirements are broken down into capabilities, which in turn are further decomposed
into features (Features generally represent the point at which Agile execution and EVM
progressing align). The product backlog also breaks down the feature into lower-level
work items which are often referred to as stories. The completion of stories often
contributes to the completion of a feature. It is a hierarchical relationship. The product
roadmap identifies the sequence in which features and capabilities are completed and is
the tool generally used as a mechanism to assist in the development of the baseline to
accomplish the scope of work. The product roadmap supports and should be traceable
to the work packages, planning packages, and summary level planning packages in the
program Performance Measurement Baseline (PMB)18
, IMS, and the Control Account
Plan (CAP).
b. Time-phasing of work: EVM requires the time phasing of all work so that the
Government and performing contractors have a common understanding of how the
work is will be performed. The mechanism for developing the PMB may include the use
of documented Agile techniques for plan creation. However, the PMB must capture all
work scope and meet the intent of the EVMSIG. A typical Agile environment calls for a
backlog of capabilities with an associated Agile roadmap that lays out the strategic
delivery of the capabilities over time. Release timeframes are often determined from
the roadmap and represent the time box to accomplish a given set of features19
.
Capabilities and features for future releases are placed in planning packages, per the
contractor’s EVM System Description. The government customer reviews the plan at an
Integrated Baseline Review and during various events throughout the life of the
contract.
c. Underpinning the IMS: The EVMSIG allows for other tools, such as enterprise resource
planning (ERP) or manufacturing resource planning (MRP) systems, to support higher
level/summary tasks and milestones in an IMS. These MRP/ERP systems manage the
18
A PMB is a time-phased resourced plan against which the accomplishment of authorized work can be measured.
19
Agile planning and execution periods, often referred to as releases, do not necessarily correspond to the formal contractual delivery
milestones. Though the term release has been used in the past to identify these delivery milestones, the delivery of functionality is now
commonly referred to as a deployment.
Capabilities
Features
Stories

finite details of labor assembly and material resourcing while balancing the timing of
purchases to satisfy just-in-time principles. An Agile tool or system, in conjunction with
the backlog, provides similar detailed task maintenance. Progress in the IMS can be
summarized from status in the Agile management tools. The Agile process for statusing
and forecasting, which supports IMS status updates, should be documented by the
contractor in their EVM System Description. Note, the IMS must maintain a level of
detail that provides the Government with actionable information and is sufficient to
determine critical and/or driving paths through selected milestones.
d. Rolling wave planning: EVM allows for an incremental planning process often referred
to as rolling wave planning20
. The planning window is documented in the contractor’s
EVM System Description and the duration of the planning window is typically three to
nine months. When rolling wave planning occurs, planning packages (and summary level
planning packages) are detail-planned and the IMS is updated to reflect that detail
planning. Agile release planning is similar to EVM rolling wave planning. The release
cadence window is generally determined based on the nature of the work but is often
three to six months in duration. During release planning, future capabilities are detail
planned into features that can be accomplished during the subsequent release. The
methods and timeframe for Agile planning activities should be documented in the EVM
System Description and program procedures if applicable.
e. Freeze period: The EVMSIG states that, “In order to solidify the PMB for accurate
performance measurement, it is necessary to establish a freeze period. During the
freeze period, changes to the PMB are limited to maintain its integrity. At a minimum,
detail planning of planning packages must occur prior to the commencement of that
work within the freeze period.” The definition of a contractor’s freeze period, including
the mechanics and rules for controlling baseline changes during that timeframe should
be documented in the contractor’s EVM System Description.
3. Measuring progress
Work scope should have clearly defined, objective, technical completion criteria that is documented
prior to starting any specific effort. This is true regardless of the use of EVM and/or Agile. The
criteria should be established either before or during the detail planning/release planning process at
the appropriate level of the WBS.
a. Progress tied to scope completion: In Agile, progress of a capability is based on the
technical completion of each of its features, which in turn is based on the
accomplishment of the feature’s acceptance criteria. It is imperative that progress is tied
to the completion of scope (technical progress) and not the completion of time boxed
events such as sprints. As with EVM, the mechanism/technique used for taking
performance against completion of a specific scope of work must be documented. To
claim work as completed, the Agile system must support the EVM system in
demonstrating that all of the objective technical completion criteria for that work has
been met. Agile procedural documentation, particularly addressing processes that occur
below the feature level, is an essential part of providing the trace that shows how Agile
processes support or generate the EVM performance status reported to the
Government program office.
20
The continuous process of converting planning packages into control accounts and control account planning packages into work packages.

b. Claiming performance: EVM guidelines emphasize the use of appropriate performance
measurement techniques based on the nature of the work. The EVMSIG states that the
contractor must have information (Quantifiable Backup Data, or QBD) that supports the
EV performance claims for each work package/control account. Similarly, Agile
programs utilizes QBD to substantiate performance claims. Stories are often assigned
value based on size, complexity and/or risk. These values become the necessary
underpinning QBD for claiming performance. The usage of stories to measure progress
must be disciplined and consistent while following certain guidelines: all stories reflect
technical accomplishment towards a feature; once established, story point values do not
change; stories can be added or removed from the QBD through the development
process to support technical completion of a feature. The process by which stories are
used to in conjunction with the selected EVT must be documented and must not conflict
with the contractor’s EVM System Description.
EVM measures progress against the detailed planned activities for a given
reporting period (i.e. accounting month). In Agile, Features often span several months
and the measure of progress is relative to the technical completion of a feature and not
to the completion of a reporting period.
c. Agile and dollarization: The contractor should define, within its EVM System
Description, the level at which dollarization occurs in the system. This is true whether or
not Agile is implemented and should be testable during routine surveillance. The
relationship between Agile performance metrics and EVM status should be understood
by all stakeholders.
d. Forecasting and Estimates at Complete: The EVMSIG states that programs will maintain
an Estimate at Complete (EAC) by developing “revised estimates of cost at complete
based on performance to date ... and estimates of future conditions.” This periodic
reassessment of remaining requirements contributes to program success for both the
Government and the contractor. The development of an EAC on a program that employs
Agile philosophies is similar to the process required for traditional software programs
and projects. The remaining work is analyzed to provide an assessment of the effort
required to deliver the remaining capabilities and features.
The metrics generated from an Agile tool are typically used to establish a forecast
Estimate to Complete (ETC). An Agile forecast reflects the attributes of a properly
maintained EAC because it is continuously adjusted to reflect program progress. It
enhances management value by tying projected costs for the remaining work to credible
sources and ensures any decision regarding the allocation of future resources is based
on valid data. Although it is not explicitly stated, the use of Agile tools for the estimation
process is supported by the EVMSIG. The methods for the identification of forecasts and
estimates between Agile tools and the EVMS should be documented in the EVM System
Description.
4. Baseline Maintenance
a. Maintaining the backlog: Backlog maintenance is critical to the effective management
of an Agile program. It is a best practice to review the backlog and product roadmap
during an Integrated Baseline Review (IBR) and periodically with the Government
customer throughout the duration of the contract. It is imperative that the Government

remain actively involved in the release planning process because of its potential to
affect the PMB. Changes to work scope must follow the established rules for work
authorization, baseline management, and change control as described in the EVMSIG.
Items within the Agile product backlog, at the feature level (i.e., work package) or
higher, have an assigned budget under baseline control. Removal or addition of any
feature-level or higher item from or to the backlog should be documented and
performed in accordance with system baseline change processes.
b. Scenarios for consideration:
i. Work toward the completion of a particular feature is ongoing and is scheduled
to finish at the end of the current sprint. Once the sprint ends, one of the
planned stories for that feature has not been completed and the feature has not
met its completion criteria.
The team forecasts the story to complete in a future sprint. The result is the
work package would have a negative schedule variance because the scope of
work (feature) associated with the work package did not complete within the
baselined period (assuming no other variances are affecting the work package).
ii. A feature will be moved from the current release to a subsequent release.
A feature is part of the baseline and therefore if it changes, it must adhere to
the baseline change control process. Baseline change could be processed in
accordance with the contractor’s approved change control process, taking into
consideration whether the change is contractual or an internal management
decision. If work has already begun, then the work package should be shut
down by the generally accepted practice of setting BCWS to BWCP, and replan
the remaining work package budget (BCWS) in the subsequent release
identified.
iii. The team will need to complete additional stories in order to meet the
completion criteria of a particular feature (i.e. there is no contractual scope
change).
If the additional stories are still consistent with the acceptance criteria of the
feature, and simply provide greater granularity to how work will be performed,
then no re-baselining/replanning is required. The originally planned scope (at
the feature/work package level) is unchanged and the likely result will be a
negative schedule variance as the work would be considered more complex
than originally thought. The amount of performance claimed would remain the
same, but the percent complete would change with an increase in the amount
of effort required to complete the same scope of the feature.
iv. The team will be able to meet the objective technical completion criteria for a
particular feature without having to complete all the planned stories.
This discovered efficiency results in no change to the work scope, as the work
would be seen as being less complex than originally thought. The likely result
would be a positive schedule variance during the completion of the work scope
and a positive float for the IMS upon completion. Also, with the associated
hours not expended, a positive cost variance may occur.

v. A need for a new feature is identified and it must be completed in order to
satisfy the completion criteria for a particular capability. It is an addition to the
baselined work scope.
If the added feature is not within the scope of the contract, the contractor shall
receive contractual direction, and the associated contract modification with
contract value and budget from the customer to begin work on the new feature.
The new scope adds to the total amount of budget and performance that can be
claimed, but does not affect the performance taken on already completed work.
The Control Account where the feature was added and the overall contract
percent complete value will decrease due to the added scope, but the amount
of performance previously claimed does not change.
If the added feature is within the scope of the contract but not in the scope of
the Control Account, then the contractor should follow their EVM System
Description for newly identified in-scope effort, and likely distribute
Management Reserve to plan and budget the resources for the new Feature.
Again, the Control Account and overall contract percent complete value will
decrease with the added effort, but this does not affect the amount of
performance previously claimed.
vi. The team was able to meet planned objective technical completion criteria for all
planned Features in the release and have additional capacity to perform more
work given their observed productivity.
A baseline change is required to allow the team to pull work out of the product
backlog (in a planning package, not yet detail planned). The contractor would
initiate a Baseline Change Request (BCR) and convert the planning package into
a work package in accordance with their EVM System Description. Work pulled
from the product backlog would be effort the team believed could be
completed under existing constraints for upcoming releases and program
milestones.
If the work to be performed as a result of the additional capacity is already in
the baseline plan as a work package, a BCR would not be required and the
portion of that work package completed in the current Release would result in a
positive schedule variance.
Agile and Maintaining EVM System Compliance
The Integrated Program Management Report (IPMR) Data Item Description (DID)21
contains specific
requirements for EVM data reporting to the Government. The IPMR allows tailoring to meet the needs
of the Government program office. To enhance customer collaboration, consideration should be given
for the buyer to have access to the supplier’s Agile tools in the interest of transparency.
21
See http://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=278901

1. Standard terminology and metrics
Currently, there is no DoD standard terminology for Agile processes and artifacts. It is imperative
for the government PMO and a contractor to define the Agile terms and process at the beginning of
negotiations for a contractual scope of work. The EVMSIG and the IPMR, along with other DoD and
Service/Agency policies, define EVM requirements and are included in RFPs where applicable. The
performing contractor should provide information to the PMO regarding how Agile processes are
incorporated in the implementation of their EVMS.
2. Agile metrics and EVM metrics
As with the discussion on definitions, there are no DoD standards for Agile methodology metrics.
Metrics such as Velocity, Burn-down/Burn-up, etc. must be agreed upon by the performing
contractor and the government PMO. Agile metrics may be included in the IPMR Format 5 as
supporting documentation for the status of work performed, but should not supplant the typical
EVM metrics. As with the link between EVM status and technical performance, Agile metrics should
provide status that supports and aligns with similar EVM metrics.
3. Traceability
Generally, Agile processes influence segments of work below the reporting level for the IPMR.
Performance status at the level where Agile execution occurs should underpin the performance
information at the level where EVM is reported (usually through the features). Since they are
typically the criteria for performance, if the stories and features for a given scope of work
experience favorable performance, both the Agile metrics and the EVM metrics should reflect
favorable performance. The same is true for unfavorable performance as well. Format 5 variance
analysis is required at the IPMR reporting level; the performing contractor should provide
information from the Agile system to help support variance explanations.

Agile Reference Terms
Capability Term frequently used interchangeably with Epic to describe a high level system
functionality defined by the government to meet a specific required need. All
Capabilities should have clearly defined objective technical completion criteria.
Capabilities are typically found at or above the Control Account level of the WBS and
are usually composed of multiple Features.
Epic See Capability.
Feature Term used to describe a discrete system functionality defined by the government to
help meet the specific completion criteria of a Capability. All Features should have
clearly defined objective technical completion criteria. Features are typically found at
the Work Package level of the WBS and can typically be completed in a single Release.
Story Term used to describe activities that contribute to the completion of a Feature and
can be completed within a single Sprint.
Release Term used to describe a concrete time box or cadence used to complete Features.
Release duration can vary, but is typically three to six months. Many practitioners use
the Release cadence as their rolling wave planning period.
Sprint Term frequently used interchangeably with Iteration to describe a concrete time box
or cadence used to complete Stories. Sprint duration can vary, but is typically two to
four weeks.
Iteration See Sprint.

Agile and earned value management

More Related Content

Similar to Agile and earned value management (20)

More from Dr Ezzat Mansour (20)

Recently uploaded (20)

Agile and earned value management