The Bucket System: Estimating Very Large Backlogs
The bucket system is affinity estimation's more structured sibling, built for backlogs so large that even silent spectrum-sorting is too slow one item at a time - think portfolios with hundreds of items, not dozens. Instead of arranging items along a continuous line, the team sorts each item directly into one of several labeled, numbered buckets, in parallel, with discussion reserved only for items that are genuinely hard to place. This page covers how it works and when it's worth reaching for over affinity estimation or Scrum Poker.
How it works
Set up a row of labeled buckets, each representing a size - a common scale is 1, 2, 3, 5, 8, 13, 20, 40, 100, extending the usual Fibonacci-style gaps further to cover a much wider range of item sizes than a typical sprint backlog needs. Each participant takes a stack of backlog items and sorts them into buckets independently and in parallel - not one at a time as a group, but many people working through the pile simultaneously, the way sorting a deck of cards into suits goes faster with several people than one.
Items that land in the same bucket across multiple sorters need no discussion - the group has implicitly agreed. Items that different sorters place in different buckets get a brief conversation, and the group settles on a bucket together. The bulk of the backlog moves through with zero discussion; the discussion budget concentrates entirely on the genuinely ambiguous items.
Why it scales further than affinity estimation
Affinity estimation's silent-sort phase still processes items roughly one at a time along a spectrum, even without discussion - useful for dozens of items, but the linear ordering itself becomes slow past a few hundred. The bucket system parallelizes harder: multiple people sorting into a fixed set of buckets simultaneously, with no need to agree on exact position within a bucket (only which bucket), processes a much larger volume in the same amount of time. This is the reason portfolio-level estimation - hundreds of items across multiple teams or a multi-quarter roadmap - reaches for buckets specifically, not spectrum sorting.
A worked example
A program with 300 backlog items across four teams needs a rough portfolio-level sizing pass before quarterly planning. Five people each take a stack of roughly 60 items and sort independently into nine labeled buckets (1 through 100) over about 40 minutes. A follow-up session compares results: most items landed in the same bucket regardless of who sorted them, and the group spends 20 minutes discussing the roughly 30 items that got split across two adjacent buckets by different sorters. 300 items sized in about an hour of total effort - a volume that would make either Scrum Poker or even affinity estimation impractical.
What you give up
Same trade-off as affinity estimation, more pronounced: almost no per-item discussion means almost none of the hidden-complexity-surfacing that makes Scrum Poker valuable. An item can land confidently in the wrong bucket if the sorter simply doesn't know something a domain expert would - and unlike affinity estimation's spectrum, where a badly-placed item is visually obvious next to its neighbors, a bucket sort hides that error inside a bucket full of superficially similar-sized items. This makes the bucket system strictly a first-pass triage tool for volume no other technique can handle reasonably, never a substitute for real estimation on work that's actually about to be built.
Bucket system vs. affinity estimation vs. Scrum Poker
| Bucket system | Affinity estimation | Scrum Poker | |
|---|---|---|---|
| Best backlog size | 100s of items | Dozens of items | A handful of sprint-ready stories |
| Discussion per item | Almost none | Minimal, review pass only | Full, on every story |
| Parallelizable | Yes - many sorters at once | Partially | No - one item at a time |
| Produces a velocity-ready number | With the bucket labels themselves | Needs a mapping step | Yes, natively |
| Right stage of the cone of uncertainty | Very early, vague | Early, vague | Late, refined |
When to reach for buckets specifically
Not every large backlog needs the bucket system - affinity estimation handles dozens of items comfortably, and the extra structure of numbered buckets adds setup overhead that isn't worth it below a few hundred items. The bucket system earns its keep specifically at the volume where even affinity estimation's spectrum-sort starts to feel slow: multi-team portfolios, annual planning across dozens of epics, or backlog cleanup after a long period without regular refinement.
After the bucket sort
However a large backlog gets its first rough sizing pass - buckets, affinity, or otherwise - the items that are actually entering the next sprint still deserve a real Scrum Poker round with full team discussion. Create a free room once the top of your backlog is refined and ready.