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
  82% (37)
• B
  7% (3)
• C
  11% (5)

Explanation

Story points are a relative measure - a team assigns point values by comparing stories to a reference story (the benchmark), and that benchmark is unique to each team's context, velocity, and shared understanding. This makes the numbers meaningless to outsiders: a "5-point story" for one team could be a "2" or a "13" for another, with no universal conversion rate.

Why B is wrong: Technical understanding isn't the core issue - even someone with full technical context couldn't interpret story points without knowing what the team's reference point is. The abstraction problem is about the scale, not the implementation details.

Why C is wrong: Decomposing into Sprint Backlog Items is a planning activity, not an estimation activity. Story points are assigned before that breakdown happens, and the difficulty of explaining them exists independently of task decomposition.

Memory tip: Think of story points like a grading curve - your "A" means nothing to someone from a different class with a different curve. Estimates are team-relative, not universal.

No community discussion yet for this question.