Swimlane sizing is a way to size a whole backlog quickly and without arguments. The team places story cards in unlabeled lanes, from smallest on the left to largest on the right, in silence. Only at the end do the lanes get numbers. The method was described in 2011 on The Agile Pirate blog in Swimlane Sizing – Complete & Fast Backlog Estimation, whose author sums up the point: “This approach keeps numbers entirely out of the mix until the end.”
It is useful when you have 30 or 60 stories and need a first view of the size of the whole thing, before anyone spends an hour debating a single card.
Relative estimation compares work items with each other instead of guessing hours for each one. A team finds it easier to agree that one item is about twice the size of another than to agree that it takes 14 hours. The Scrum Guide leaves the method open but says who does it: “The Developers who will be doing the work are responsible for the sizing.”
There are many relative methods: planning poker, T-shirt sizes, the bucket system, dot voting and swimlane sizing among them. Most of them end in story points, a unitless size that only means something inside one team.
Comparisons carry information even for machines. A 2026 study, Story Point Estimation Using Large Language Models, tested four models on 16 software projects. With no training examples, the models estimated story points better than deep learning models trained on 80% of each project’s data. The authors also found that the models were not better at predicting pairwise comparisons of effort, but that such comparisons worked well as examples to improve the estimates. For people, reference stories the team already understands play a similar role.
The name comes from Kanban boards, but the method borrows only the look. The Kanban Guide, updated in May 2025, defines Kanban as “a strategy for optimizing the flow of value through a process.” Kanban University’s Kanban guide explains that lanes are often used for different work types or projects to distribute capacity. Neither guide prescribes story points: Kanban teams forecast from how long work items take to flow through the board.
In swimlane sizing, each lane is a size, not a type of work, and the board is used once to size a backlog, not to track work every day.
A table or a wall the whole team can reach, tape or string to mark eight lanes, and the backlog written on cards or sticky notes. For a remote team, an online whiteboard with eight unlabeled columns works the same way. Optionally, add a few finished stories as reference points.
| Lane | 1 | 2 | 3 | 5 | 8 | 13 | 20 | Far right |
|---|---|---|---|---|---|---|---|---|
| What it means | Trivial | Small | Small to medium | Medium Sprint story | Large; consider splitting | Split before the Sprint | Too unknown to size well | Not sized: split or research first |
The source post gives three rules of thumb for reading the result: 5 is a typical medium story for a Sprint, anything above 8 to 13 needs splitting, and anything above 20 is an unknown that needs investigation first. Our guide to user story splitting shows nine ways to break those cards down. Splitting them also keeps the work in small batches, which DORA’s AI Capabilities Model from September 2025 found amplifies the benefits of AI tools.
Stories nobody can size go to the far-right lane, so that is where unclear requirements show up. That matters: in the Stack Overflow Developer Survey 2026, unclear priorities or requirements was the top answer when 18,214 developers named what made their job harder, at 16.6%.
The original post claims a backlog can be sized in well under an hour. Our own teams size and discuss 12 to 15 user stories an hour with this method. Speed comes from the silent rounds: nobody waits for a debate to end before placing the next card.
The trade-off is precision. Swimlane sizing is rougher than planning poker and doesn’t aim for full agreement on every card. Its goal is a picture of the whole backlog.
| Swimlane sizing | Planning poker | |
|---|---|---|
| Best for | A long backlog that needs a first size | The next Sprint’s stories, one by one |
| Pace | 12 to 15 stories an hour in our teams | Slower: each story gets a discussion and a vote |
| Discussion | Only on cards that keep moving or get low confidence | On every story |
| Who has to speak | Nobody, unless they rate 1 or 2 | Everyone with an outlier estimate |
| Precision | Rough | Finer |
You can use both: swimlane sizing for the whole backlog at the start, planning poker before each Sprint.
Points describe size inside one team. They are not hours and not money, and a 5 in one team isn’t a 5 in another. A founder deciding whether to build needs hours, weeks and a budget, and needs them before a team even exists. Our post on agile project estimation challenges explains why that gap trips people up.
Our project estimate starts from the same raw material as swimlane sizing: user stories. It turns your brief into stories, and you confirm what is in scope. Every hour in the budget traces back to a story you kept. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. The result is an hours range, a budget range and a number of weeks.
For a typical first version, our estimate lands in the same range as our published MVP price: $5,000-15,000 and 2-4 weeks, with more for regulated or two-sided products. For a market view, across 95 agencies the median published MVP starting price is $13,234 and the median promised timeline is 6 to 12 weeks (Rocketech MVP Price Index 2026, H2 edition). It’s a planning range, not a fixed quote. You can estimate your MVP’s cost and timeline in about four minutes, then let the team size the same stories in swimlanes once it starts.
Swimlane sizing is a relative estimation technique. The team silently places story cards in unlabeled lanes from smallest to largest, adjusts them in a second silent round, votes on confidence and only then labels the lanes with story point values.
The original 2011 description claims a backlog can be sized in well under an hour. Our teams size and discuss 12 to 15 user stories an hour with the method.
Swimlane sizing sizes a whole backlog quickly and roughly, mostly in silence. Planning poker sizes stories one by one with discussion and a vote, which is slower but more precise. You can use swimlanes for the first pass and poker before each Sprint.
No. It borrows the look of Kanban lanes, but in Kanban lanes usually separate types of work, and Kanban teams forecast from how long items take to flow rather than from story points.
Not directly. It produces story points, which only mean something inside one team. For a budget you need hours multiplied by a rate, which is what a project estimate gives you before the team starts.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.