HKSM

Estimate User Stories is the Scrum process where the team assigns relative sizes to user stories to forecast effort and support release and sprint planning.

Purpose & When to Use

The goal is to size user stories relatively so the team can forecast how much work fits into releases and sprints, expose unknowns and risks, and highlight stories that need splitting or investigation.

• Use during backlog refinement once initial user stories and acceptance criteria exist.
• Repeat before release planning and as new or changed stories appear.
• Helpful whenever dependencies, complexity, or nonfunctional needs are unclear and require team discussion.

Mini Flow (How It’s Done)

• Inputs: Prioritized Product Backlog, acceptance criteria, Definition of Ready, historical velocity or initial forecast, reference story.
• Roles: Scrum Team estimates; Product Owner clarifies; Scrum Master facilitates and guards against bias.

1. Prepare a baseline by selecting one or two well-understood reference stories with agreed point values.
2. For each story, review goal, acceptance criteria, constraints, and dependencies; confirm shared understanding.
3. Choose a technique (e.g., Planning Poker with Fibonacci points, T‑Shirt sizes mapped to points, Affinity/Bucket estimation).
4. Estimate together: each member selects a size privately, reveal simultaneously, then discuss high and low outliers (complexity, uncertainty, integration, test effort).
5. Re-estimate until the team converges or reaches a narrow range; record the final story-point value.
6. Flag stories that are too large or risky; split them or create time-boxed spikes to reduce uncertainty.
7. Update the backlog and release forecast using current or provisional velocity; adjust ordering if value/effort insights change priorities.

• Outputs: Estimated User Stories, updated Prioritized Product Backlog, list of stories to split or spike, noted risks/assumptions, refined release/sprint forecast.

Quality & Acceptance Checklist

• Every estimated story has clear acceptance criteria and a shared understanding.
• Estimates are relative (story points/T‑Shirt) and reached by team consensus, not by a single role.
• Testing, integration, and nonfunctional needs are included in the size.
• Oversized stories are identified for splitting so each can fit within a sprint.
• Assumptions, dependencies, and major risks are captured or linked to spikes.
• Reference stories and point scale are stable and known to the team.
• Backlog is updated immediately; estimates are revised if the story meaning changes.

Common Mistakes & Exam Traps

• Treating story points as hours or days; points are for relative size and forecasting.
• Allowing the Product Owner or manager to set the estimate; the people doing the work estimate.
• Averaging differing estimates instead of discussing outliers to reach true consensus.
• Estimating epics or vague stories; refine or split first.
• Ignoring testing, integration, and nonfunctional requirements in the estimate.
• Using velocity as a performance target; it is a planning forecast, not a KPI.
• Failing to re-estimate after splitting or major changes in scope or team composition.
• Inconsistent mapping between T‑Shirt sizes and points across sessions.

PMP/SCRUM Example Question

During backlog refinement, half the team selects 3 points and the other half selects 8 points for the same story. What should the Scrum Master encourage the team to do next?

1. Average the estimates to 5 points and move on.
2. Ask the Product Owner to decide the final estimate.
3. Discuss underlying assumptions, risks, testing and integration needs, then re-estimate.
4. Immediately split the story into smaller stories.

Correct Answer: C. The team should explore why estimates differ, surface assumptions and risks, and re-estimate; only split if it cannot fit in a sprint or remains too uncertain.