DI-IPSC-82298

Product Backlog

Approval DateOctober 3, 2019

AMSC NumberF10101

Preparing Activity19

Project NumberIPSC-2019-010

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.

Supersedes

—

DI-IPSC-82297

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

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. The Product Backlog is a key product to manage development when using Agile methodologies.

The Product Backlog can be used in conjunction with the Product Roadmap (DI-IPSC-82297). The Product Roadmap shows the strategy used to drive the priorities in the Product Backlog. When both the Product Backlog and the Product Roadmap are requested in the Contract Data Requirements List (CDRL), they present a coordinated representation of the needed development for the software or system.

This 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 Backlog shall be in the form of an output exported from the agile management tool, including attributes such that the Government has the ability to edit, copy, and search the Product Backlog content.

3Content.The Product Backlog shall be organized in a hierarchy where Epics are decomposed into Features and Features are decomposed into User Stories with bi-directional traceability between each level. Epics are a set of features to provide a needed capability. Features are a capability or service that fulfills a stakeholder need. User Stories are the smallest unit of requirements, written from a user's perspective, describing how the software or system will be used. The Product Backlog shall include the following items:

3.1A prioritized list of the following:

3.1.1Epics.

3.1.2Features.Each feature shall include a benefit hypothesis and acceptance criteria to be delivered in 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/.)

3.1.3User Stories.User Stories shall include the contents specified in Table 1 below with items a-h being required elements and items i-n being included as applicable.

3.1.4Technical Stories.A Technical Story, also known as an Enabler, identifies important algorithms, architecture, or infrastructure needed to deliver future user value. Technical Stories shall contain the contents as specified in Table 1 above, except for (a), as a Technical Story can take any format.

3.1.5Defects.Any condition that deviates from defined expectations (e.g., requirement 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.1.6Technical Debt.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.2The status of development shall be shown by denoting the completion of Epics, Features, User Stories, Technical Stories, Defects, and Technical Debt against the Definition of Done. The Definition of Done is an agreed upon checklist of the work that the development team is expected to finish successfully before declaring the work ready for delivery. The status of development shall also include the following:

3.2.1Status for each item (e.g., Epic, Feature, User Story, Technical Story, Defect, and Technical Debt) showing either when the item was completed, or, if known, when the work is planned to be performed.

3.2.2Metrics for each Build, including:

3.2.2.1Development progress profile (e.g., percent of work complete, cumulative backlog items, release burndown).

3.2.2.2Software productivity (e.g., velocity in story points per sprint, cumulative workflow).

3.2.2.3Software quality and defect rates (e.g., defects per 1000 lines of code, test coverage).

3.3All items in the Product Backlog shall contain the following configuration control information:

3.3.1Record of all changes, including timestamp (date and time) when changes were made and identity of who made the changes.

3.3.2Record of approval, if required, for item changes, including timestamp (date and time) when approval occurred and identity of who approved.

3.3.3Record of new items added, including timestamp (date and time) when addition occurred and identity of who added the item.

3.3.4Record of removal of an item, including timestamp (date and time) when removal occurred, identity of who removed the item, and rationale for removal.

References

Copies of DoDI 5000.02 can be obtained at: https://www.esd.whs.mil/

Figures

Figure Table 1. User Story Contents

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer