Product Backlog Item Data Object

Purpose

The Product Backlog Item represents a work item associated with a Digital Product that when fulfilled will be associated with a Product Release.

Types of work item vary depending on development methodology and may include epics, features, stories, story tasks, fixes, enhancements, and so on. Product Backlog Items describe the full range of work and artifacts required to complete the Product Release. This includes not only code and configuration information, but also the creation of other deployable artifacts under version control such as training material, user guides, and pricing tables.

A Product Backlog Item can be decomposed into a set of more granular Product Backlog Items; for example, a feature can be decomposed into user stories and related tasks. A group of Product Backlog Items can be assigned to a specific implementation phase, such as an iteration or sprint.

Key Attributes

The Product Backlog Item data object shall have the following key data attributes:

  • Id: unique identifier of the Product Backlog Item

  • Title: short description of the Product Backlog Item

  • Type: type of Product Backlog Item such as epic, feature, and story

  • Description: detailed description of the Product Backlog Item

  • Status: status of the Product Backlog Item

  • Parent Id: unique identifier of the parent Product Backlog Item (decomposition/refinement)

  • Budget: budget for the Product Backlog Item

  • Actual Spend: actual spend on the Product Backlog Item

  • Start Date: Product Backlog Item start date

  • End Date: Product Backlog Item completion date

  • Size: size of the Product Backlog Item; for example, in story points

  • Definition of Done: list of criteria which must be met before a Product Backlog Item is considered "done"

  • Priority: priority of the Product Backlog Item

  • Value: scoring of the Product Backlog Item in terms of business value

Key Data Object Relationships

The Product Backlog Item data object shall maintain the following relationships:

  • Product Backlog Item to Digital Product (n:1): a Product Backlog Item belongs to one Digital Product

  • Portfolio Backlog Item to Product Backlog Item (1:n): a Portfolio Backlog Item can be decomposed into one or more Product Backlog Items (refinement of Portfolio Backlog Items)

  • Product Backlog Item to Product Backlog Item (1:n): a Product Backlog Item can be refined into one or more sub-Product Backlog Items (parent and child Product Backlog Items)

  • Product Backlog Item to Product Backlog Item (n:m): a Product Backlog Item can be dependent upon or related to other Product Backlog Items

  • Product Backlog Item to Product Release (n:1): a Product Backlog Item will be associated with one Product Release; larger Portfolio Backlog Items which cannot be delivered in one release will need to be decomposed into sub-Product Backlog Items (refinement)

  • Product Backlog Item to Product Design (n:1): a Product Backlog Item can modify and/or realize a (part of the) Product Design

  • Product Backlog Item to Source (n:m): modifications in the source code need to be linked to a Product Backlog Item (with a merge request)

  • Product Backlog Item to Defect (n:m): a Product Backlog Item can be related to one or many Defect records in order to investigate and resolve the Defects

  • Product Backlog Item to Requirement (n:m): a Product Backlog Item must be associated with one or more Requirements (such as non-functional requirements); a new or changed Product Backlog Item may require creation or modification of one or more Requirements

  • Product Backlog Item to Test Case (n:m): a Product Backlog Item can have one or more Test Cases defined in the Test functional component