Software Acquisition

AAF  >  Software Acquisition  >  Define Capability Needs > Minimum Viable Product and Minimum Viable Capability Release

MVP, MVCR, and Deployment Frequency

How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

 

 

Reference Source: DODI 5000.87 Glossary

 

MVP: An early version of the software to deliver or field basic capabilities to users to evaluate and provide feedback on.  Insights from MVPs help shape scope, requirements, and design.

 

MVCR: The initial set of features suitable to be fielded to an operational environment that provides value to the warfighter or end user in a rapid timeline.  The MVCR delivers initial warfighting capabilities to enhance some mission outcomes.  The MVCR is analogous to a minimum marketable product in commercial industry.

 

Reference Source: DODI 5000.87 Section 3.3.b

 

The PM and the sponsor will use an iterative, human-centered design process to define the minimum viable product (MVP) recognizing that an MVP’s definition may evolve as user needs become better understood. Insights from MVPs help shape scope, requirements, and design.

 

The PM and the sponsor will use an iterative, human-centered design process to define a minimum viable capability release (MVCR) if the MVP does not have sufficient capability or performance to deploy into operations. The MVCR delivers initial warfighting capabilities to enhance mission outcomes. The MVCR for applications programs must be deployed to an operational environment within 1 year after the date on which funds are first
obligated to acquire or develop new software capability including appropriate operational test. If the MVP version of the software is determined sufficient to be fielded for operational use, the MVP will become the MVCR.

MVP / MVCR Guidance

Reference Source: USD(A&S) Guidance

The MVCR is akin to the Minimum Marketable Product (MMP) or Minimum Marketable Release (MMR) in commercial industry terms. Definition and delivery of the MVP, MVCR, and product roadmap inform a key business decision at the start of the execution phase. Programs must distinguish between an MVP (designed to deliver early functionality to inform the development process) and an MVCR (designed to deliver the minimum set of operational capability that provides enough value to the Warfighter/end user).

Minimum Viable Product

The main purpose of the MVP is to validate the need for the capability and gain user feedback on the new capability. The MVP must be sized as a manageable, demonstrable set of scenario threads through a minimal set of features. The MVP, by definition, should not include all the capabilities identified in the product roadmap. The MVP accelerates the learning process by delivering the minimum functionality necessary to elicit meaningful feedback from users quickly and, thus, enable continuous learning and iterating by the product team. Feedback from users can also state that the product/service is not needed, negating the need for future iterations.

An MVP is typically defined during project initiation and refined during subsequent planning periods. If external resources (i.e., contractors, system integrators, end users) are part of the team they take part in the MVP definition process.

Generating an MVP requires that programs put product teams and processes in place and that the teams execute the necessary processes. While the MVP is typically deployed to a production environment, programs may have constraints and/or needs that require a staging environment or other option for MVP deployment. This is acceptable and should be identified at the outset.

The Product Owner / Product Manager (collectively referred to as the Product Management team, for larger systems/solutions) and development team(s) need to work together to identify and agree upon the product MVP. The Product Management team is responsible for ensuring that the MVP provides business value, and the development team determines if the scope of the MVP is reasonable to allow delivery within the set period.

Minimum Viable Capability Release

An MVCR is designed to provide minimum capability that a Warfighter/end user can employ operationally. An MVCR has three key attributes:

Minimalistic: MVCRs must contain minimal capabilities that must be fielded to ensure acceptable safety, security, and performance. For example, a program cannot field a major software upgrade for an aircraft without airworthiness designation. MVCR releases of any scope should be minimal (as small as possible) but not to the detriment of the operational mission.

Rapid Validation: The MVP strategy relies on rapid user feedback to shape a product quickly. MVCR capabilities must be evaluated by testable measures of effectiveness. An essential part of the MVCR strategy is to establish early testing and validation that provide actionable feedback for timely updates.

Architecture: MVPs are often built in a software as a service (SaaS) and open source development ecosystem that is inexpensive, well understood, and stable. Where the MVP strategy takes a long-term, stable, and enabling architecture for granted, the MVCR strategy recognizes that architecture must be modular, well defined, and enduring to support the entire software lifecycle.

Maximize Use of Prototyping, Experimentation, and Minimum Viable Products.

A prototype or MVP in the hands of operators and engineers would accelerate learning and design of solutions beyond a team conducting a CBA or AoA. Portfolios should use the multiple prototyping pathways to the maximum extent before establishing a formal program or follow-on increment to shape scope and requirements. Iterative prototypes and MVPs would improve opportunities to exploit leading technologies and the chances of delivering high-value capabilities to Warfighters. 

Section 809 Panel

Deployment Frequency

Reference Source: FY20 NDAA Section 800

