---
title: "Scrum vs Kanban vs Shape Up (and Scrumban)"
description: "Scrum vs Kanban vs Shape Up compared on cadence, roles, backlog and team fit, plus where Scrumban lands and a simple test for choosing how your team works."
canonical_url: "https://builderscamp.com/guides/comparison/scrum-vs-kanban-vs-shape-up"
date_published: "2026-09-27"
date_modified: "2026-09-27"
author: "Andre Albuquerque"
publisher: "Builders Camp"
guide_class: "comparison"
---

# Scrum vs Kanban vs Shape Up

**TL;DR:** Choose Scrum when a team needs a fixed rhythm and clear roles, Kanban when work arrives unpredictably and flow matters more than iterations, and Shape Up when a small, senior team can shape problems before committing six weeks to them. Scrumban sits between Scrum and Kanban, and the right choice is whichever one gets your team to its goals faster, not the one it follows most faithfully.

Scrum, Kanban and Shape Up all promise the same thing, shipping useful work often, and they disagree on one design choice: how time is cut up. The Scrum Guide by Ken Schwaber and Jeff Sutherland says Sprints "are fixed length events of one month or less to create consistency." Kanban, per the Kanban Guide, has no iteration at all. Shape Up, as Ryan Singer describes Basecamp's method, runs six-week cycles followed by two weeks of cool-down. Almost every other difference between the three follows from that choice.

The fourth option most teams actually run, Scrumban, is covered below too. David Pereira, the author of Untrapping Product Teams, compared all four for GoRetro and ended on a line worth keeping in front of the whole decision: "It's never about mastering a framework. It's all about improving collaboration and creating value sooner."

## How do Scrum, Kanban, Scrumban and Shape Up compare?

| | Scrum | Kanban | Scrumban | Shape Up |
|---|---|---|---|---|
| Time unit | Sprint of one month or less | None, continuous flow | Continuous flow, planning on demand | Six-week cycle plus two-week cool-down |
| Roles | Product Owner, Scrum Master, Developers | None prescribed | Usually whatever Scrum roles the team kept | Shapers and builders; a betting table decides |
| Backlog | Product Backlog, refined continuously | A board of work items | Ordered board, pull from the top | No backlog; pitches are bet on or dropped |
| Planning | Sprint Planning at the start of every Sprint | Whenever capacity frees up | When the ready column drops below a set level | Betting table during cool-down |
| Main control | Sprint Goal and timebox | WIP limits | WIP limits | Fixed time, variable scope |
| Typical team | 10 or fewer people | Any size | Any size | One designer and one or two programmers |
| Best fit | New teams, teams needing rhythm | Interrupt-driven or support-heavy work | Scrum teams that outgrew fixed Sprints | Small, senior teams on product bets |

