HKSM

Structured techniques used by the Product Owner, with stakeholder input, to order Product Backlog items based on value, risk, cost, and dependencies. They help decide what to deliver next by ranking or scoring items in a transparent way. The result is an ordered backlog that guides release and sprint planning.

Key Points

• Led by the Product Owner with input from stakeholders and the Scrum Team.
• Compares backlog items by value, risk, cost of delay, effort, and dependencies.
• Common techniques include MoSCoW, 100-Point Method, paired comparison, Kano analysis, and relative weighting/WSJF.
• Produces a single, transparent ordering of the Product Backlog with clear rationale.
• Revisited frequently as new information, risks, or market changes arise.
• Feeds Release Planning and Sprint Planning by clarifying what to build next.

Purpose of Analysis

Prioritization makes sure the team delivers the highest value early while managing risk and constraints. It aligns delivery with the product vision, stakeholder goals, and customer outcomes, while exposing trade-offs and assumptions.

By converting preferences and data into a ranked list, it helps decide scope for releases, determine MVP slices, and reduce the cost of delay.

Method Steps

1. Prepare the candidate backlog: ensure items are expressed as epics or user stories with brief benefits and acceptance criteria.
2. Collect decision inputs: business value hypotheses, risks, time criticality, dependencies, and rough effort estimates from the team.
3. Select a technique: choose MoSCoW, 100-Point Method, paired comparison, Kano, or relative weighting/WSJF based on time and data available.
4. Facilitate a workshop: involve key stakeholders to score, rank, or classify items; resolve ties and record rationale.
5. Check constraints: validate dependencies, regulatory must-haves, and technical enablers that may affect ordering.
6. Create the ordered list: convert scores or categories into a single Product Backlog order.
7. Validate with the Scrum Team: confirm feasibility, clarify assumptions, and adjust for DoR and capacity boundaries.
8. Publish and iterate: communicate the ordering, note cutlines for release/MVP, and update regularly as feedback arrives.

Inputs Needed

• Product vision, business goals, and release objectives.
• Stakeholder value drivers, customer feedback, and market signals.
• Risk register or risk notes, regulatory and compliance needs.
• High-level effort estimates from the team (e.g., story points, T-shirt sizes).
• Dependencies, architectural enablers, and technical debt considerations.
• Definition of Ready and any organizational constraints or deadlines.

Outputs Produced

• An ordered Product Backlog that reflects value, risk, and timing considerations.
• Scores, ranks, or categories (e.g., MoSCoW or WSJF values) with rationale for transparency.
• Cutlines indicating MVP, next release scope, or near-term sprint candidates.
• Updates to release planning assumptions and stakeholder alignment records.

Interpretation Tips

• Treat scores as decision aids, not absolute truths; the order is what guides selection.
• Do not confuse effort estimates with value; high effort does not mean high priority.
• Reassess after major feedback, risk changes, or dependency shifts.
• Combine qualitative judgment with simple metrics to avoid false precision.
• Make rationale visible so stakeholders understand trade-offs and accept the ordering.
• Use time horizons: near-term items should be more granular and validated than distant ones.

Example

A Product Owner needs to pick features for the next release. Four stakeholders receive 100 points each to distribute across five user stories.

After voting, Story A has 160 points, B has 140, C has 110, D has 70, and E has 20. The team notes that B depends on C, so the final order becomes A, C, B, D, E. The top items are then refined for the upcoming sprints and used to set the release cutline.

Pitfalls

• Letting effort or loud voices drive decisions instead of customer value.
• Ignoring dependencies, regulatory constraints, or critical enablers.
• Freezing priorities for too long and missing market changes.
• Overcomplicating the scoring model and creating false certainty.
• Gaming the process with inflated numbers or hidden agendas.
• Neglecting non-functional requirements and technical debt items.

PMP/SCRUM Example Question

A Product Owner faces conflicting stakeholder opinions about which features should lead the next release. The PO wants a quick, collaborative way to convert preferences into a ranked Product Backlog with transparent weighting. What should the PO do?

1. Use the 100-Point Method so stakeholders allocate points across backlog items to produce a ranked list.
2. Order items by highest story points to maximize team utilization.
3. Ask the Scrum Master to decide based on the team’s capacity.
4. Use the Daily Scrum to vote on the next release scope.

Correct Answer: A — Use the 100-Point Method so stakeholders allocate points across backlog items to produce a ranked list.

Explanation: The 100-Point Method is a recognized prioritization technique that converts stakeholder preferences into an ordered backlog. Story points are effort, not value; the Scrum Master does not set priorities; the Daily Scrum is not for backlog prioritization.