USE OF AUTHORITY. In using the authority under this section, the Secretary shall consider how such use will—

(A) initiate the engineering of new software capabilities quickly;

(B) demonstrate the viability and effectiveness of such capabilities for operational use not later than one year after the date on which funds are first obligated to acquire or develop software; and  – “This is the MVCR”

(C) allow for the continuous updating and delivery of new capabilities not less frequently than annually to iteratively meet a requirement. – “This is a Capability Release”

 

Reference Source: FY21 NDAA Section 835 Joint Explanatory Statement (Congressional Perspective)

Provide for delivery of capability to end-users not later than 1 year after funds are obligated noting that other Government-wide policy and best practices call for updates no less frequently than once every 6 months.

 

Reference Source: DODI 5000.87

1.2.e. Programs using the software acquisition pathway will demonstrate the viability and effectiveness of capabilities for operational use not later than 1 year after the date on which funds are first obligated to develop the new software capability. New capabilities will be delivered to operations at least annually to iteratively meet requirements, but more frequent updates and deliveries are encouraged where practical. For programs using the embedded software path, this annual update applies after initial operational acceptance of the system in which the software is embedded and should be aligned with the associated system’s schedule. Before the operational acceptance of the system in which the software is embedded, software deliveries will be delivered to an operationally representative environment at least annually.

 

3.3.b.(5) The PM and the sponsor will use an iterative, human-centered design process to define a minimum viable capability release (MVCR) if the MVP does not have sufficient capability or performance to deploy into operations. The MVCR delivers initial warfighting capabilities to enhance mission outcomes. The MVCR for applications programs must be deployed to an operational environment within 1 year after the date on which funds are first obligated to acquire or develop new software capability including appropriate operational test. If the MVP version of the software is determined sufficient to be fielded for operational use, the MVP will become the MVCR.

 

First Funds Obligated Definition:  Date that funds have been obligated for a development activity AFTER official entry into the SWP.

Deployment Frequency Guidance

Reference Source: USD(A&S) Guidance

The Software Pathway can be used by nearly any DoD system type given its nuanced treatment of deployment frequency. This paper is intended to provide clarity on deployment frequency and target environment expectations.

Commercial Expectations and Trends

DoD’s goal is to approximate commercial industry software and digital product delivery to achieve competitive advantage.  Commercial industry, from SpaceX to Netflix, use CI/CD pipelines or DevSecOps pipelines and tool chains to automate build test and release.

For cloud-native systems and applications, digital product delivery, commercial software practices and modern architectures (e.g., containerization and micro-services) are used to continuously deliver and deploy new releases, features and fixes at a relentless pace.  Any given product line might release new features every half-hour, or less. Across all products and services, industrial software factories are releasing new code in periods marked by seconds and total annual deployments in the tens of millions. Darwinian market forces have forced companies (large and small) to adopt Lean Startup, Design Thinking, Site Reliability Engineering, Chaos Engineering, Agile and DevSecOps to achieve security, reliability, and speed in digital product delivery.

Google Support 4 million builds per Day
Amazon Releases code to production every 11.6 seconds
SpaceX

Pushes up to 17,000 changes per day

Maintains 9 different rockets code baseline with 50 developers

Netflix

500 code releases per day

Pioneered Chaos Testing in Ops

Indeed, across small tech startups and large businesses that are transforming, continuous deployment is becoming the norm to compete in the 21st century marketplace.  This level of speed and responsiveness is also  necessary for the battlefield as autonomy and AI dominate warfare in the next decade and beyond.  Yet, in stark contrast…

DoD’s historical average release cycle is 2-10 years

The good news is more and more leading programs across the DoD are deploying code faster some within hours and many more within months.  The bad news is that its still not happening at the scale and pace needed to win that inevitable near-peer fight that is on the horizon.  We need to move faster which is why Deployment Frequency is such a critical measure for the Software Acquisition Pathway.

FAQs

1. How do you define a Minimum Viable Capability Release?

“MVCR: The initial set of features suitable to be fielded to an operational environment that provides value to the warfighter or end user in a rapid timeline. The MVCR delivers initial warfighting capabilities to enhance some mission outcomes. The MVCR is analogous to a minimum marketable product in commercial industry.”  – DODI 5000.87

The MVCR is akin to the Minimum Marketable Product (MMP) or Minimum Marketable Release (MMR) in commercial industry terms. Definition and delivery of the MVP, MVCR, and product roadmap inform a key business decision at the start of the execution phase. Programs must distinguish between an MVP (designed to deliver early functionality to inform the development process) and an MVCR (designed to deliver the minimum set of operational capability that provides enough value to the Warfighter/end user).

