HKSM

The Prioritized Product Backlog is the ordered, single source list of epics and user stories ranked mainly by business value, risk, and dependencies. It is owned by the Product Owner and continuously refined with stakeholder feedback and team estimates. It feeds both release planning and sprint planning.

Key Points

• Single, transparent list of all desired product work, ordered by value and risk.
• Owned and actively managed by the Product Owner with input from stakeholders and the team.
• Continuously refined through grooming; updated after Sprint Reviews and as new information emerges.
• Top items are small, testable, estimated, and clear enough to be pulled into a sprint.
• Primary input to Release Planning and Sprint Planning; output of backlog creation and refinement processes.
• Reordering can happen anytime between sprints; the current sprint scope remains stable.

Purpose

The backlog provides a clear, value-driven sequence of work so the team always knows what is most important next. It aligns stakeholders on scope, enables forecasting for releases, and supports incremental delivery of the highest value features.

By keeping one authoritative list, it reduces conflicts, clarifies trade-offs, and anchors decisions about what to build now versus later.

Key Terms & Clauses

• Product Backlog Item (PBI) - A user story or other item that delivers value to users or stakeholders.
• Epic - A large requirement that is later broken into smaller user stories.
• Acceptance Criteria - Conditions that must be met for a PBI to be accepted.
• Order/Priority - The explicit rank of items based on value, risk, and dependencies; only one item holds each position.
• Estimate - Relative sizing, typically in story points, provided by the delivery team.
• Definition of Ready (DoR) - Agreement on what makes a PBI clear and ready to pull into a sprint.

How to Develop/Evaluate

1. Seed the backlog with epics from the product vision and stakeholder needs.
2. Split epics into user stories; apply INVEST to improve clarity and independence.
3. Add acceptance criteria, business value scores, dependencies, and risks.
4. Estimate collaboratively using techniques like Planning Poker; revise as understanding grows.
5. Order items by value, risk, and dependency logic; use simple ranking, MoSCoW, or WSJF if helpful.
6. Refine regularly so the top 1–2 sprints of work are DoR-ready and right-sized.
7. Evaluate health with quick checks: ready ratio of top items, backlog size, churn rate, and aging of high-priority work.

How to Use

In Release Planning, select the highest-value, feasible items to form a release backlog and set release goals. In Sprint Planning, the team pulls the top ready items to create the Sprint Backlog based on velocity and capacity.

During delivery, the Product Owner may add or reorder items between sprints as feedback arrives from Sprint Reviews, user tests, or market changes. Groom Prioritized Product Backlog sessions keep the list current, while Sprint Reviews and retrospectives trigger updates and learning.

Example Snippet

• PBI-41 - As a user, I can reset my password via email so I can regain access. Value: 100. Estimate: 5. Risk: Medium. Priority: 1. Acceptance: link expires in 30 minutes; email sent to registered address only.
• PBI-28 - As an admin, I can export reports to CSV for offline analysis. Value: 60. Estimate: 8. Risk: High. Priority: 2. Dependency: PBI-12 reporting API.
• Epic: Payments - Split into PBI-72 add card, PBI-73 charge card, PBI-74 refund. Each story has acceptance criteria and estimates; ordered by expected revenue impact.

Risks & Tips

• Risk: Priority driven by the loudest voice rather than value data; mitigate with explicit scoring and stakeholder workshops.
• Risk: Top items lack estimates or acceptance criteria; mitigate with a Definition of Ready and timeboxed refinement.
• Risk: Mixing tasks/technical subtasks with user stories; keep tasks in the Sprint Backlog and value items in the Product Backlog.
• Risk: Frequent mid-sprint changes to scope; keep the sprint stable and reorder backlog for the next sprint.
• Tip: Limit the top of the backlog to about 1–2 sprints of ready items to reduce churn.
• Tip: Visualize dependencies and aging to avoid hidden blockers and stale high-priority work.

PMP/SCRUM Example Question

During a Sprint Review, stakeholders request a high-value feature that was not previously considered. What should the Product Owner do next?

1. Add it to the current Sprint Backlog so the team can start immediately.
2. Add it to the Prioritized Product Backlog and order it based on value, risk, and dependencies.
3. Send a change request to the PMO and lock the backlog until approval.
4. Ask the Scrum Master to update the Definition of Done to include the feature.

Correct Answer: B — Add it to the Prioritized Product Backlog and order it based on value, risk, and dependencies.

Explanation: New scope is captured and prioritized in the backlog, not injected into an active sprint. The Product Owner orders it for consideration in a future sprint or release.