What it measures

Story points are a relative estimate of effort. A team scores each backlog item against a reference task, usually on a Fibonacci-style scale, to express how much work it expects an item to take compared to others. The number folds together complexity, uncertainty, and volume into a single figure that exists only inside the team that set it.

Because the scale is relative and subjective, a story point has no fixed meaning across teams or even across quarters within one team. It is a planning input agreed in a refinement session, not a measured fact about the code. Two teams reporting the same point total may be doing wildly different amounts of work.

How to measure it

Story points live in your planning tool, not in your repositories, so they are recorded rather than computed. The honest way to read them is after the fact: take the points assigned to completed items in a window and compare the estimate to what the work actually took in git and the deploy pipeline. Match each pointed item to its branch, its commits, and the deployment that shipped it, then look at the elapsed time and the diff that resulted.

That comparison is the only part of story points worth trusting, because it grounds an opinion against evidence. A five-point item that turned into three commits and shipped in a day, next to a two-point item that churned for two weeks, tells you the estimates and the reality have drifted. The points themselves you take as given. The signal is in how far they sit from the git and deployment record.

What it does not tell you

Story points measure a team's prediction of effort, made before the work exists. They tell you nothing about what was actually built, whether it shipped, or whether it advanced anything the business cares about. Points are also trivially inflatable: a team under pressure to raise its number can re-score the same work upward, and the chart improves while nothing changes. A high point total is a measure of estimated motion, not delivered value or strategic direction.

This is the gap between an activity metric and Execution Intelligence. Story points capture how big a team guessed the work would be. They cannot tell you which initiative the work served, whether the code reached production, or what it cost to get there. Reading effort estimates is not the same as reading what is being built and why.

How InteliG uses it

InteliG does not ask anyone to enter story points. It reads the real git and deployment history with no manual instrumentation, so the size of a piece of work is taken from the commits and the diff that actually shipped, not from a pre-work guess. Where a team does keep points, InteliG sets that estimate next to the evidence so the drift between predicted and actual effort is visible.

Every unit of work is then connected to the initiative it belongs to, the contributors who did it, and the cost it carried. That turns effort from a number on a board into one input to a sharper question: was the work pointed at something that mattered, did it reach production, and what did it cost.

Related terms

Sprint Velocity — the points-per-sprint throughput figure story points feed
Cycle Time — the measured time work takes to reach production, grounded in git rather than estimated
Execution Intelligence — reading not just how much was estimated, but what is being built and why