Estimated User Stories

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.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Seven sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Advance your Lean Six Sigma expertise!

HK School of Management helps you take Lean Six Sigma to the next level without the overwhelm. Master advanced statistical tools, Excel-based analysis, and real-world improvement techniques to solve complex problems with confidence. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More