Story Points in Development — What They Are, Evaluation Scales and Application

What Are Story Points?

Story Points are a metric of task complexity used in Scrum and other Agile methodologies. The team evaluates each task not in hours but in relative units: “this task is twice as complex as the reference.” This approach levels out the difference in speed between different developers and focuses on complexity.

Origin of the Term

The concept of story points emerged in the early 2000s with the popularization of Scrum. One of the first to describe the method was Ron Jeffries as part of Extreme Programming (XP). The idea was to move away from estimation in “person-hours,” which is always inaccurate, toward relative complexity that the team determines collectively. Today, story points are the industry standard for Agile teams.

Factors Considered in Story Points

When estimating in story points, the team considers three factors: volume of work (amount of code, screens, logic), complexity (technical challenges, new technologies), and uncertainty (unclear requirements, risks). One story point might mean “a simple task with no risks,” while 8 might mean “a complex task with high uncertainty.”

Story Point Scales: How to Choose

The choice of story point scale affects estimation accuracy and planning convenience. The most popular scale is the Fibonacci sequence, but there are alternatives.

Why Fibonacci? The Psychology of the Scale

The Fibonacci sequence was not chosen by chance. The difference between 1 and 2 is minimal (50%), while between 13 and 21 it is significant (62%). This reflects reality: small tasks are estimated more accurately, large tasks with greater spread. When a task is estimated at 21 story points, the team understands: “we don’t know how long it will take, but it’s definitely more than 13.” The Fibonacci scale prevents false precision.

The Reference Task — Foundation of the Scale

For the scale to work, the team agrees on a reference: “task X is 1 story point.” Usually a simple, well-known task is chosen as the reference: “add a text field to a screen” or “fix a typo bug.” All other tasks are estimated relative to the reference. Without a reference, story points lose their meaning — everyone understands the unit differently.

Team Velocity and Forecasting

Velocity is the average number of story points a team completes per sprint. This is a key metric for forecasting project timelines.

How Velocity Is Calculated

Velocity is calculated based on completed tasks: the story points of all tasks that the team managed to finish (definition of done is met) are summed. Unfinished tasks are not counted. For accuracy, take the average over the last 3–5 sprints. For example, if a team completed 20, 22, 18, and 24 story points over the last 4 sprints, velocity = 21 sp.

Forecasting Through Velocity

Knowing velocity and the total backlog volume in story points, you can forecast the number of sprints until release. For example, if the backlog has 210 story points and velocity = 21, it will take 10 sprints. This is a rough forecast that gets refined as work progresses. Important: velocity is an average, not a commitment. Plan based on the lower bound (18 sp) rather than the average.

How to Increase Velocity

Velocity cannot be increased by decree — it is a symptom of process health. Sustainable velocity growth is achieved through: reducing technical debt, improving code review processes, reducing context switching, automating testing and CI/CD. Important: velocity of different teams cannot be compared — each team defines story points in its own way.

Story Points vs Hours: What and When to Use

Story points and hours have different purposes, and the choice between them depends on the context. Experienced teams use both approaches for different tasks.

When Story Points Work Better

Story points are indispensable for sprint planning: they don’t depend on who will do the task. A junior might do 2 sp per day, a senior 4 sp, but the task estimate remains 2 sp for both. Story points allow tracking team productivity without comparing developers. This reduces political pressure and improves team atmosphere.

When Hours Are Necessary

Hours are needed for external commitments: contracts, budgets, client reports. A client wants to know not “8 story points” but “3 weeks.” To convert story points to hours, use historical conversion rate: the team knows that 1 sp equals approximately 4 hours of work. The conversion should be transparent and data-driven, not guesswork.

Combined Approach

Many teams use a combined approach: tasks are estimated in story points for sprint planning, and then the manager converts them to hours/days for external reporting. It’s important not to mix the two systems in one process: either you estimate in story points and derive time from velocity, or you estimate in hours directly.

Common Mistakes When Working with Story Points

Implementing story points is often accompanied by mistakes that negate the benefits of relative estimation. Here are the most common ones.

Tying Story Points to Time

The most common mistake — the team agrees: “1 sp = 4 hours.” In this case, story points lose their meaning and turn into hours with a different name. Story points should be relative, not tied to time. If task A is twice as complex as task B, it gets 2 sp, regardless of how many hours it will take.

Post-factum Estimation

When a task is estimated after it is completed — this is not estimation, it’s documentation. Story points should be assigned before work begins, at the moment of maximum uncertainty. Post-factum estimation distorts velocity and provides no planning benefit. Moreover, it creates a false sense of accuracy.

Comparing Velocity Across Teams

Comparing velocity of team A and team B is a meaningless exercise. Each team defines the reference and scale differently. For one team, 1 sp is a simple one-hour task, for another it’s a day-long task. You can only compare one team’s velocity over time: whether it’s growing or declining.

Inconsistent Scale

When different tasks with the same complexity receive different story points, and more complex ones receive fewer, the scale breaks. The team should regularly calibrate the scale: every 3–6 sprints, retrospectively review how well estimates matched actual complexity. This improves estimation consistency.