Product Backlog Template

---
title: "Product Backlog Template"
methodology: "agile"
complexity: "advanced"
owner: "mirichard"
updated: "2026-09-19"
primary_principles: ["value-focus", "adaptability"]
secondary_principles: ["quality-by-design"]
principle_rationale: "Orders product work transparently and refines user needs into acceptance criteria and manageable dependencies as priorities evolve."
---

# PRODUCT BACKLOG

## When to Use

- During Agile product delivery when work needs transparent ordering and acceptance criteria.
- When stakeholders and the team need visibility of scope, dependencies, and refinement readiness.

## When NOT to Use

- As a fixed scope contract that prevents evidence-based backlog adaptation.
- Do not waive essential controls solely because delivery is Agile, hybrid, or time-constrained. See [Tailoring by omission](../../../../docs/principles/anti-patterns.md#tailoring-omission).

## Pairs Well With

- [User Story Template](../../../../domains/uncertainty/role-based-toolkits/product-owner/user-story-template.md).
- [Sprint Planning Template](../../../../domains/delivery/templates/agile/sprint_planning_template.md).

Selection context: Delivery domain; agile methodology; advanced complexity. Match the situations above to project phase, risk, team size, and industry using the [decision-engine context model](../../../../meta/architecture-research/800-801-context-assessment-model.md).

## Scrum tailoring

These worksheets and suggested agendas are optional practices. In Scrum, the Developers own the plan for delivering the Sprint Goal; selected work is a forecast that can be adapted. A Definition of Ready and story points are optional team practices. Use the product Definition of Done consistently, and treat the Sprint Review as inspection and adaptation rather than a release-approval gate. See the [Scrum Guide](https://scrumguides.org/scrum-guide.html).


## Document Information
**Product/Project Name:** *[Customer Portal Application]*  
**Product Owner:** *[Jane Smith]*  
**Document Version:** *1.0*  
**Last Updated:** *[YYYY-MM-DD]*\

---

## Document Purpose
*This Product Backlog serves as the single source of truth for all work to be completed on the [Product/Project Name]. It contains all features, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. This is a living document that is continuously refined and prioritized by the Product Owner in collaboration with the Scrum Team and stakeholders.*

---

## Table of Contents
1. [Backlog Structure and Organization](#1-backlog-structure-and-organization)
2. [User Story Format](#2-user-story-format)
3. [Estimation Guidelines](#3-estimation-guidelines)
4. [Prioritization Framework](#4-prioritization-framework)
5. [Backlog Refinement Process](#5-backlog-refinement-process)
6. [Definition of Ready](#6-definition-of-ready)
7. [Current Product Backlog](#7-current-product-backlog)
   - [Epics](#epics)
   - [User Stories](#user-stories)
8. [Backlog Management Tools](#8-backlog-management-tools)

---

## 1. Backlog Structure and Organization

### 1.1 Backlog Hierarchy
The Product Backlog is organized using a hierarchical structure to manage complexity and provide appropriate levels of detail:

**Epics**
- Large bodies of work that can be broken down into smaller components
- Typically span multiple sprints or releases
- Provide a high-level view of major features or capabilities

**Features**
- Specific functionality that delivers value to users
- Typically broken down from epics
- May span one or more sprints

**User Stories**
- Small, independent, valuable pieces of functionality
- Typically completable within a single sprint
- Written from user perspective

**Tasks**
- Technical activities required to complete a user story
- Typically assigned to individual team members
- Usually completed within a few days

### 1.2 Backlog Sections
The Product Backlog is organized into the following sections:

**Current Release**  
Items planned for the upcoming release, with high level of detail and refinement.

**Future Releases**  
Items planned for future releases, with less detail and refinement.

**Technical Debt**  
Non-functional improvements, refactoring, and other technical items needed to maintain product quality.

**Research Spikes**  
Investigations needed to understand complex problems before creating detailed user stories.

## 2. User Story Format

### 2.1 User Story Template
User stories follow this format:

```
As a [type of user],
I want [an action or feature]
So that [benefit/value]
```

### 2.2 Acceptance Criteria
Each user story includes clear acceptance criteria that define when the story is complete. Acceptance criteria follow the Given-When-Then format:

```
Given [precondition]
When [action]
Then [expected result]
```

### 2.3 Additional Story Attributes

**Epic Link**  
The epic to which this story belongs

**Business Value**  
Numeric indicator (1-10) of value to the business

**Dependencies**  
Other stories that must be completed before this one

**Attachments**  
Mockups, diagrams, or other supporting documents

**Notes**  
Additional context or information

### 2.4 User Story Example

```
ID: US-123
Title: User Login

As a registered user,
I want to log in to my account using my email and password
So that I can access my personal dashboard and settings

Acceptance Criteria:
1. Given I am on the login page
   When I enter a valid email and password
   Then I should be successfully logged in and redirected to my dashboard

2. Given I am on the login page
   When I enter an invalid email or password
   Then I should see an appropriate error message

3. Given I am on the login page
   When I click the "Forgot Password" link
   Then I should be directed to the password reset page

4. Given I am logged in
   When I click the logout button
   Then I should be logged out and redirected to the login page

Epic Link: User Authentication
Business Value: 8
Story Points: 5
Dependencies: US-100 (User Registration)
Attachments: login_screen_mockup.png
Notes: Implement using OAuth 2.0 protocol
```

## 3. Estimation Guidelines

### 3.1 Story Point Scale
This product backlog uses the Fibonacci sequence for story point estimation:

| Points | Complexity | Example |
|--------|------------|---------|
| 1 | Trivial | Text change, simple UI update |
| 2 | Simple | Basic form with minimal validation |
| 3 | Small | Feature with simple business logic |
| 5 | Medium | Feature with moderate complexity |
| 8 | Large | Complex feature with multiple components |
| 13 | Very Large | Feature with significant complexity and dependencies |
| 21 | Extra Large | Should be broken down into smaller stories |

### 3.2 Relative Sizing
Story points represent relative effort, not absolute time. Consider these factors when estimating:
- Complexity
- Uncertainty/Risk
- Effort required
- Volume of work

### 3.3 Estimation Process
1. **Planning Poker**: Team members estimate stories simultaneously to avoid anchoring bias
2. **Reference Stories**: Compare new stories to previously estimated ones
3. **Team Consensus**: Discuss differences in estimates to reach agreement
4. **Continuous Calibration**: Regularly review and adjust estimation accuracy

### 3.4 Velocity Calculation
Team velocity is calculated as the average number of story points completed over the last 3 sprints. Current team velocity: [XX] points per sprint.

## 4. Prioritization Framework

### 4.1 Prioritization Factors
Items in the Product Backlog are prioritized based on these factors:

**Business Value**  
How much value does this item deliver to customers or the business?

**Cost of Delay**  
What is the impact of not implementing this item now?

**Risk/Opportunity**  
Does this item mitigate significant risks or unlock key opportunities?

**Dependencies**  
Does this item unblock other high-value work?

**Effort/Complexity**  
How complex or time-consuming is the implementation?

### 4.2 Priority Levels
The Product Backlog uses these priority levels:

| Priority | Description | Timeframe |
|----------|-------------|-----------|
| Critical | Must have for the current release | Current sprint or next sprint |
| High | Important for current release | Within next 2-3 sprints |
| Medium | Desired for current release but could be deferred | Current release |
| Low | Nice to have, can be deferred to future releases | Future release |

### 4.3 WSJF Scoring (Optional)
For complex prioritization decisions, Weighted Shortest Job First (WSJF) may be used:

WSJF = Cost of Delay / Job Size

Where Cost of Delay combines:
- Business value
- Time criticality
- Risk reduction/opportunity enablement

### 4.4 MoSCoW Method (Optional)
For release planning, items may be categorized using the MoSCoW method:
- **Must Have**: Required for the release to be successful
- **Should Have**: Important but not necessary for initial release
- **Could Have**: Desirable if time and resources permit
- **Won't Have**: Out of scope for this release but may be considered later

## 5. Backlog Refinement Process

### 5.1 Refinement Cadence
Backlog refinement is an ongoing process with dedicated sessions held:
- Formal refinement meeting: Weekly, [Day] at [Time]
- Duration: 1-2 hours
- Participants: Product Owner, Scrum Master, Development Team

### 5.2 Refinement Activities
1. **Review and Update**: Examine existing backlog items
2. **Breaking Down**: Split larger items into smaller, sprint-sized stories
3. **Adding Detail**: Clarify requirements and acceptance criteria
4. **Estimating**: Size new or updated items
5. **Prioritizing**: Review and adjust item priorities
6. **Identifying Dependencies**: Flag and address dependencies between items

### 5.3 Preparation for Refinement
**Product Owner**:
- Pre-identify items for discussion
- Prepare initial detail for new items
- Consider business priorities

**Development Team**:
- Review items before the meeting
- Note questions and concerns
- Consider technical implications

**Scrum Master**:
- Facilitate the process
- Keep focus on highest priority items
- Time-box discussions

### 5.4 Ready for Sprint Planning
The top items in the Product Backlog should be refined to be "Ready" for Sprint Planning. The goal is to have at least 2 sprints' worth of "Ready" stories at all times.

## 6. Definition of Ready

For a Product Backlog Item to be considered "Ready" for Sprint Planning, it must meet these criteria:

### 6.1 Story Readiness Checklist
- [ ] Written in user story format (As a... I want... So that...)
- [ ] Clear, testable acceptance criteria defined
- [ ] Dependencies identified and resolved or planned for
- [ ] Estimated by the Development Team
- [ ] Understood by the Development Team (no open questions)
- [ ] Small enough to complete within one sprint
- [ ] User interface designs or mockups attached (if applicable)
- [ ] Technical approach discussed and agreed upon
- [ ] Performance criteria specified (if applicable)
- [ ] No impediments that would prevent the story from being completed
- [ ] Acceptance testing approach defined

### 6.2 Epic Readiness
For Epics, which will be refined into user stories, readiness means:
- [ ] Clear business objective defined
- [ ] Target users/personas identified
- [ ] High-level scope boundaries established
- [ ] Initial acceptance criteria for the overall epic
- [ ] Rough size estimate (t-shirt sizing: S, M, L, XL)
- [ ] Dependencies and constraints identified
- [ ] Success metrics defined

## 7. Current Product Backlog

### Epics

| Epic ID | Epic Name | Description | Status | Priority |
|---------|----------|-------------|--------|----------|
| E-001 | User Authentication | User registration, login, profile management, and security features | In Progress | Critical |
| E-002 | Dashboard | Personalized user dashboard with customizable widgets | Not Started | High |
| E-003 | Reporting | Data visualization and report generation capabilities | Not Started | Medium |
| E-004 | Admin Controls | Administrative functions for user management and system configuration | Not Started | High |
| E-005 | Notification System | Email, in-app, and push notification capabilities | Not Started | Medium |

### User Stories

#### Sprint Ready (Next Sprint)

| ID | User Story | Acceptance Criteria | Epic | Priority | Points | Dependencies |
|----|------------|---------------------|------|----------|--------|-------------|
| US-101 | As a visitor, I want to create an account so that I can access the system | 1. Email validation<br>2. Password requirements<br>3. Confirmation email<br>4. GDPR compliance | E-001 | Critical | 5 | None |
| US-102 | As a user, I want to log in with my credentials so that I can access my account | 1. Email/password login<br>2. Error handling<br>3. Remember me option<br>4. Logout functionality | E-001 | Critical | 3 | US-101 |
| US-103 | As a user, I want to reset my password if I forget it so that I can regain access to my account | 1. Email reset flow<br>2. Secure token generation<br>3. Password update form<br>4. Notification of change | E-001 | High | 3 | US-101 |
| US-104 | As a user, I want to edit my profile information so that my account details stay up to date | 1. Edit form with validation<br>2. Profile picture upload<br>3. Email change verification<br>4. Save confirmation | E-001 | Medium | 5 | US-102 |

#### Refined (Future Sprints)

| ID | User Story | Acceptance Criteria | Epic | Priority | Points | Dependencies |
|----|------------|---------------------|------|----------|--------|-------------|
| US-201 | As a user, I want to see a dashboard when I log in so that I can access key information | 1. Dashboard layout<br>2. Default widgets<br>3. Loading states<br>4. Responsive design | E-002 | High | 8 | US-102 |
| US-202 | As a user, I want to customize my dashboard layout so that I can focus on relevant information | 1. Drag and drop widgets<br>2. Add/remove widgets<br>3. Save layout<br>4. Reset to default | E-002 | Medium | 8 | US-201 |
| US-301 | As an admin, I want to manage user accounts so that I can help users with account issues | 1. User search<br>2. Edit capabilities<br>3. Account lock/unlock<br>4. Permission changes | E-004 | High | 8 | US-101 |

#### Unrefined (Initial Ideas)

| ID | User Story | Epic | Priority | Notes |
|----|------------|------|----------|-------|
| US-401 | As a user, I want to create custom reports | E-003 | Medium | Needs discussion with data team |
| US-402 | As a user, I want to schedule automated reports | E-003 | Low | Dependencies on email system |
| US-501 | As a user, I want to set notification preferences | E-005 | Medium | Needs UX design |

## 8. Backlog Management Tools

### 8.1 Tools Used
The Product Backlog is managed using the following tool(s):
- Primary Tool: [Jira/Trello/Azure DevOps/etc.]
- Backup: This Markdown document, updated [frequency]

### 8.2 Workflow Status
Items in the backlog follow this workflow:
1. **New**: Initially created, minimal details
2. **Refining**: Adding details, under discussion
3. **Ready**: Meets Definition of Ready, available for sprint planning
4. **In Sprint**: Currently being worked on
5. **Done**: Completed and meets Definition of Done

### 8.3 Backlog Visualization
The Product Owner maintains these views of the backlog:
- Release Roadmap (quarterly view)
- Sprint Pipeline (next 3 sprints)
- Current Sprint Plan

---

## Appendix A: Product Backlog Item Template

```
# Product Backlog Item

## Basic Information
**ID:** [unique identifier]
**Type:** [Epic/Feature/User Story/Bug/Technical Debt]
**Title:** [short descriptive title]
**Sprint:** [if assigned]

## Description
As a [type of user],
I want [an action or feature]
So that [benefit/value]

## Acceptance Criteria
1. Given [precondition]
   When [action]
   Then [expected result]

2. Given [precondition]
   When [action]
   Then [expected result]

3. [Additional criteria as needed]

## Details
**Epic Link:** [parent epic if applicable]
**Business Value:** [1-10]
**Priority:** [Critical/High/Medium/Low]
**Story Points:** [1,2,3,5,8,13,21]
**Dependencies:** [list of dependent items]
**Components:** [technical components affected]

## Additional Information
**Mockups/Designs:** [links or attachments]
**Technical Notes:** [implementation details, constraints]
**Testing Notes:** [special testing considerations]
**Stakeholder Input:** [relevant stakeholder feedback]
```

## Appendix B: Definition of Ready Checklist

```
# Definition of Ready Checklist

## User Story Information
- [ ] Written in user story format 
- [ ] Title is clear and descriptive
- [ ] Business value is clearly articulated
- [ ] Priority is assigned

## Acceptance Criteria
- [ ] Written in Given-When-Then format
- [ ] All scenarios covered
- [ ] Testable and specific
- [ ] No ambiguous language

## Size and Scope
- [ ] Estimated by the team
- [ ] Can be complete