Why no 1-point stories?

If every story rounds to 1, your baseline drifted. Recalibrate; don't shrink the scale.

Story points are relative. A point is whatever the team agreed a point was when they picked their reference story. The Fibonacci-shaped scale exists so that small differences register as small numbers and large differences register as large ones — 2 is materially bigger than 1, 3 is materially bigger than 2, 8 is in a different category from 3. The moment a team has a steady stream of 1-point stories, that gradient is gone. Everything tiny is a 1, everything bigger than tiny is a 2 or 3, and the scale has collapsed to a binary.

The fix isn't "ban 1s," which is the cargo-cult version of this rule. The fix is to ask why the team is sizing so much work at the bottom of the scale. Almost always, one of three things is happening: the reference story has drifted (team got faster, the original "1" is now genuinely smaller than anything they ship), the team is over-decomposing in refinement (every small task is a story instead of an AC on a bigger one), or the work has shifted toward a category the team can ship easily and points need rebasing.

The reference-story drift case

Pick a story the team shipped six months ago and would now estimate as a 1. If "I'd point that a 1 today" is true, the team's reference story has moved. The work hasn't gotten smaller; the team's calibration has shifted. The fix is to pick a new reference — something the team shipped recently, that everyone remembers, that takes effort to ship but isn't large — and re-anchor against that. Velocity will look different against the new reference; that's expected and fine. See velocity for the rebasing pattern.

The over-decomposition case

If the team is producing 1-point stories because someone broke a 5 into "one-point chunks" during refinement, the team has decomposed past the point of usefulness. Each 1 should still be a thing a user notices. "Update the button text" probably isn't a story; it's an AC on something else. Splitting by acceptance criteria covers the related anti-pattern — pulling ACs out as standalone stories when they're not independently shippable.

The work-mix case

Sometimes the team's actual work has shifted toward small things. A team in maintenance mode for a quarter will legitimately have more 1s than a team mid-feature-build. That's not drift; that's a real change in what's on the backlog. In that case, points are doing their job — the team's velocity reflects that the work is small — and the fix is to notice the pattern, not to "promote" everything to a 2.

The cases where a 1 is genuinely fine

Some 1-point stories are real and shouldn't be split, combined, or upgraded. A copy-change ticket that needs review by legal. A version-bump that requires a release note. A single config-file change that touches a production system. Each of these is small in effort and meaningful in process. The team votes 1 and ships it the same day. That's the scale working correctly; there's nothing to recalibrate.

The signal to watch isn't "no 1s ever." It's "1s as 60% of the backlog." A backlog with one or two 1s per sprint is fine. A backlog where every other story is a 1 is telling you the calibration question hasn't been asked in too long.

If 1s are everywhere, the reference story drifted. Pick a new one. Don't expand the scale; recalibrate it.

Adjacent: velocity for what a reference-story change does to the rolling average; re-estimating for what to do with in-flight stories after a recalibration; common mistakescovers point inflation as the inverse failure mode.