maxubrq.
Tiếng Việt
Tech ● Interactive Chapter IV đọc bản tiếng việt →

Can story points measure the growth AI gives you?

And if they can, how long does it take?

◔ read time
1–3 min · one sitting
load
need first
a little statistics will help
best when
freetime

One of the companies I worked at leaned on AI heavily across the whole Software Development Life Cycle (SDLC). Using that much AI is a form of investment, so the CEO asked for productivity to improve by 10% every quarter — and productivity, on the R&D (Research and Development) side, was measured in story points (SP). Whether the is the right way to measure productivity is a different argument and this piece will not have it; assume it is. The question here is narrower: is “10% growth every quarter” something you can actually establish?

Velocity and the basic arithmetic

In software the word “productivity” usually turns into the word “ ”, and velocity is measured as the number of SP finished in one . Productivity over a quarter, then, is many sprints — which means it is not a single number at all. It is a series.

Here is Q1, as logged:

38   45   31   42   36   48

What can we pull out of that?

The mean is , and yet not one sprint was 40. The gap between the best sprint and the worst is SP, and nothing on the outside changed across those twelve weeks: same people, same codebase, same way of working.

So the first thing to accept is that velocity swings even when nothing is happening. Not big changes — small ones. Somebody was off sick. A story turned out easier than it looked, or harder.

That swing has a size, and the is how you get at it: With and the series above, , and the is . A lot of numbers, I know. The short version: with nothing whatsoever going on, a sprint can land 6.23 points off the mean.

One more number falls out of the same data, the : which says that this team’s ordinary swing is about 15.6% of its own average. As teams go, that is a steady one.

Comparing two series

The question at the end is not any of the numbers above — trust me, they matter — it is a comparison between two series.

Q2 comes in, and the log now reads:

Q1: 38  45  31  42  36  48   →  avg: 40.0
Q2: 41  49  36  47  40  51   →  avg: 44.0

Q2’s average is 4 points above Q1’s. Exactly 10%. Time to celebrate?

Celebrate first, sure. But then: if nothing at all had acted on this team, AI included, could a 4-point gap have shown up anyway?

The usual way to compare two series is to compare their means, which is what we just did — and a mean carries an error of its own, the : What that number says is this: if you had the power to re-run Q1 in some other timeline, same team, same conditions, the mean (40) coming out 2.54 points different would be an ordinary Tuesday.

So if we could re-run both quarters in another timeline, how far apart could the two means land?

● Figure 2 re-run the quarter
-10-50510difference between the two quarterly means (points) +4 — what we actually observed

You have re-run it 8 times, in a world where nothing changed at all — no AI, no improvement, nothing. 2 of those came out +4 points or more.

Each dot is a quarter lived again: two runs of six sprints drawn from the same team, the same spread, with no improvement anywhere in it. The orange dots are the times noise alone built 'evidence' as large as the evidence we actually have.

With ,

Which gives us something to say: with nothing changed at all, two quarterly means drifting 3.49 points apart is normal. The gap we observed is 4 points, and noise alone reaches 3.5. The quick conclusion is the honest one — there is not enough here to say whether AI helped, because what we are holding is barely distinguishable from noise.

How big does a difference have to be?

Before the arithmetic, one more thing about that : it is also the width of the bell the noise is spread along. Go back to re-running both quarters in another timeline — do that endlessly and about 70% of the time the difference lands between -3.49 and 3.49 points.

Figure 1 the noise distribution
about 70% of runs land in here -10-50510difference between the two quarterly means (points) ±SE = 3.49 observed difference: +4
With nothing changed, the gap between two quarters still wanders around zero with a width of SE = 3.49. The +4 we observed sits well inside that cloud.

To detect anything and mean it, there are two ways to be wrong, and both have to be guarded against.

Type I error

A is a false alarm: nothing changed, but noise happened to throw up a gap wider than the ordinary one we just measured (3.49). To guard against it, we allow only a 5% chance of noise clearing the bar — and on a normal curve that point sits 1.96 widths out from the centre. So the bar is , which means: under 7 points, say nothing.

Type II error

A is a miss: the improvement was real, but noise dragged the number below the bar and it got read as “nothing happened”. Concretely — if the real improvement is exactly the 7 points we just computed, then across endless re-runs you catch it half the time and lose it the other half. To push the catch rate to 80%, the real improvement has to clear 7 by a margin: on a bell, shifting the centre 0.84 widths further puts 80% of the distribution to the right of the bar.

So what is needed is

Which is to say, a gap of at least 10 points before it counts as improvement.

● Figure 3 drag it
-10-505101520difference between the two quarterly means (points) the bar: 6.84
noise, when nothing has changedif the improvement is real

If the real improvement is exactly 6.8 points, then across endless re-runs you would call it an improvement about 50% of the time. The shaded tail is that share.

The grey bell standing still is noise. The blue one is a world where the improvement is real — drag it wherever you like. Park it on the bar and the shaded part is exactly half: that is where the 50% goes missing.

So how long does it take?

