HKSM

An ordered, evolving list of features, defects, and other work for the product. It captures all known scope and ranks it by value and risk. It guides planning and delivery of the next most valuable work.

Key Points

• A single, transparent list of all product work, ordered by value, risk, and urgency.
• Output of Develop Scope Structure that expresses scope as epics, features, and stories rather than tasks.
• Each item is small, testable, and valuable, enabling incremental delivery.
• Typical fields: title, description, acceptance criteria, estimate, rank/order, value, dependencies, status, and target release.
• Includes functional items, non-functional requirements, defects, enablers, and spikes.
• Living artifact that changes as new information emerges; distinct from the Sprint/Iteration Backlog and schedule.

Purpose

• Provide a single source of truth for product scope and priorities.
• Enable evidence-based decisions about what to build next to maximize value.
• Support release and iteration planning, forecasting, and stakeholder alignment.
• Control scope by channeling changes through a visible, prioritized list.
• Reduce risk by surfacing and sequencing high-uncertainty items early.

How to Create

• Gather inputs: product vision, roadmap, business case, charter, stakeholder needs, user research, architecture constraints, compliance requirements, and known defects.
• Structure scope with techniques such as story mapping, user journeys, and impact mapping to identify epics and features.
• Decompose epics into right-sized backlog items using the INVEST guideline where practical.
• Write clear acceptance criteria for each item to define testable outcomes.
• Estimate size using relative sizing (e.g., story points or T-shirt sizes).
• Order items by value, risk, dependencies, and deadlines using methods like WSJF or MoSCoW.
• Define a Definition of Ready for selection and link to the team’s Definition of Done.
• Capture dependencies and identify enablers or spikes where discovery is needed.
• Map the highest-priority items to near-term releases or increments.

How to Use

• Refine regularly to clarify scope, split items, update estimates, and reorder priorities.
• Select the top ready items during iteration or sprint planning to form the Sprint/Iteration Backlog.
• Respond to change by adding and reordering items rather than disrupting in-progress iteration scope.
• Use the top of the backlog to communicate trade-offs and obtain stakeholder decisions.
• Forecast outcomes by combining ordered items with team throughput or velocity.
• Track completion against acceptance criteria and update status for transparency.

Ownership & Update Cadence

• Accountable owner: Product Owner, with input from the delivery team, customers, and stakeholders.
• Continuously updated; formal refinement typically consumes 5–10% of team capacity each iteration.
• Near-term items are detailed and estimated; mid-term items are medium-grained; longer-term items remain coarse.
• Reordering can happen at any time when value, risk, or constraints change.
• Regularly archive done or obsolete items to keep the list lean and navigable.

Example

• PBI-01 — User signs up with email (Story): Rank 1, Est 5 pts, Acceptance: valid email, password rules, confirmation email sent, Target: Release 1.0, Deps: none.
• PBI-02 — Capture GDPR consent (Story): Rank 2, Est 3 pts, Acceptance: explicit consent checkbox recorded with timestamp, Target: Release 1.0, Deps: PBI-01.
• PBI-03 — Performance baseline (Spike): Rank 3, Est 2 pts, Outcome: approach to meet 2 s page load, Target: Sprint 2, Deps: none.
• PBI-04 — Password reset flow (Story): Rank 4, Est 3 pts, Acceptance: reset link expires in 15 minutes and enforces new password rules, Target: Sprint 2, Deps: PBI-01.
• PBI-05 — Payment gateway integration (Feature): Rank 5, Est 13 pts, Acceptance: process test card, refund flow supported, Target: Release 1.1, Deps: vendor sandbox.
• PBI-06 — Availability SLO 99.9% (NFR): Rank 6, Est 0, Acceptance: SLO defined, monitored, and reported, Target: Release 1.1, Deps: observability tooling.

PMP Example Question

A new regulatory rule is announced mid-iteration that will affect the product. To keep scope structured and transparent, what should the Product Owner and team do next?

1. Update the WBS baseline and freeze scope until the next phase.
2. Add a new item to the product backlog and reprioritize with stakeholders.
3. Immediately move work into the current Sprint Backlog to avoid delays.
4. Submit a change request to the PMO before taking any action.

Correct Answer: B — Add a new item to the product backlog and reprioritize with stakeholders.

Explanation: Changes are funneled through the product backlog, then ordered based on value, risk, and urgency. This preserves transparency and allows informed planning without disrupting the current iteration.