Complete firstStory Points
A shared estimation scale (Fibonacci or T-shirt) has been introduced in the team and anchored with reference items.
Without: Without a calibrated scale, bucket labels are meaningless and the estimates are not comparable.
RunsheetAgile
Bucket System
ComplexityMedium
Time30-90 min
Participants3-12
FormatWorkshop
MaturityEstablished
01
Prerequisite
What needs to be finished first
Complete firstAcceptance Criteria Workshop
A short description with acceptance criteria exists for each item so sorting is not based on titles alone.
Without: Without criteria, titles are sorted and the later implementation does not match the bucketed value.
02
Preparation
What needs to be ready before start
Materials
Whiteboard or Miro board with a horizontal row of predefined buckets (e.g. 1, 2, 3, 5, 8, 13, 20); cards or notes per item; reference items visible for each bucket; timer; marker colors for annotations.
People / roles
One facilitator for process and timeboxes; one product owner for item context; the delivery team (4-12 people); one scribe for assumptions and splits.
Pre-read
List of items to sort (typically 30-150); acceptance criteria per item; reference items with assigned bucket values; known dependencies or risks.
Time needed
30-90 min
Setup
Stick the buckets horizontally on the wall (e.g. 1, 2, 3, 5, 8, 13, 20). Put a reference item into each bucket. Announce the rule: items go into one bucket only, no in-between values. Silence is the rule during sorting.
03
Core question
The one question this method answers
Which bucket does each item belong to relative to our references, and which items are so large or unclear that they need to be sliced or clarified before planning?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Calibrate buckets | 10 min | Review the buckets and reference items together. Anyone with a different understanding speaks up now. Rearrange references if needed until consensus is reached. | Without calibrated references, the bucket scale is arbitrary. If no references from delivery history exist, choose three to five items before the workshop and bucket them. |
2Phase 2: First rapid sort | 20-30 min | The team sorts items silently into buckets. Max 30 seconds per item. Gut feeling is enough, calibrated on the sample. Moving items back and forth is allowed. | If people argue in this phase, the pace breaks. Rapid sorting is the core of the method. Detailed discussion comes later in phase 3. |
3Phase 3: Check bucket consistency | 15-20 min | Compare the items in each bucket: do they really belong together? Move outliers into a more fitting bucket. Mark items in large buckets (13+, 20+) as split candidates. | If a bucket is very full (>50% of items), the granularity is unsuitable. Refine the bucket scale or handle the items in a second estimation round with a finer scale. |
4Phase 4: Splits and spikes | 10-20 min | Either split items in large buckets (13+) with a proposal, owner, and deadline, or add a spike before them. Send items in the 'too unclear' bucket to refinement. | Large buckets remain wishful thinking if no split proposal is made. If nobody can propose a split, the problem is not understood and the item belongs in discovery. |
05
Artifact
What comes out at the end
Form
Backlog with bucket value per item in the ticket system, plus a snapshot of the bucket board with date, a list of splits/spikes with owner and deadline, and assumptions per large item.
Versioning / ownership
Keep bucket values directly in the item. Archive one snapshot per workshop with the date. When an item is split, mark the old ID as 'resolved into X, Y, Z' and give new items their own bucket values.
Tool alternatives
- Miro or FigJam with a bucket template
- Physical wall with cards and photo export
- Jira with a story-point field and bucket filter
- Linear with estimate and size label
- Notion database with a bucket property
bucket-system-working-template.md
Compact working template for Bucket System with context, input, output artifacts, and next step.
Bucket System Working Template
Goal
Sorts many items into predefined estimate buckets to assess large backlogs quickly by relative size.
Context
When and for what do we use this method?
Input
Which data, observations, decisions, or materials are available?
Execution
Short notes along the runsheet.
Output artifacts
- Bucketed Backlog:
- Relative Estimates:
- Split Candidates:
Assumptions and open questions
- ...
Decision / Next step
Owner, date, and success signal.
06
Example output
Concrete filled scenario, fictional example
bucket-system-beispiel.md
Concrete filled scenario, fictional example
Bucket System - Release Q3/2026, 2026-05-18
Buckets: 1, 2, 3, 5, 8, 13, 20 story points
References
- 1: tooltip tweak
- 3: Google SSO
- 5: client export API endpoint
- 8: self-service portal slice
- 13: multi-tenant customer administration
- 20: database engine migration
Result (62 items)
- Bucket 1 (18 items): UI polish, tooltips, small bugs.
- Bucket 2 (14 items): config toggles, smaller API extensions.
- Bucket 3 (13 items): medium features, reporting modules.
- Bucket 5 (10 items): larger features, webhook system.
- Bucket 8 (5 items): complex features, workflow builder parts.
- Bucket 13 (2 items): AI receipt recognition (spike).
Splits/spikes
- AI receipt recognition -> spike @anna by 30.05. for vendor comparison.
- Workflow builder component C -> PO @lisa to split into three sub-stories by 22.05.
Velocity projection: team velocity 28 points/sprint -> ~6 sprints for bucket 1-5, separate plan for 8 and 13.
07
Pitfalls
Recognize symptoms and steer against them
Trap
In-between values are introduced
Symptom
Participants want to place items 'between 5 and 8', so the bucket system gets watered down.
What to do
The facilitator enforces the rule hard: an item goes into a bucket, not between buckets. Take the higher bucket so risk is not underestimated. In-between values destroy the scale.
Trap
Discussion in phase 2
Symptom
The team starts to argue instead of sorting quickly and the pace breaks.
What to do
The facilitator interrupts: 'Sort first, discuss in phase 3.' If the rule is broken again, take a short break and reset. Rapid sorting is the method's core.
Trap
References are outdated or missing
Symptom
Sorting runs on gut feeling and nobody can name references per bucket.
What to do
Before the workshop, bucket three to five real items per bucket. Without references, the bucket scale is meaningless. Recalibrate references every 6 months when the team changes.
Trap
Granularity is unsuitable
Symptom
More than half of the items land in one bucket and the scale uses only 1-2 values.
What to do
Bring items to comparable granularity before the workshop (e.g. all at story level, not mixed with epics). If items are too large, split them in pre-refinement.
Trap
Large buckets without splits
Symptom
Items in 13+ remain unchanged and nobody proposes a split.
What to do
Mandatory rule: no item above 13 enters sprint planning without a split proposal or a spike. Name an owner for the split. Large unsliced items are a risk.
08
Stop criteria
Done signals checkable in under a minute
No calibrated reference items are available, so the bucket scale is arbitrary.
Items have clearly different granularity, so sorting becomes inconsistent.
No delivery team is present, only the PO or stakeholders, so bucket values become wishful thinking.
More than a third of the items have unclear acceptance criteria.
Workshop time is under 30 min for more than 30 items, so rapid sorting becomes hectic and inaccurate.
The team has never used the bucket scale before, so the method becomes method learning rather than estimation.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.