Story Points and Velocity: Estimate Relatively, Forecast by Velocity

Asked how long something will take, a team starts guessing at hours it has no basis for, then treats the guess as a promise. The problem is not the team but the question: people are poor at estimating absolute durations and good at comparing. Saying "this story is roughly twice that one" is a judgment you can make with confidence; saying "this takes 17 hours" is a claim with nothing behind it. Relative estimating in story points builds on the strength rather than the weakness, and velocity turns those relative estimates into real forecasting power after a few iterations.

Definition and Foundation

A story point is a unit used to estimate the relative level of effort needed to implement a user story. That definition comes from the Eighth Edition glossary, and it carries three constraints that are often missed:

• Relative, not absolute — story points reflect relative effort or complexity rather than absolute time, based on the understanding that teams are typically better at comparing work items than at predicting precise durations.
• For user stories, not tasks — the guide shows prioritized features delivered by user stories estimated in story points, while the tasks created to deliver those stories are estimated in hours. The two levels are distinct and each has its own unit.
• Simplifying without sacrificing accuracy — the guide notes the approach simplifies planning while preserving accuracy, since estimating hours can be more time-consuming and less reliable in dynamic environments.

Velocity is a measure of a team's productivity rate at which deliverables are produced, validated, and accepted within a predefined interval. Those three words are a condition, not a description: work that has been produced but not yet validated or accepted does not count toward velocity. Velocity therefore differs from "what the team got done" in the ordinary sense of that phrase.

The predefined interval is the iteration: an agreed-upon work cycle duration, typically two weeks or one month. Determining the rate at which deliverables are produced, validated, and accepted within that period is a stated activity in tailoring the schedule under adaptive approaches, alongside conducting retrospectives and reprioritizing the remaining backlog.

How It Works in Practice

Estimating stories in points

The team compares a story against an agreed reference story and assigns it relative points. Among the techniques for estimating effort and duration the Eighth Edition names two built for this: planning poker and T-shirt sizing, alongside expert judgment, Delphi, and analogous, parametric, and multipoint estimating. Both relative techniques are collective, which limits how far one opinion can dominate the number.

Deriving velocity and using it to forecast

After several iterations a relatively stable rate emerges for what gets accepted per iteration. That rate is the forecasting instrument: 120 points of remaining scope at a velocity of 20 points per iteration implies roughly six iterations. Velocity is named explicitly among the tools and techniques for monitoring and controlling the schedule, alongside critical path, critical chain, schedule compression, and burn charts. It needs several iterations before it can be relied on: a rate built on one iteration is not a rate. This is where points and velocity meet the schedule, through agile release planning: a high-level summary timeline of the release schedule — typically three to six months — based on the product roadmap and product vision, which determines the number of iterations in the release. It lets the product owner and team determine development scope, timelines, and a releasable product, factoring in business goals, dependencies, impediments, and resource availability. Because features represent expected value to the customer, this timeline gives a more easily understood schedule: it defines which features will be available at the end of each iteration.

The link to earned value

In adaptive approaches effort can be expressed through story points, so earned value and planned value for the iterations are calculated from the points assigned to each user story. Planned value is the story points estimated for the user stories planned up to a certain date, usually the end of the iteration; earned value represents the points for stories considered done at the end of that same iteration; and actual cost relates to the costs of the team working on those stories, usually derived from working hours. Points do not insulate a team from performance measurement — they feed it.

Points on the charts

A burndown chart can show the number of story points remaining, or the amount of risk exposure that has been reduced. Burn charts, both up and down, can show project team velocity. Points are not a number that lives only inside the planning tool; they are the unit the whole visual picture of the work is built on. That dual use — estimating unit and display unit — is what makes consistent estimating matter: points assigned against shifting criteria produce a chart with no readable trend.

On the Exam

The 2026 ECO names story points outright inside Domain II, Process: Task 8, plan and manage schedule, carries the enabler "estimate project tasks (milestones, dependencies, story points)." Alongside it, Task 9, evaluate project status, carries enablers for developing project metrics and analysis, assessing current progress, and measuring, analyzing, and updating project metrics.

The dominant pattern is a management scenario asking points or velocity to carry a load they cannot. Four keys settle most of it:

• A request to compare two teams' velocity → refused, since the unit is referenced to the team itself, not a shared standard.
• A request to convert points into hours for a management report → not their purpose; stories in points, tasks in hours.
• A question about when a scope completes → remaining scope in points divided by velocity.
• A team whose velocity suddenly jumped → check what "accepted" means before celebrating; work may have been produced but not accepted.

What deceives is that the options offer management actions that look reasonable: raising the velocity target for the next iteration, rewarding the fastest team, adding people to increase velocity. All three convert a planning measure into a pressure instrument and corrupt the measure itself, because the team starts inflating its estimates. The third is also technically flawed: adding people does not raise velocity immediately, since points are calibrated to the existing team composition and need recalibrating before the new rate means anything.

Detailed Mistakes

Computing velocity from work produced rather than accepted

The definition requires all three: deliverables produced, validated, and accepted. Counting a story that "finished coding" but has not passed acceptance inflates the figure and then corrects it in the next iteration when the story bounces back. The result is a rate that swings too much to forecast with, and the cause lies in the counting method, not the team's performance. The remedy is not a stricter definition imposed on the team but a consistent one: as long as "accepted" means the same thing every iteration, the numerator settles and the rate settles with it.

Adding uncertainty to the definition of a point

The Eighth Edition defines a story point by relative effort, and elsewhere refers to relative effort or complexity. Adding uncertainty as a third dimension is common in agile literature but has no place in the guide. The distinction matters: mixing uncertainty into size makes a small but vague story carry many points, corrupting the comparability points were adopted for.

Treating one iteration's velocity as the rate

Velocity is a rate measure, and a rate needs several observations. Planning from a single exceptional iteration — high or low — builds a forecast on noise rather than signal. The nature of the work varies between iterations, and the accepted points vary with it, which is why the trend across several iterations is read rather than the latest value.

Where It Does Not Apply

Points and velocity are adaptive-approach instruments resting on iterations of an agreed duration and on a clear definition of what counts as accepted. Where there are no iterations — continuous flow work not divided into timeboxes — the "points per iteration" measure loses its denominator, and flow metrics replace it. Where there is no agreed definition of acceptance, velocity means nothing, because its numerator is undefined. A third constraint remains: points are internal to one team, so velocities from several teams are neither summed into a project figure nor compared. That is not an ethical caution but a direct consequence of the unit being relative to a reference story that team alone selected. Points still have a role in hybrid settings: where the high-level schedule is planned with predictive techniques while components with a high rate of change are run in iterations, points are used inside those components only, and are not raised to the level of the overall schedule as its unit of measure.