HKSM

A set of team-agreed rules, units, and reference points used to size user stories and tasks consistently. It guides what factors to consider (such as complexity, risk, and uncertainty) and how to apply scales like story points or T-shirt sizes during estimation.

Key Points

• Tool/Technique used in SBOK during Estimate User Stories and Estimate Tasks.
• Defines the estimation unit and scale (story points, ideal hours, T-shirt sizes) and the reference stories that anchor the scale.
• Specifies which factors to consider: complexity, effort, uncertainty, risk, and dependencies.
• Agreed by the Scrum Team; the Product Owner participates for clarity but does not impose numbers.
• Applied during techniques like Planning Poker and Affinity Estimation to speed consensus.
• Reviewed and refined based on actual velocity and learning across sprints.

Purpose of Analysis

The goal is to create a consistent yardstick so different backlog items are sized in a comparable way. This supports more reliable forecasting, clearer conversations, and faster estimation sessions. It also reduces bias by making the evaluation factors explicit and shared.

Method Steps

1. Select the estimation unit and scale (for example, Fibonacci story points or S, M, L T-shirt sizes).
2. Choose 2–3 reference stories with known, stable sizes to anchor the scale.
3. Define inclusion rules and factors: what work to include (build, test, integration), how to treat uncertainty, risk, and dependencies.
4. Document the criteria in a brief checklist and socialize it with the team and Product Owner.
5. Apply the criteria during estimation workshops (for example, Planning Poker), timeboxing discussion and comparing to reference stories.
6. Inspect outcomes after a few sprints, compare estimates to actuals via velocity, and refine the criteria as needed.

Inputs Needed

• Product backlog items with clear acceptance criteria and a Definition of Ready.
• Historic velocity, cycle time, or examples of completed stories for references.
• Known risks, dependencies, and architectural constraints.
• Team capacity, skills mix, and Definition of Done to ensure completeness.
• Any organizational standards on estimation units or scales, if applicable.

Outputs Produced

• A concise Estimation Criteria guide describing units, scale, factors, and inclusion rules.
• A set of reference stories with agreed sizes for calibration.
• Consistent size estimates for user stories and decomposed tasks.
• An assumptions or estimation log that captures notable risks or caveats.

Interpretation Tips

• Treat sizes as relative measures, not precise effort hours, to enable stable velocity-based forecasting.
• Use story points for backlog sizing and hours only after task breakdown in Sprint Planning if helpful.
• Calibrate across teams with shared reference stories when multiple teams work on the same product.
• Keep criteria lightweight; too much detail slows estimation without improving accuracy.
• Separate size from priority; business value affects ordering, not the numerical estimate.

Example

A Scrum Team adopts Fibonacci story points and defines reference stories: a simple validation story as 3 points and a medium integration story as 8 points. The team agrees to include development, testing, and integration work, and to reflect uncertainty and dependencies in the size. During Planning Poker, items are compared to the references; after three sprints, the team reviews velocity and slightly adjusts what qualifies as a 5 versus an 8.

Pitfalls

• Changing scales mid-release, which breaks comparability of estimates.
• Mixing business priority into size, inflating estimates to influence ordering.
• Allowing one expert to dominate, undermining team consensus and shared understanding.
• Padding estimates to add hidden buffer instead of managing risk transparently.
• Ignoring testing, integration, or non-functional work in the inclusion rules.

PMP/SCRUM Example Question

A Scrum Master is preparing a joint estimation workshop for two teams that will work from the same product backlog. What should be done first to ensure consistent and comparable sizing across teams?

1. Ask the Product Owner to assign sizes based on business priority.
2. Agree on estimation criteria, including the unit/scale and shared reference stories.
3. Break all epics into tasks and estimate those in hours.
4. Create a detailed Gantt chart to align both teams on schedule.

Correct Answer: B — Agree on estimation criteria, including the unit/scale and shared reference stories.

Explanation: Establishing estimation criteria creates a common yardstick for both teams, enabling consistent relative sizing. Options A, C, and D either conflate priority with size, skip story-level estimation, or use non-Scrum scheduling tools.