Program Backlog

Working with the Program Backlog

Terms

Create the Program

• Create a Program work item in the Program Management backlog.
• Put a link to the Program Brief in the Description field.
• Form a small team for Discovery Phase.
• Work with Principal Software Developer (PSD) to develop basic system design.

Program States

State	Description
Draft	Program brief is being drafted and reviewed internally before submission.
Proposed	Brief is written but not yet approved by BLT, possibly adjusting the brief based on BLT feedback.
Approved	The BLT approved the program brief, but no program team (EPM, SPM, Principal) assigned yet.
Unstaffed	Program team is in place, but no teams assigned. There is ongoing analysis among Tech Lead, EPM, and SPM.
Discovery	Program team and development teams are designing high level software deliverables and milestones with rough estimates.
Committed	Program is in progress; development teams are actively working on milestones.
Done	Program completed - acceptance criteria met.
Removed	Program ended, but not through completion of all acceptance criteria.

Program Template

• Program Goal
• The goal of the program is to...
• Program Links
• Latest Approved Program Brief: URL
• Key Discovery Phase Documents:
• Name: URL
• Name: URL
• Shared Program Folder: URL
• Program Overview Slide Deck: URL
• Targeted Market Launch Dates
• Lighthouse Release: Approximate Date Range and/or Milestone
• General Availability Release: Approximate Date Range and/or Milestone
• Program Template
  

Create Themes (Milestones)

• Each Theme represents a delivery or milestone.
• Most milestones should be sufficiently featureful, stable, and complete to potentially ship and market.
• The title of themes should be in the format "M#: Description [Release Type](optional)", e.g. "M5: UoM Support [GA]" where:
• M#: The milestone number
• Description: A short, human-readable description of the theme/milestone
• Release Type: Optional suffix, enclosed by square brackets, to indicate the type of release.
• UIT: User Integration Testing
• Lighthouse: Lighthouse Release
• GA: General Availability

Release Theme Template

• Release Theme Goals and Intentions
• The intent of this release theme is to enable customers to...
• Why?
• Release Theme Acceptance Criteria
• At the end of this theme, an user should be able to...
• Assumptions / Comments / Questions
• Release Theme Demo
• Target Completion Date
• The target completion date / milestone of this release theme is: <Estimated Month Year> and/or <Milestone like PI World>
• Theme Template
  

Create Epics

• Epics are potentially shippable/deployable (i.e. tested, documented, and complete) deliverables that define the Program.
• With technical guidance, develop a collection of Epics.
• An Epic should encompass a cohesive, coherent deliverable such that it can be moved easily between milestones, accounting for significant dependencies.
• Infrastructure (Technically-Driven) Epics should be avoided.
• Epics should be user- and persona-driven.
• Non-functional requirements (e.g. performance, scale, security, usability, maintainability), technical work (e.g. integration testing, package upgrades, refactoring, environment setup, CI/CD pipelines) and documentation (e.g. user guide and release documentation) should be incorporated into epics that they enable.
• UI Epics should be avoided unless backend and UI work realistically provides independent value.

Epic Template

• Goal
• The goal of this EPIC is to...
• Why?
• Key Personas
• Name - Title: Description
• User Stories
• As a Sr. Process Engineer, Carl wants to ... SO THAT...
• As a Sr. Process Engineer, Carl wants to ... SO THAT...
• Assumptions / Comments / Questions
• Epic Template
  

Schedule the Epics into Themes

• Core functionality can be delivered before extended functionality.
• Description: “At the end of this Theme, the customer will be able to….”
• Epics represent a demonstrable piece of functionality (e.g. vertical slice of a system) that is potentially shippable. In contrast, Themes represent an aggregate of Epics that satisfy a specific market scenario. When Themes are complete, they can be showcased during a Lighthouse engagement or released to a customer.
• These aggregations will change as the Program matures.

Create Features under Each Epic

Features mark the hand off from the Program team to the Development team. The Technical Product Manager (TPM), Engineering Manager (EM), and Staff Developer collaborate to break down Epics into Features.

Features are created and remain in the product backlog, if an appropriate product backlog exists; otherwise they can remain in the program backlog.

Feature Template

• User Stories
• As a Sr. Process Engineer, Carl wants to ... SO THAT...
• Background
• Provide any additional information.
• Out of Scope
• Explicitly define what is not part of the feature.
• Timeline Driver
• Define when the feature needs to be complete, for example, PI World SF 2020, and the reasoning for the timeline date. The target date should be used with this to indicate the expected Feature completion date.
• Dependencies/Stakeholders
• UserVoice Ideas
• Links to the UserVoice ideas we’re aiming to tackle with the feature.
• Considerations and Questions
• Feature Template
  

Backlog Items (actual dev work)

• Features are often implemented by a single development team.
• The development team authors Backlog Items from Features, with assistance from TPM as necessary.