Story Point Estimator

A story point is not an hour, a day or a unit of money. It is a mark on a ruler that one team made for itself, and the ruler only works inside that team. Everything useful about story points follows from accepting that, and most of the trouble comes from forgetting it.

The encyclopedia entry that covers story points calls them a sort of arbitrary unit, used to show the work remaining on a burndown chart. That sounds dismissive. It is actually the point. Nobody can say how long a feature will take before it is built, but a team can usually say that one piece of work looks about twice the size of another. Relative judgement is easier and steadier than absolute guessing, so teams size work against each other rather than against the clock.

Why the numbers on the cards are spaced out

The scales teams use make the relative idea visible. A replication study of story point estimation notes that the Fibonacci series and T-shirt sizes are the scales usually recommended, and a deck that follows the sequence runs 1, 2, 3, 5, 8, 13, 21, 34, 55 and 89. Some teams prefer a doubling scale of 1, 2, 4, 8 and so on, and many size with S, M, L and XL before turning the letters into points.

The gaps matter. Calling one task exactly twice another is a precision nobody has. With a Fibonacci scale, something a little more than a 5 has to be called an 8 or a 13, and a person who wants to say 6 has to decide whether their doubt is real. The steps widen as the numbers grow, so a big estimate never looks more certain than it is. A wide card says, honestly, that a big item is a fog.

Those numbers are only meaningful to the people who chose them. One team’s 5 can be another team’s 13 for the same work, and neither is wrong. The ExtremeProgramming.org page on velocity makes the same point from the other end: each team has its own bias, some estimating high and some low, and that does not matter in the long run as long as the team stays consistent with itself. The same page warns against dividing velocity by the number of people or using it to compare two projects.

The research record agrees that points resist outside prediction. One open dataset gathered 23,313 issues with story points from 16 open source projects to train a model to predict them. A later replication that added more data found that the model beat a plain median guess with statistical significance in only 8 of 42 comparisons, and concluded that the wording of a story was not enough to tell its size. Size is something a team decides, not something hidden in the text.

Hidden votes, revealed together

The idea of collecting estimates privately before anyone discusses them is older than agile software. The Delphi method was developed at the RAND Corporation in the 1950s and 1960s as a forecasting tool. In the 1970s Barry Boehm and John Farquhar adapted it for software as Wideband Delphi, so called because it added more discussion between the experts than the original.

Boehm’s steps are short. A coordinator hands each expert the specification. The group meets to discuss the problem. Each expert then fills in an estimate anonymously, the coordinator shares a summary, and the next meeting concentrates on the points where the estimates differ most. Then everyone estimates again, still anonymously, for as many rounds as it takes. A later variant has the team revise its figures without revealing specific numbers until nobody wants to change or the range is acceptable.

Estimation cards are the quick form of the same idea. Everyone picks a card in private and all the cards turn over at once, so nobody’s figure is heard before everyone else has formed their own. Then the people with the lowest and the highest cards explain first. The low voter may know that a library already does half the job. The high voter may have remembered a migration nobody else thought of. Very often the spread is not noise but two different pictures of the work, and the discussion merges them before the next round.

So the outlier is not a problem to be averaged away. If four people play 3, 5, 5 and 21, the average of 8.5 hides the one fact the team most needs, which is that someone sees a much bigger job. That is why the tool on this page shows the lowest and highest voters by name after the reveal and asks them to speak first, keeps every round, and lets the team record the size it agrees on rather than computing one for it.

The Scrum Guide puts responsibility for sizing with the people who will do the work. A session is a short conversation with a structure, not a ritual, and an item that will not converge after a few rounds is usually an item that needs splitting or more information.

What velocity is and is not

Velocity is the sum of the points for the work actually finished in a sprint. The ExtremeProgramming.org page describes it as simply as that: add up the estimates of the stories completed in the iteration. Because the points are the team’s own ruler, velocity is that team’s own pace measured on that ruler. It is a planning input, not a productivity score.

Used as a target, it breaks. A study of performance metrics in practice found story points and burndown charts in wide use, and found teams struggling with a lack of transparency, a lack of standard meaning and insufficient accuracy. Since each team sets its own scale, sizing more generously raises velocity while the work itself stays the same. The Agile Manifesto’s principles name working software as the primary measure of progress, and velocity is at best a shadow of that.

Forecasting with ranges

Velocity earns its keep in one question: how many sprints will this backlog take? The Scrum Guide gives the honest starting point. In complex work what will happen is unknown, and only what has already happened can be used for decisions about the future. The more a team knows about its past performance, the more confident its forecasts can be.

The usual shortcut divides the backlog by the average velocity. It gives one number and hides the spread. A Monte Carlo forecast keeps the spread. The general pattern of Monte Carlo methods is to define the possible inputs, draw them at random, compute a result for each draw, and gather the results. Here the inputs are the team’s own past sprints. Each simulated future sprint is one past sprint picked at random with replacement, which is the resampling idea behind the statistical bootstrap, and each trial keeps adding sprints until the backlog is done.

A worked example shows why the range matters. Take six past sprints of 18, 23, 20, 15, 26 and 21 points and a backlog of 120 points. The average is 20.5, and 120 divided by 20.5 is about 5.9, so the shortcut says 6 sprints. The best past sprint every time would need 5; the worst every time would need 8. Run 10,000 trials with seed 1 in the tool above and half of them finish within 6 sprints, but the 85th and the 95th percentiles are both 7 sprints.

The exact answer agrees. With only six past values, every possible sequence of sprints can be counted, and the chance of being done within 6 sprints comes to about 66 percent. A plan pinned to the average therefore misses one time in three. The 85th percentile, 7 sprints, is the kind of line a team can stand behind, and the 95th says when a later finish would be truly surprising.

Percentiles here mean what the NIST handbook says they mean: the value that a given share of outcomes do not exceed. The handbook also notes there is no single agreed way to interpolate between data points, so the tool uses the nearest-rank rule, which always returns a sprint count that actually occurred in the trials.

Why a forecast is not a commitment

Every forecast carries assumptions, and this one has three that matter. The coming sprints must resemble the sampled ones: same team, same sprint length, same way of sizing. Each sprint is treated as independent of the last, which ignores streaks such as a holiday season. And the backlog is assumed fixed, although real backlogs grow. Break any of these and the numbers stop meaning what they say.

The method also cannot see what has never happened. Six sprints of history cannot predict a reorganisation, an outage or a new regulation. Few data points mean wide uncertainty that resampling only partly reveals, which is why the tool refuses to forecast from fewer than three sprints.

The manifesto prefers responding to change over following a plan, and a range is how a plan leaves room for change. Say “85 percent of simulated futures finish within seven sprints, assuming the scope holds” and the listener hears both the estimate and its conditions. Say “it will be done on the fourteenth” and the conditions vanish, though the uncertainty does not. Rerun the forecast every sprint with the newest velocity, and the range narrows on its own as the work gets done.