DI-IPSC-82297
Product Roadmap
The Product Roadmap describes the strategy for prioritizing and completing Epics and Features across a program's lifecycle and shows how development aligns with key program milestones, technical reviews, and test events.
Approval DateOctober 23, 2019
AMSC NumberF10100
Preparing Activity19
Project NumberIPSC-2019-011
OPR—
DTIC ApplicableNo
GIDEP ApplicableNo
Limitation—
Applicable Forms—
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantYes
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Application & Interrelationship
—
Use & Relationship
The Product Roadmap contains the strategy for prioritizing and completing the Epics and Features across the lifecycle of a program. Additionally, the Product Roadmap shows how the development fits with the key program milestones, technical reviews, and test events in the Integrated Master Schedule (IMS). The Product Roadmap is a key product to manage development when using Agile methodologies.
The Product Roadmap can be used in conjunction with the Product Backlog (DI-IPSC-82298). The Product Backlog contains the complete set of prioritized Epics, Features, and User Stories with bi-directional traceability to the program requirements and highlights known work yet to be completed. When both the Product Backlog and the Product Roadmap are requested in the contract deliverable requirements list (CDRL), they present a coordinated representation of the needed development for the software or system.
This data item description (DID) contains the format, content, and intended use information for the data deliverable resulting from the work task described in the solicitation.
Preparation Instructions
1Reference Documents.The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as specified in the contract.
2Format.The Product Roadmap shall be presented in graphical (e.g., Gantt chart) or tabular (e.g., table) format.
3Content.The Product Roadmap shall be based on Agile iterative cadence (e.g., number and length of time-boxed iterations, such as Sprints, for a delivery of a Build). A Build is defined as a testable, integrated subset of the overall capability, which, together with clearly defined decision criteria, ensures adequate progress is being made before fully committing to subsequent builds in accordance with Department of Defense Instruction (DoDI) 5000.02, Operation of the Defense Acquisition System, 5.c.(3)(c). (Copies of DoDI 5000.02 can be obtained at: https://www.esd.whs.mil/.) The Product Roadmap shall contain the following information:
3.1The planned and completed Builds over the timeframe of the program.
3.2The software versions released to the user (planned and already released).
3.3The following items assigned to each Build (planned and already completed):
3.3.1Epics, which are defined as a set of features to provide a needed capability.
3.3.2Features, which are defined as a capability or service that fulfills a stakeholder need.Each feature shall include a benefit hypothesis and acceptance criteria.
3.4The planned time allotted to address the following:
3.4.1Defects, which are defined as any conditions that deviate from defined expectations (e.g., requirements specifications, architectures, design documents, user manuals, plans, procedures, reports, standards, policy) or suitability (e.g., from a user's or other stakeholder's sound engineering judgment or experiences).Defects can be found during the review, test, analysis, integration, or use of products, or in any of the applicable documentation. Defect is synonymous with anomaly, discrepancy, error, fault, failure, incident, flaw, problem, gripe, glitch, or bug.
3.4.2Technical Debt, which is defined as rework that needs to be done by the development team as an easier, short-term solution was pursued, yet further changes are needed for improved rigor and resiliency of subsequent developments.
3.5The link between development activities and the key program milestones, technical meetings, and reviews shown in the IMS, to include the following information:
3.5.1When key program milestones occur in conjunction with the Builds, including:
3.5.1.1The key test events, including: integration with outside systems, tests requiring Government Furnished Equipment (GFE), and government Developmental and Operational Test and Evaluation (DT&E and OT&E).
3.5.1.2External constraints or system limitations that affect when Epics and Features can be developed.
3.5.2When efforts to maintain the development environment are accomplished to meet the needs of the developers and testers, including the following:
3.5.2.1Planned and performed configuration updates of the development and test environments.
3.5.2.2Planned and performed significant system infrastructure (e.g., commercial-off-the-shelf (COTS) and open source software) updates.
3.5.3When test data, data stubs, emulators, simulators, and connections with external systems are developed to support development, integration, and testing.
3.6The composition of the software development team(s) performing the work for each of the Features, including the following information:
3.6.1The number of software development teams that perform the work.
3.6.2Any other teams supporting the software development process, such as: systems engineering, combined development and operations (DevOps), and test teams.
3.7The metrics and analytics for the work planned and completed, including the following information:
3.7.1Progress indicators showing as-is and to-be states based on the latest metrics from the development.
3.7.2Expected burndown rates versus performed rates for completion of Features during the Builds.
3.7.3Defect burndown strategy for assigning current Defects to Sprints, which shall be based on the prioritization in the Product Backlog.
3.8All items in the Product Roadmap shall contain the following configuration control information:
3.8.1Record of all changes, including timestamp (date and time) when changes were made and identity of who made the changes.
3.8.2Record of approval, if required, for item changes, including timestamp (date and time) when approval occurred and identity of who approved.
3.8.3Record of new items added, including timestamp (date and time) when addition occurred and identity of who added the item.
3.8.4Record of removal of an item, including timestamp (date and time) when removal occurred, identity of who removed the item, and rationale for removal.
Schema v3.0Community-maintained · Verify against ASSIST 