An MVCR is designed to provide minimum capability that a Warfighter/end user can employ operationally and has three key attributes:

  • Minimalistic: MVCRs must contain minimal capabilities that must be fielded to ensure acceptable safety, security, and performance. For example, a program cannot field a major software upgrade for an aircraft without airworthiness designation. MVCR releases of any scope should be minimal (as small as possible) but not to the detriment of the operational mission.
  • Rapid Validation: The MVP strategy relies on rapid user feedback to shape a product quickly. MVCR capabilities must be evaluated by testable measures of effectiveness. An essential part of the MVCR strategy is to establish early testing and validation that provide actionable feedback for timely updates.
  • Architecture: MVPs are often built in a software as a service (SaaS) and open-source development ecosystem that is inexpensive, well understood, and stable. Where the MVP strategy takes a long-term, stable, and enabling architecture for granted, the MVCR strategy recognizes that architecture must be modular, well defined, and enduring to support the entire software lifecycle.

2. What does “demonstrate operational use” mean?

Quite simply, the capability has been delivered, is approved for use and is available to the warfighter.

  • This means the software has been tested in accordance with the test plan (DT/OT).
  • This means the software has received the appropriate ATOs and met requirements for Operational Acceptance (however those are defined).
  • This means that any additional Certifications (Weapon Safety, Air Worthiness, Nuclear, etc.) are in-place.

The means to achieve this scaling of OT, Cyber, Certifications and other testing with small batch deliveries is by:

  • Using a risk based (or other methodology) approach that enables developers, users and other stakeholders to clearly distinguish when capabilities warrant quick release versus detailed testing.
  • Maintain close collaboration with key stakeholders (functional and operational) to ensure that the testing approach devised has clear buy-in from the affected community.

For Embedded Systems, the above applies except the software delivery can be to an operationally representative system (TSIL, Test Fleet, etc.).

The A&S Acquisition Enablers shop is also actively working with the test community (in an effort called T&E Ignite) to modernize DT/OT so that it more closely mirrors the private sector.

Embedded Software Definition: software with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints, or software applications embedded in a platform (e.g., air vehicle, ground vehicle, or ship). In the context of this issuance, embedded software does not apply to firmware or software dedicated to controlling devices.

3. Does that mean it is fielded in 12 months?

Yes, annual deliveries are the minimum statutorily required deployment frequency.

The actual goal however of DODI 5000.87 (and Congress) is 6 months or less with a bias for as frequent as possible. Our goal is for all DoD programs to field capability into production in hours or days – not months or years.  The policy does NOT require all capabilities to be delivered in one year or less, but that the program continuously deliver capabilities at least annually.  Cadence is key here.   Ideally SWP programs should be accelerating all timelines to be responsive to changes in operations, threats, technologies, budget, and feedback/performance of previous releases.  Therefore, the SWP emphasizes DevSecOps and continuous ATO (cATO) best practices. While the annual delivery may be achieved though standard Agile practices; achieving the speeds of days or hours is only possible using DevSecOps pipelines in conjunction with a cATO.

SWP Timelines for Embedded Systems

4. Who decides what the software acquisition program needs to demonstrate within a year after the date on which funds are first obligated to develop the new software capability?

 This is determined through the governance process established by the program with the user community.  The User Agreement should document these details which will help manage expectations for each software release.

Capability Releases are the continuous fielding of new capability or enhancements to the warfighter.  Programs need to strive to make releasing into production on-demand possible.  By having small batch commits ready to deploy, we minimize having to build on a fragile code base or accumulate technical debt which otherwise defers defect discovery to late-stage integration.

Conclusion

Winning a future fight with a determined adversary will be based on the ability of the DoD to quickly develop and field software into combat support and combat systems.  Therefore, it is critical that programs understand the importance of deployment frequency and work to build small batch changes that provide the ability to fail forward more easily, roll back, and continue delivering new capabilities needed by the Warfighter.  Programs and acquisition leaders should continue to streamline program, portfolio and enterprise processes to improve deployment frequency outcomes align with operationally relevant timelines.

Competitors, especially China, have made and continue aggressive efforts to negate long-enduring U.S. warfighting advantages and challenge the United States’ interests and geopolitical position.  They have studied, resourced, and introduced systems specifically designed to defeat the U.S. Air Force capabilities that have underpinned the American way of war for a generation.  While we and industry previously enjoyed the benefit of time, when U.S. Air Force dominance seemed unassailable, we are now seeing competitors outpace our current decision structures and fielding timelines.

General Charles Q. Brown, USAF

Note: If the below video(s) show a “Website Blocked” banner, try accessing the video via a non-DoD network. No sensitive content is contained in this video. Current DoD network policies to conserve bandwidth may be impacting the ability to view this video.