Comparisons

Scrum vs Kanban vs Shape Up

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 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 and the Product Owner's 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 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 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, 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 makes that parallel work visible, and good backlog refinement 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 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

Bootcamps referred in this Guide

Bootcamp2 weeks

Product Manager Foundations

In 2 weeks, you’ll learn the end-to-end product process used by modern teams, from finding real problems to shipping, measuring, and iterating. Expect live sessions, practical exercises, and the core frameworks you’ll keep reusing across any product you touch.

See the bootcamp

Bootcamp1 week

Beyond Agile

If ‘doing Agile’ isn’t delivering outcomes, you need a better operating model. Learn how modern product teams balance discovery and delivery, define outcomes, and build a cadence that actually produces value.

See the bootcamp

Track16 weeks

Product Management Starter Track

A guided track that bundles the essential skills for early product builders: discovery, strategy basics, execution, and communication. Designed to give you a structured path, not random courses.

See the track

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

Written by

Andre Albuquerque

CEO of Builders Camp, SuperOperator, and other companies. Building products.

LinkedIn More guides by Andre Albuquerque

Last updated 2026-09-27

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.