Story Point

Work used to be sized in time. Ask how many days and the answer is three. Give the same task to somebody else and it's six; give it to someone a month into the job and it's two weeks. Three answers attached to one task means a sum of several items says nothing at all.

It put a burden on the person answering, too. When a human says a number of days out loud, that becomes a commitment, and missing it becomes a fault. Someone who said three days and took six starts doubling every future estimate. That's safer, and a plan can't be built from those numbers, and the person listening knows they're inflated and discounts them again.

Both problems have the same root. Time varies with who does the work and it reads as an individual promise. So the thing being estimated moved from time to size. Size is the same whoever does it, and because the team sets it together it doesn't become anyone's personal commitment. A story point is the unit that size gets written in. The shift looks small, and it changes who owns the number.

Fix one reference item and score everything else against it. Five rules.

1. Nail down a reference. Pick a task everyone knows and call it a 3. With "build the login screen" at 3, something roughly twice as large is a 5 and something half the size is a 2. That reference is an agreement internal to the team, so your 3 is not the same amount of work as another team's 3.
2. The usable values are a spreading sequence: 1, 2, 3, 5, 8, 13. The absence of 6 and 7 between 5 and 8 is a deliberate constraint. The larger a task, the less is knowable about it, so the sequence prevents an argument about whether something is an 8 or a 9 from being possible.
3. Three things go into size: how much work there is, how entangled it is, and how much is unknown. A small amount of work being done for the first time can score high, and that isn't a bad estimate.
4. Nobody scores alone. Planning poker, where each person reveals a card, is the standard method, and when two people show a 2 and an 8 the numbers don't get averaged — the question is why they saw it differently. A condition one side didn't know surfaces right there.
5. Anything 13 or above gets split. That size usually signals several jobs bundled into one item, and unsplit it won't finish inside the cycle.

The number gets used as a total per cycle. The average points a team actually completes per cycle is velocity, and a plan's total gets held against that average to see whether it's a stretch. Points are an input to planning, and their meaning as numbers exists only in that comparison.

The planning meeting that decides how much goes into a cycle is the first place. A requirement written as one sentence from the user's point of view is a user story, and points get attached to that list and the total laid beside the recent average. Average 32 against a committed 40 and something comes out right there.

The second is finding items to split. Anything marked 13 or 21 gets re-read, and usually breaks into two or three. Getting that signal is half the actual return on scoring at all.

The third is a rough sense at the quarter scale. Divide the remaining points by the per-cycle average and you get how many cycles are needed. It isn't a value for promising dates; it's a value for seeing whether a plan fits inside a quarter. Treating it as a date is where it stops being useful.

What it isn't for matters more. Summing points per person to see who did more work, comparing numbers between teams, and reporting them outside the company as performance are all uses this unit can't carry. One property — the reference is an agreement internal to the team — rules out all three.

"You've got this at 8? I read it as a 3."

A question aimed at surfacing what the two of them understood differently, not at the number.

"If it's a 13, let's split it. It won't finish in one cycle."

Reading the size itself as a signal to split.

"If you're asking how many hours one point is, there's no answer."

Turning back the request to convert into time.

Pagedeck keeps one fixed reference: adding a single filter to a list screen is a 3. Theo calls values against that task when scoring something new, and when he's two steps apart from someone else they reconcile the reasoning on the spot.

One item once came back as a 2 and a 13. One person read it as a screen-only change; the other read it as requiring a change to the data structure. Mia reread the requirement and found both readings available in how it was written. After the sentence got fixed and the item rescored, both of them showed a 5. What got aligned was the sentence, not the number.

The most common move is pinning down how many hours a point is. It's a number, so it seems convertible, and converting lets you answer in dates for whoever asks from outside. But the moment a conversion table exists, the unit reverts to time. Fix one point at four hours and people start dividing their own expected hours by four to produce points, which brings back the original problem of a value that varies by person. Six months later the same item carries a 3 or an 8 depending on who scored it, and the total means nothing again.

The other frequent view is that scoring accurately is the goal. It's an estimate, so being right feels like the point, and teams spend twenty minutes on one item arguing 5 against 8. What this unit actually produces is not the number but the conversation that happens around it. What surfaces the moment a 2 and a 13 split is a condition one side didn't know, and finding that is where the usefulness lives. Teams that spend the time on precision end up with two-hour meetings, and plans built from the more precise numbers diverge from reality by exactly as much as before.