Why are estimates expressed in terms of story points difficult to explain outside of the team?

Question

Options

• AIt requires a comparison to a benchmark, which typically varies from team to team.
• BIt requires a deeper understanding of the technical approach to implement each story.
• CIt requires breaking the stories down into Sprint Backlog Items, which only the team can do.

• A
  71% (15)
• B
  10% (2)
• C
  19% (4)

Explanation

Story points are a relative estimation technique - a team assigns points by comparing stories to each other or to a reference story, not by measuring absolute effort. Since each team calibrates its own scale (a "5" on one team may equal a "2" or a "13" on another), the numbers are meaningless to outsiders without knowing that team's baseline, making cross-team or stakeholder communication confusing.

Why B is wrong: Story points are intentionally designed to abstract away technical details - they capture complexity and risk holistically, not deep technical specifics. Stakeholders don't need to understand implementation to grasp an estimate.

Why C is wrong: Breaking stories into Sprint Backlog Items is a separate activity (Sprint Planning), not a prerequisite for communicating estimates. Story points exist before Sprint Backlog decomposition happens.

Memory tip: Think of story points like a restaurant's internal "difficulty rating" for dishes - useful for the kitchen team to plan their night, but if a customer asks "why does this dish take 8 points?", the number means nothing without knowing the kitchen's personal scale.

No community discussion yet for this question.