HKSM

Early, rough size or effort ranges for epics that express relative complexity and cost. Created collaboratively by the Scrum Team during early planning, they inform prioritization and release planning and are refined as epics are split into user stories.

Key Points

• Represents order-of-magnitude sizing for epics, not detailed estimates.
• Usually expressed as ranges or categories (e.g., T-shirt sizes or story point bands).
• Produced during Develop Epic(s) and used in Create Prioritized Product Backlog and Conduct Release Planning.
• Estimated by the Scrum Team; maintained by the Product Owner within the product backlog.
• Captures assumptions and confidence to communicate uncertainty.
• Refined after decomposition into user stories and as more information emerges.

Purpose

Provide a quick, comparable view of effort and complexity for large backlog items so stakeholders can balance value, risk, and cost early. These estimates support early prioritization, budgeting, and high-level release forecasting without delaying discovery.

They serve as an output of Develop Epic(s) and as inputs to Create Prioritized Product Backlog and Conduct Release Planning, enabling scope shaping and trade-off discussions.

Key Terms & Clauses

• Epic: A large, coarse-grained backlog item that will later be decomposed into user stories.
• T-shirt sizing: Relative categories like XS/S/M/L/XL that map to effort ranges.
• Story point range: A band such as 40–100 points used to indicate uncertainty at epic level.
• Assumptions: Conditions recorded with the estimate that, if changed, may shift the range.
• Confidence level: Qualifier (e.g., low/medium/high) indicating reliability of the range.
• Reference stories: Known items used to anchor relative sizing among epics.
• Velocity (team-specific): Historical throughput used to convert point ranges into rough time windows for releases.

How to Develop/Evaluate

1. Prepare epics: Confirm high-level goal, boundaries, and acceptance criteria at a coarse level.
2. Select a scale: Choose T-shirt sizes or point ranges; agree on reference items to calibrate.
3. Estimate collaboratively: Timebox a quick session with the Scrum Team using affinity estimation or wideband techniques.
4. Record assumptions and confidence: Note key drivers (dependencies, unknowns, constraints) and a confidence indicator.
5. Normalize and review: Check for outliers, align across epics, and adjust where calibration suggests inconsistency.
6. Baseline and update: Store in the product backlog and refine after splitting epics into stories.

• Evaluation checks: Are sizes relative to agreed references, is the range realistic, and are major risks captured.
• Quality indicators: Clear assumptions, consistent use of scale, and shared team understanding.

How to Use

• Prioritization: Combine with business value and risk to order the product backlog.
• Release planning: Convert point ranges to tentative release windows using historical velocity.
• Budgeting: Derive order-of-magnitude cost using rates or burn profiles for early funding conversations.
• Scope shaping: Identify oversized epics for early splitting or spikes to reduce uncertainty.
• Risk management: Flag low-confidence, high-size epics for discovery or proof-of-concept work.
• Progressive elaboration: Replace high-level ranges with story-level estimates as decomposition occurs.

Example Snippet

• Epic A: Size = L (approx. 60–120 points), Confidence = Medium, Assumptions = 1 external API and 1 team available.
• Epic B: Size = M (approx. 30–60 points), Confidence = High, Assumptions = No new infrastructure.
• Epic C: Size = XL (approx. 120–200 points), Confidence = Low, Assumptions = Unknown third-party integration; spike needed.

If team velocity is ~30 points per sprint, Epic B could fit in 1–2 sprints, Epic A in ~2–4 sprints, and Epic C requires split or staged delivery.

Risks & Tips

• Risk: Treating high-level estimates as commitments or fixed dates.
• Risk: Bias from a single role estimating without team input.
• Risk: False precision by using exact hours too early.
• Risk: Not updating estimates after decomposition or major assumption changes.
• Tip: Keep ranges and confidence visible in the backlog.
• Tip: Use reference stories and historical velocity to anchor estimates.
• Tip: Timebox estimation sessions and capture assumptions explicitly.
• Tip: Trigger spikes for low-confidence, high-impact epics.

PMP/SCRUM Example Question

During Develop Epic(s), the Product Owner needs input for release planning and backlog ordering. What should the Scrum Master facilitate?

1. Have the Scrum Team provide relative, high-level ranges (e.g., T-shirt sizes) for each epic and record assumptions.
2. Decompose all epics into tasks and estimate hours for a detailed schedule.
3. Ask the Product Owner to assign story points based solely on business value.
4. Delay estimation until Sprint Planning when the team can commit to dates.

Correct Answer: A — Have the Scrum Team provide relative, high-level ranges (e.g., T-shirt sizes) for each epic and record assumptions.

Explanation: High-level estimates for epics are created early by the team to inform prioritization and release planning; they are ranges, not commitments. The other options either bypass team estimation, force premature detail, or delay necessary planning inputs.