Let me restate the question. We know a gap has to reach at least 10 points before it counts, and we collected per quarter. The new question is “how many sprints (N) does it take to establish that the team improved by 10%?”

Generalising SE

The from earlier is one specific number for , not a formula. Assuming the two series are always the same length, it can be written out:

where

Working the threshold backwards

We also have as the point where a gap counts. Substituting the formula for gives an inequality:

In words: a real improvement has to be at least 2.8 times the noise of the comparison.

Now rearrange it for .

That is a formula for , but not yet one in percentages. To get there, divide top and bottom by — the square of the series’ mean.

And is the team’s coefficient of variation. So what does the formula say?

The numerator says how much noise, in percent, this team brings. The denominator says how much improvement, in percent, you want to catch.

With the pooled across both quarters, , and a 10% improvement to catch, so , has to be

A quick check

Put back into the formula for SE: . That gives , and . Good — the arithmetic holds.

So it takes at least 33 sprints per arm, meaning 66 sprints, before you can catch whether something has lifted productivity by 10%.

Conclusion

Back to the CEO’s question: “productivity has to improve 10% every quarter”. The answer is not “yes” or “no”. It is something more uncomfortable: with one quarter of data, that question has no answer at all.

Three numbers from this piece, side by side, say the whole thing:

  • The team already swings 15% around its own average when nothing is happening.
  • The gap to reach is 4 points; the noise of the comparison is 3.49 points. What we need to measure is barely distinguishable from pure noise.
  • To tell those two apart takes 33 sprints per arm — with two-week sprints, two and a half years of data for one conclusion.

Here is the paradox. The review cycle is a quarter, six sprints, while the measure being used to do the reviewing needs ten times that before it can conclude anything. Asking for “10% a quarter” is not wrong as an expectation. It is just not verifiable in story points — and an unverifiable demand gets answered each quarter by instinct, by a number that happened to look good, or by whoever was loudest in the meeting.

If you still want to measure it, the formula leaves exactly three knobs:

  1. Cut — make the team less noisy. scales with , so the steadier the team the less time it takes: pull the swing from 15% down to 7.5% and the wait drops to a quarter of what it was. Stories split small and evenly, estimates kept consistent, no changing the scale halfway through. This turns out to be the most valuable work on the list, and it has almost nothing to do with AI.
  2. Accept a bigger target. scales inversely with , so hunting a 20% improvement costs a quarter of what hunting 10% costs. A genuinely large effect is easier to prove than a small one is to evidence.
  3. Widen the observation window. Stop asking “did we grow 10% this quarter”; ask “after a year and a half, has the trend actually turned”.

And the last one, which matters most: none of the numbers above conclude anything about whether AI is useful. They say story points are not sensitive enough to serve as evidence for the question being asked. Those are two entirely different statements — and in an end-of-quarter review they get treated as one.

● Figure 4 your team's numbers

sprints to observe, per arm

variability7.5%10%15%20%
5%3663142251
10%9163663
20%34916

Your team swings 14.4% around its mean. The observed difference is +4.0 points against a bar of 9.8 points — not enough to say anything yet. To catch the level you picked, you need 33 sprints per arm, about 30 months.

Two levers, both squared: halve the team's swing, or double the improvement you need to catch, and either one cuts the wait to a quarter. The filled cell is where the team in this piece stands.
If you remember one sentence from Can story points measure AI?

Your team swings 15% on its own. The improvement you are looking for is 10%.

Words

marked in this piece
coefficient of variation noun · statistics
The standard deviation as a fraction of the mean — spread with the unit divided out, so two things measured differently can be compared.
normal distribution noun · statistics
The bell-shaped spread that averages tend towards — symmetric, and fully described by a centre and a width.
sample standard deviation noun · statistics
How far a single observation typically falls from the mean, in the same unit as the observations.
sample variance noun · statistics
The average squared distance from the mean, divided by n−1 rather than n because the mean was estimated from the same data.
sprint noun · agile
The fixed-length window a team plans and delivers in — the unit that turns work into a countable series.
standard error of the mean noun · statistics
How far the *average* of a sample typically falls from the true average — the standard deviation divided by the square root of the sample size.
story point noun · agile
A unit of estimated effort, agreed by the team rather than measured — relative size, not hours.
type I error noun · statistics
A false alarm — calling a difference real when nothing changed and the noise simply landed high.
type II error noun · statistics
A miss — an improvement that was real, but landed under the threshold because the noise happened to pull it down.
velocity noun · agile
How many story points a team finishes in one sprint — a rate, and therefore a series rather than a single number.
The whole dictionary lives here

Sources

cited in this piece
  1. 01
    Welch, B. L. · 1947

    The correction the sidenote leans on. Student's t-test assumes the two groups share a spread; Welch drops that assumption and pays for it with fractional degrees of freedom, computed from the two variances rather than counted from the two sample sizes. It is the honest default whenever two samples are small and there is no reason to believe their scatter is identical — two quarters of a team's sprints, for instance.

The full list lives here
a quiet word to the author not published · never shown to other readers

Did anything here change how you think about the problem?

maxubrq.space / tech A notebook, kept in public · est. 2024 © 2026