HKSM

Estimation Methods are collaborative techniques used by the Scrum Team to size user stories and estimate task effort for planning and forecasting. In SBOK, these include tools like Planning Poker, Wideband Delphi, Affinity Estimation, T-shirt sizing, and Ideal Time, focused on relative sizing and team consensus. They support Product Backlog ordering and help forecast releases and sprints using empirical velocity.

Key Points

• Used during Estimate User Stories, Estimate Tasks, Backlog Refinement, and Sprint Planning.
• Relies on team consensus, relative sizing, and comparison to reference stories.
• Common techniques include Planning Poker, Wideband Delphi, Affinity Estimation, T-shirt sizing, and Ideal Time.
• Produces estimated user stories (story points or T-shirt sizes) and task effort (ideal hours) for sprint planning.
• Supports Product Owner in prioritization by balancing value, risk, and size.
• Scrum Master facilitates to reduce bias, ensure time-boxing, and maintain transparency.

Purpose of Analysis

Estimation in Scrum helps the team understand the relative size and complexity of work so they can plan sprints, forecast releases, and manage risk. It informs Product Backlog ordering by giving the Product Owner a realistic view of effort versus value. It also enables empirical planning by connecting story points to observed velocity.

Method Steps

1. Prepare: Select a set of refined user stories with clear acceptance criteria; confirm Definition of Done and estimation scale (story points or T-shirt sizes).
2. Choose a technique: Planning Poker, Affinity Estimation, T-shirt sizing, Wideband Delphi, or a mix (e.g., T-shirt sizing first, then Planning Poker for borderline items).
3. Discuss and clarify: Product Owner answers questions; the team identifies assumptions, risks, and dependencies.
4. Estimate: Individuals propose sizes privately (e.g., simultaneous card reveal) or group items by similarity (affinity), then converge to consensus.
5. Triangulate: Compare to reference stories and adjust to maintain consistency across the backlog.
6. Record and split: Document final estimates, note assumptions, and split any story that exceeds the team’s sizing threshold.
7. Task-level estimation (optional, near Sprint Planning): Break selected stories into tasks and estimate ideal hours to check capacity.

Inputs Needed

• Refined user stories and acceptance criteria.
• Reference stories with agreed point values or size categories.
• Team capacity and historical velocity (if available).
• Definition of Done, known risks, and dependencies.
• Product vision, release goals, and constraints that influence prioritization.

Outputs Produced

• Estimated user stories in story points or T-shirt sizes.
• Consensus notes and key assumptions for future reference.
• Updated Product Backlog ordering by the Product Owner based on value versus size.
• Task-level effort estimates in ideal hours for sprint planning (when used).
• Improved velocity forecast and release planning baselines.

Interpretation Tips

• Treat story points as relative size, not as hours or days.
• Use triangulation with reference stories to keep consistency across sprints.
• Expect higher uncertainty early; refine estimates as stories mature.
• Use team velocity empirically to forecast, not to set targets.
• Re-estimate only when a story’s scope or understanding changes materially.

Example

During refinement, the team estimates a new search feature. Using Planning Poker, members reveal 5 and 8 points. They discuss that integration and performance tests add complexity, then compare it to a known 5-point reference.

They agree on 8 points, capture the assumption that a third-party API is stable, and the Product Owner reorders the backlog, moving a smaller but high-value story ahead for the next sprint. Before Sprint Planning, the team breaks the selected stories into tasks and estimates ideal hours to confirm capacity.

Pitfalls

• Anchoring on the first number or deferring to the loudest voice instead of reaching true consensus.
• Treating story points as commitments or as direct time conversions.
• Overprecision for vague epics instead of splitting and refining first.
• Gaming velocity by inflating points to meet targets.
• Estimating without cross-functional team members who will do the work.

PMP/SCRUM Example Question

During Backlog Refinement, the team sees wide variation in initial sizes for a complex user story. The Scrum Master wants to reduce anchoring and quickly reach a consensus estimate. Which technique is MOST appropriate?

1. Round-robin updates where each member states an estimate aloud in turn.
2. Planning Poker with simultaneous reveal and discussion rounds.
3. The Product Owner selects the estimate based on business priority.
4. Use last sprint’s velocity as the estimate for the story.

Correct Answer: B — Planning Poker with simultaneous reveal and discussion rounds.

Explanation: Planning Poker reduces anchoring by private selection and simultaneous reveal, then drives consensus through discussion. The other options either introduce bias, misuse velocity, or bypass team estimation.