HKSM

Estimated User Stories are product backlog items that the Scrum Team has sized using a chosen scale, typically story points or ideal time. They express relative effort and uncertainty, enabling reliable sprint and release forecasting.

Key Points

• Output of the Estimate User Stories process in the SBOK Plan and Estimate phase.
• Serves as an input to Commit User Stories, Create Sprint Backlog, Estimate Tasks, and Create Release Plan.
• Uses relative sizing techniques such as Planning Poker, affinity estimation, and Fibonacci-based scales.
• Estimates are owned by the Development Team and reflect collective understanding and risk.
• Supports Product Owner decisions by linking value to effort for prioritization and forecasting.
• Gets refined over time as epics are split, acceptance criteria mature, and new learning emerges.

Purpose

Estimated User Stories provide a shared view of the size and complexity of backlog items so the team can forecast how much work fits in a sprint and how many sprints are needed for a release. They also improve transparency for stakeholders by showing effort drivers and uncertainty.

Key Terms & Clauses

• Story points: A relative measure of size and complexity using a consistent reference story.
• Estimation scale: Common sequences include 1, 2, 3, 5, 8, 13 or T-shirt sizes mapped to points.
• Reference story: A well understood story used to calibrate all other estimates.
• Planning Poker: Collaborative technique to reach consensus and reduce anchoring.
• Spike: Time-boxed research story to reduce uncertainty before re-estimation.
• Velocity: Average points completed per sprint, used for forecasting and committing.

How to Develop/Evaluate

1. Prepare the backlog: Ensure stories are independent, negotiable, valuable, estimable, small, and testable, with initial acceptance criteria.
2. Select a scale: Agree on story points or ideal time and pick a reference story to anchor estimates.
3. Facilitate estimation: Use Planning Poker or affinity estimation with the whole Development Team.
4. Handle uncertainty: Create spikes for unknowns, split epics into smaller stories, and capture assumptions.
5. Check consistency: Compare to reference stories, look for outliers, and seek consensus on the final number.
6. Record results: Update the product backlog with estimates and brief rationale for traceability.

How to Use

• Commit User Stories: Combine story point estimates with known velocity and capacity to select stories for the sprint.
• Create Sprint Backlog and Estimate Tasks: Break selected stories into tasks and add hour-level estimates if the team uses them.
• Release planning: Use cumulative points and velocity to forecast release scope and dates.
• Prioritization: Help the Product Owner balance value against effort for ordering the backlog.
• Progress tracking: Feed burn-up and release burndown charts with completed points per sprint.
• Continuous refinement: Re-estimate when stories are split or when significant learning changes perceived effort.

Example Snippet

Sample estimated backlog entries:

• US-101: As a customer, I want to reset my password so I can regain access. Estimate: 3 points. Acceptance: token email sent, link expires, audit logged.
• US-118: As a user, I want to filter results by date and category to find items faster. Estimate: 5 points. Acceptance: multi-select filters, persisted state.
• US-130: As an admin, I want to export reports in CSV. Estimate: 8 points. Acceptance: configurable columns, UTF-8 encoding, handles 100k rows.

Risks & Tips

• Risk: Anchoring on the first number. Tip: Use blind voting and discuss differences before revoting.
• Risk: Equating points to hours. Tip: Keep points relative and use velocity for time-based forecasts.
• Risk: Estimating vague stories. Tip: Clarify acceptance criteria and split large stories before sizing.
• Risk: Management-imposed estimates. Tip: Scrum Master safeguards team-owned estimation and consensus.
• Risk: Never revisiting estimates after learning. Tip: Re-estimate when uncertainty changes materially.
• Risk: Ignoring dependencies. Tip: Note technical and external dependencies that may affect effort and order.

PMP/SCRUM Example Question

A Scrum Team has produced Estimated User Stories using story points. During sprint planning, what should they do with this information?

1. Convert points to hours so the Product Owner can assign tasks to developers.
2. Use team velocity and the estimated user stories to select a realistic set of stories to commit.
3. Ask the Scrum Master to set the sprint scope based on stakeholder requests.
4. Replace estimates with T-shirt sizes to make reporting simpler.

Correct Answer: B - Use team velocity and the estimated user stories to select a realistic set of stories to commit.

Explanation: Estimated User Stories are an input to committing user stories and creating the sprint backlog. The team uses velocity to choose how many story points they can complete, not to convert points to hours or let others assign work.