The numbers in that table come from the primary sources: the Scrum Guide's "typically 10 or fewer people" and 15-minute Daily Scrum, Shape Up's chapter on [the betting table](https://basecamp.com/shapeup/2.2-chapter-08) for cycle length and team size, and the Kanban Guide for WIP limits.

## How does Scrum work for a product team?

Scrum gives a team a fixed heartbeat. Every Sprint starts with Sprint Planning, runs a Daily Scrum of 15 minutes, and ends with a Sprint Review and a Sprint Retrospective, and a new Sprint starts the moment the previous one ends. The Product Owner orders the Product Backlog, the Developers commit to a Sprint Goal, and the Scrum Master keeps the process honest. The detail on each event lives in the guides on [Sprint Planning](https://builderscamp.com/guides/glossary/sprint-planning-ceremony) and [the Product Owner's responsibilities in Scrum](https://builderscamp.com/guides/path/product-owner-responsibilities-in-scrum).

The strength is predictability. A team that has never worked together gets a shared rhythm in its first month, and stakeholders learn when they can expect to see progress. The weakness is that the rhythm never stops: there is no built-in pause between Sprints, and a team without a real Sprint Goal slides into a feature factory where the only goal is finishing tickets by Friday.

## How does Kanban work, and when is it better than Scrum?

Kanban drops the iteration entirely. The [Kanban Guide](https://kanbanguides.org/english/) defines it as "a strategy for optimizing the flow of value through a process" built on three practices: defining and visualizing a workflow, actively managing items in it, and improving it. The main control is a limit on work in progress, so team members start something new only when there is capacity to finish it. The guide makes four flow metrics mandatory: WIP, throughput, work item age and cycle time.

Kanban beats Scrum when work arrives unpredictably. A platform team fielding requests from six other teams, or a product team that also owns customer escalations, cannot promise a two-week plan that survives Tuesday. Kanban's weakness is the mirror image of its freedom: with no roles, no events and no goal built into the method, a less experienced team can end up curating its board instead of shipping. The [Kanban method](https://builderscamp.com/guides/glossary/kanban-method) glossary entry covers the board mechanics in more detail.

## How does Shape Up work, and who is it for?

Shape Up separates deciding from building more sharply than either of the others. Before a cycle, senior people shape a problem into a pitch: a rough solution with its boundaries, risks and an appetite (how much time the problem is worth). During cool-down, a betting table picks which pitches get the next cycle. Ryan Singer explains the six-week choice directly: "Six weeks is long enough to finish something meaningful and still short enough to see the end from the beginning."

Shape Up has no backlog at all. In the chapter [Bets, Not Backlogs](https://basecamp.com/shapeup/2.1-chapter-07), Singer writes that "Backlogs are a big weight we don't need to carry," and unchosen pitches are simply let go; important ideas come back on their own. A team that bets six weeks gets six uninterrupted weeks, and if the work is not shipped by the end, it does not automatically get more time. Basecamp calls that policy a circuit breaker.

The fit is narrow. Shape Up assumes people who can shape a problem well before handing it over, small teams of one designer and one or two programmers, and a company willing to protect six weeks from interruptions. A 200-person organisation with quarterly commitments to sales rarely has all three.

## Where does Scrumban fit between Scrum and Kanban?

Scrumban is what most Scrum teams drift into once they have outgrown fixed Sprints. Pereira points out in his GoRetro comparison that its creator, Corey Ladas, meant it as a path from Scrum to Kanban, not a permanent hybrid, but a hybrid is how most teams run it: a visible board with WIP limits, work pulled from the top of an ordered list, and planning triggered when the ready column drops below a set level rather than on a calendar.

The risk Pereira names is the lack of goals. Without a Sprint Goal, Scrumban can turn into a queue that stakeholders fill and the team empties, fast and directionless. It works best for a senior, trusted team that already knows what belongs on the board and what to keep off it.

## Which one should your team choose?

Start from the team's situation, not the framework's reputation:

| If your team... | Start with | Why |
|---|---|---|
| Is new, or has no shared way of working yet | Scrum | Fixed events build a rhythm and make problems visible fast |
| Gets frequent unplanned requests or support work | Kanban | Flow and WIP limits absorb interruptions a Sprint plan cannot |
| Runs Scrum well but finds Sprint boundaries artificial | Scrumban | Keeps the useful Scrum habits and drops the fixed timebox |
| Is small, senior and able to shape problems before building | Shape Up | Fixed time and variable scope force hard scope decisions early |

Then apply one test before and after the switch: is the team reaching its key results faster than before? Framework fidelity is not the goal. If a team follows Scrum by the book and still ships features nobody uses, the problem is upstream of the framework. Pereira's own advice is to avoid dogmatism and mix practices from different frameworks, and his summary is blunt: "No framework will get you far without a value-driven mindset."

## What does none of these frameworks tell you?

None of the four decides what is worth building. Scrum and Kanban are delivery systems; Shape Up comes closest to discovery by making shaping a separate job, but it still assumes someone already knows which problems matter. Most product teams therefore run a discovery track in parallel with delivery, whatever framework they use: some people spend part of each week testing the next problem while the rest of the team builds the current one, and the whole team takes part in both. A [triple-track roadmap](https://builderscamp.com/guides/glossary/triple-track-roadmap) makes that parallel work visible, and good [backlog refinement](https://builderscamp.com/guides/other/backlog-refinement-best-practices) keeps the delivery side from filling with untested ideas.

The honest objection to this whole comparison is that the choice matters less than it looks. A team with a clear goal, a short feedback loop and the authority to say no will do well in any of the four, and a team without those will struggle in all of them.

## Where to learn how discovery and delivery fit together

Product Manager Foundations is a 2 week Builders Camp bootcamp with 4 live sessions, taught by Andre Albuquerque and part of the Product Management Starter Track. It covers the product process from problem discovery through prioritization and roadmapping to execution, metrics and launching, including agile delivery. For teams whose problem is the operating model itself, [Beyond Agile](https://builderscamp.com/bootcamps/beyond-agile) is a 1 week bootcamp on outcome-driven planning, balancing discovery and delivery with a dual-track approach, and keeping only the rituals that earn their place.

[See the Product Manager Foundations bootcamp](https://builderscamp.com/bootcamps/product-foundations?utm_source=guide&utm_medium=organic&utm_campaign=scrum-vs-kanban-vs-shape-up)

## Frequently asked questions

### What is the main difference between Scrum, Kanban and Shape Up?

The unit of time. Scrum runs fixed Sprints of one month or less with a goal for each. Kanban has no fixed iteration at all and manages a continuous flow of work by limiting work in progress. Shape Up runs six-week cycles followed by a two-week cool-down, and only works on pitches that were shaped and bet on before the cycle started.

### Which is best for a new product team?

Scrum, usually. It gives a team that has not worked together a fixed rhythm, named roles and regular points to inspect and adjust, which is exactly what a new team lacks. Kanban's freedom tends to suit teams that already have working habits, and Shape Up assumes people who can shape a problem well before anyone builds it.

### Does Kanban have roles like Scrum Master and Product Owner?

No. The Kanban Guide defines practices (visualize the workflow, actively manage items in it, improve it) and four mandatory flow metrics: WIP, throughput, work item age and cycle time. It prescribes no roles and no meetings, so the team decides who does what.

### Is Shape Up an Agile framework?

Basecamp does not present it as one. Shape Up is the way Basecamp says it works, written up by Ryan Singer, with no backlog, small teams of one designer and one or two programmers, and fixed six-week bets. Teams outside Basecamp adopt parts of it, most often the cycle and cool-down rhythm and the idea of shaping work before committing to it.

### What is Scrumban?

A mix of Scrum and Kanban. David Pereira notes that Corey Ladas, who created it, meant it as a way to move from Scrum to Kanban, though in practice most teams use it as a hybrid: a Kanban board with WIP limits, planning triggered when the ready column runs low, and some Scrum events kept.

### Can a team switch frameworks later?

Yes, and many do. A common path is Scrum while the team forms, then Scrumban or Kanban once the rhythm is habit and interruptions become the main constraint. Change one thing at a time and check whether the team is reaching its goals faster, not whether it follows the new framework correctly.

### Where does product discovery fit in these frameworks?

Mostly outside them. Scrum and Kanban describe how a team delivers, not how it decides what is worth building. Shape Up comes closest by making shaping a separate activity before a bet. Most product teams run discovery as a parallel track alongside whichever delivery framework they use.

## Sources

- [The Scrum Guide (November 2020), Ken Schwaber and Jeff Sutherland](https://scrumguides.org/scrum-guide.html)
- [The Kanban Guide (May 2025), Kanban Guides](https://kanbanguides.org/english/)
- [Shape Up, Ryan Singer, Basecamp: Chapter 8, The Betting Table](https://basecamp.com/shapeup/2.2-chapter-08)
- [Shape Up, Ryan Singer, Basecamp: Chapter 7, Bets, Not Backlogs](https://basecamp.com/shapeup/2.1-chapter-07)
- [David Pereira, GoRetro: Scrum, Kanban, Scrumban, Shape Up! Which is the Best Fit For You?](https://www.goretro.ai/post/scrumban-scrum-kanban-shapeup)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.