The Sizing Rubric.

A size is "how much attention does this take from me." AI flattened the typing, so effort no longer separates the sizes — but attention still does. You can't measure attention directly, but you can spot the things that eat it. We call each one a flag: count the flags a ticket raises, and the count is the size.

Size the attention, not the typing

Raise a flag for each one that's true. Count the flags — that's the size.
Not "how much code changes" — AI does that part now — but "how much of my head does this take up." When we sized by effort, the sizes told us how long a ticket would take. They stopped: across every ticket closed Dec 2024–Jun 2026, the odds that a bigger-sized ticket actually took longer fell from 84% to 68% as AI tooling landed, and every "XS" that ran past a week turned out to be an unknown-cause investigation. Effort stopped separating the sizes. Attention still does.

Step 1 — check the ticket against these five

Each one that applies raises a flag.

UNCLEAR SPEC
Product/design decisions still open. The ticket isn't decision-complete for you yet.
UNKNOWN CAUSE
You have to investigate before you even know the fix. Unclear repro, unknown root cause.
MULTI-SURFACE
FE + BE, a proto change, a third-party integration, infra — more than one domain moves.
RISKY
Touches money, auth, or member data — anything hard to revert if it goes wrong.
HEAVY REVIEW
You expect multiple review rounds or careful manual QA. Checking it is the real work.

Step 2 — count the flags, that's your size

Flags → sizeWhat it feels likeExamples from our work
XSno flags · 1 pt Mechanical. Known pattern, one surface, reviewer rubber-stamps. Claude one-shots it; you mostly verify. Copy tweak · resolve a Dependabot alert · run a prepared migration · rename a field
S1 flag · 2 pts Clear spec, one real decision or one surface with substance. Review might go a round. Swap a model provider · remove a legacy field · org-scope a collection · a contained UI improvement
M2 flags · 3 pts Real ambiguity, or multiple surfaces move and review will iterate. All investigations start here — an unknown cause means it isn't small, however small the eventual fix looks. A new automation type · a Cal.com-style integration · redesigning the integrations page · a bug with an unknown cause
L3+ flags · 5 pts + Unknowns stacked: migration, cross-system flow, new integration, or wide blast radius. Surprises are expected. Consider splitting a timeboxed investigation out first. protobuf-es v2 migration · CubeJS reliability work · Typesense → InstantSearch conversion

Edge cases

  • New to the area? Unfamiliarity eats attention too — raise a flag. A ticket that's an S for someone who knows the subsystem is an M for someone who doesn't. That's honest, not padded.
  • Split the hunt from the fix. A mystery bug becomes a timeboxed M investigation ("find the cause"); once the cause is known, the fix gets sized on its own — usually XS or S. This keeps mysteries from being silent point-traps.
  • Reality diverged? Re-size mid-cycle — the 80% Plan already asks you to keep estimates current. An "XS" that's earned a flag by day three should pick one up; that's data for next planning.

Relationship to the 80% Plan

The 80% Plan runs on points — schedule 40, land 32 — and its Estimates section says you own those estimates. This rubric is the shared definition behind them: the same scale (XS=1 · S=2 · M=3 · L=5), just sized by attention rather than effort. Nothing else about the policy changes — reports, the cycle, and the point math all stay the same.

Source: adopted by Engineering at Tuesday planning, June 2026. Calibrated against every ticket closed Dec 2024 – Jun 2026 (n≈2,900); the full sizing analysis and technical appendix live in the team's #engineering thread.