Story Points: Agile Estimation with Fibonacci & Planning Poker

How to estimate story points correctly: Fibonacci scale, Planning Poker & Velocity explained. Learn relative estimation for agile projects. Practical guide!

Category:Agile Methods

Story points are a relative unit of measurement in agile software development used to estimate the effort required to implement a user story or backlog item. Unlike absolute time estimates (such as hours or days), story points represent a relative size that takes various factors into account.

What Makes Story Points Unique?

Story points differ from traditional time estimates through several properties:

  • Relativity: Story points express the relationship between different tasks, not their absolute duration.
  • Holism: They take into account not just the pure workload, but also complexity, uncertainty, and risk.
  • Team-Based: The meaning of a story point is team-specific and varies between different teams.
  • Abstraction: They decouple estimates from individual performance differences and external factors.

Components of Story Points

When evaluating with story points, three main factors are typically considered:

  1. Complexity: How complex is the technical implementation? How many components are affected? How much cognitive work is required?
  2. Uncertainty/Risk: How new or unknown is the technology? How high is the risk of problems? How many dependencies are there?
  3. Scope/Effort: How much "work" needs to be done? How much code needs to be written, tested, and documented?

Estimation Techniques for Story Points

There are various methods with which teams can estimate story points:

Planning Poker

The most widely used technique for story point estimation:

  • Each team member receives a set of cards with values (usually the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21...)
  • A user story is presented and discussed
  • Each team member secretly selects a card representing their estimate
  • All cards are revealed simultaneously
  • In case of large discrepancies, the reasons are discussed and re-estimated
  • The goal is consensus or at least convergence of estimates

Team Estimation Game

An alternative method that focuses on relative size:

  • User stories are written on cards
  • The team sorts the cards by size from small to large
  • After all cards are sorted, concrete story point values are assigned
  • This method emphasizes the relativity between stories

Dot Voting

A faster method for experienced teams:

  • Stories are placed on a board
  • Team members receive a certain number of "dots" (points)
  • They distribute their dots across stories based on perceived effort
  • The number of dots is translated into story points

Fibonacci Scale and Other Scales

Special scales are often used for story points:

  • Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21...): The most commonly used scale. The increasing gaps between values reflect that estimates become less precise as size grows.
  • Modified Fibonacci Sequence (1, 2, 3, 5, 8, 13, 20, 40, 100): Simplifies larger values for better manageability.
  • T-Shirt Sizes (XS, S, M, L, XL, XXL): Emphasizes the relative nature and is often used as an intermediate step before converting to numerical values.
  • Powers of 2 (1, 2, 4, 8, 16, 32...): An alternative that also reflects increasing uncertainty for larger stories.

Velocity: The Connection Between Story Points and Time

Although story points themselves are not time units, the concept of velocity enables translation into time-based forecasts:

  • Definition: Velocity is the sum of story points of all user stories that a team can complete in a sprint.
  • Calculation: After several sprints, the average of completed story points per sprint is determined.
  • Application: With a known velocity, a team can predict how many story points it can accomplish in future sprints.
  • Release Planning: Velocity enables forecasts of how long it will take to implement a product backlog.

Advantages of Story Points

  • Reduction of Psychological Biases: Avoids the tendency to round time estimates to "nice" values like hours or days.
  • Team Consensus: Promotes discussions and a shared understanding of tasks.
  • Consideration of Multiple Factors: Integrates complexity and risk, not just working time.
  • Relativity: Facilitates estimation through comparisons with already known stories.
  • Team Independence: Velocity automatically adjusts to the performance capability of the respective team.
  • More Accurate Long-Term Forecasts: Average velocity is often more reliable than time estimates.

Challenges and Pitfalls

The following problems can arise when working with story points:

  • Story Point Inflation: The tendency for story points to become "inflated" over time.
  • Over-Focus on Numbers: Story points become an end in themselves rather than a means for planning.
  • Misunderstandings with Stakeholders: Non-technical stakeholders may not understand the concept.
  • Cross-Team Comparisons: Attempting to compare story points across teams leads to false conclusions.
  • Lack of Calibration: Without regular "calibration," estimates can become inconsistent.

Best Practices for Story Points

For effective use of story points, the following is recommended:

  • Regular calibration based on reference stories
  • Consistent application of the chosen scale
  • Considering all aspects of the Definition of Done when estimating
  • Using relative rather than absolute comparisons
  • Involving the entire team in the estimation process
  • Accepting imprecision, especially for large stories
  • Splitting stories that would receive more than 13 story points
  • Focusing on dialogue and knowledge exchange during estimation

Story Points in Practice: An Example

A Scrum team has defined the following reference stories:

  • 1 Point: Simple UI text change without logic change
  • 3 Points: Adding a new form field with simple validation
  • 5 Points: Implementing a new API interface to an existing system
  • 8 Points: Development of a new feature with medium complexity
  • 13 Points: Integration of a complex new subsystem with multiple dependencies

The team now estimates new stories relative to these reference stories. After several sprints, the team finds that its average velocity is 30 story points per two-week sprint. This enables the Product Owner to forecast that a backlog of 150 story points will require approximately 10 weeks (5 sprints) to implement.

More Glossary Terms