Skip to main content

SOP for PBIs


SOP to create PBIs​

Defining the terms​

SOP (Standard of Practice): Effective development processes are critical to the success of
projects.

PBIs (Product Backlog Items): A product backlog item (PBI) is a single element of work in the product backlog. This can include specifications, new feature requests, bugs, or change requirements. Simply put, a PBI is an individual task that needs to be taken care of to improve the project or fix an issue.

Types of PBIs​

Epic: An Epic is an effort that is large enough that it can be split into smaller features. An epic often spans across multiple sprints, teams, and even across multiple projects. Epics break down development work into shippable components across teams and projects while keeping the work connected to the larger business initiatives.

Features: Features are more specific deliverable component of effort under Epics. A Feature should be the smallest increment of a “shippable component”. Features are made up of two or more User Stories that are required to achieve the deliverable component.

User Stories: User Story is a work item sometimes used interchangeably with Product Backlog Item (though they are arguably quite different). A User Story is the smallest unit of work that needs to be done to create a new behavior or change existing behavior. User Stories are commonly broken down into tasks.

  • Tasks: The smallest work type, tasks are also the only work type not designed to deliver value. Instead, tasks are a way to break a User Story or PBI into “bite size” chunks.

Bugs: A bug is a variation or deviation of the software application from the original business requirements. It is caused by an error in coding which causes incorrect or unexpected results from a software program which does not meet actual requirements.

Guidelines for creating PBIs​

Epics:

  • Due to the scope, creating an Epic should be handled by the Product Manager with the understanding that it aligns with long-term strategic objectives.
  • Epics should be created in ADO using the Epic Template. Instructions on how to apply a template can be found here.

Features:

  • Features will typically be created by the Product Manager, however, the development team is encouraged to create a feature if the following conditions are met:
    • The scope of effort will be greater than one User Story.
    • The feature has been discussed with the Product and Engineering manager(s) prior to creation.
    • The feature does not currently exist in the backlog.
    • The Product Manager(s) are tagged on the new feature for review and prioritization.
    • The feature is created using the Feature Template, and filled out with as much information as possible.
  • Features should be created in ADO using the Feature Template. Instructions on how to apply a template can be found here.

User Stories:

  • User Stories will typically be created by the Product Manager, however, the development team is encouraged to create a User Story if the following conditions are met:
    • The scope of effort will be one User Story.
    • The User Story is designed to create a new behavior or change existing requirements behavior.
    • The User Story has been discussed with the engineering manager prior to creation.
    • The User Story does not currently exist in the backlog.
    • Area & Iteration Path is set to "Empower". New tickets will not be brought into sprints without additional discussion regarding priority and urgency.
    • The User Story is flagged for 'QA Testable' if applicable.
    • The Product Manager(s) are tagged on the new User Story for review and prioritization.
    • The User Story is created using the User Story Template, and filled out with as much information as possible.
  • User Stories should be created in ADO using the User Story Template. Instructions on how to apply a template can be found here.

Bugs:

  • Bugs can be created by anyone on the team. The following conditions must be met when creating new bugs:
    • The scope of effort will be one defect.
    • The Bug is designed to correct existing requirements behavior.
    • The Bug does not currently exist.
    • Area & Iteration Path is set to "Empower". New tickets will not be brought into sprints without additional discussion regarding priority and urgency.
    • The Product Manager(s) and QA are tagged on the new Bug for review and prioritization.
    • The Bug is created using the Bug Template, and filled out with as much information as possible.
  • Bugs should be created in ADO using the Bug Template. Instructions on how to apply a template can be found here.