Shape Up vs. the Scrum Guide — an assessment and comparison

If you have hit the limits of Scrum, it is worth taking a serious look at Shape Up.

Shape Up was developed by Ryan Singer and published in 2019 as the book "Shape Up: Stop Running in Circles and Ship Work that Matters." The method grew out of how work is actually done at Basecamp (today 37signals), where Singer shaped it over years of day-to-day product development.

→ basecamp.com/shapeup

I want to start with a short assessment. After that you will see the differences laid out side by side.

Part 1: My assessment

Bets instead of a backlog

Shape Up works with bets instead of a backlog. I consider this a very significant improvement over the Scrum Guide.

In the agile transformations I have helped to shape, we also worked from hypotheses or from a business case. Both are close to the idea of a bet.

A backlog quickly fills up with things that are not relevant. You lose focus, you may end up building things that were not yet needed, and you drift away from the Lean philosophy, which takes care to reduce waste across the eight types of muda.

Shape Up returns to those roots and concentrates on bets. Their tight frame contains the work sharply and keeps waste out from the start.

Cycles instead of sprints

Another step forward is the cycle. We all know "waterfall in sprints" and the jokes about it — and the jokes come from real experience: teams end up working forever on things that may never deliver the intended value.

Fixing the cycle length in Shape Up prevents exactly that and reduces the risk of quietly slipping back into waterfall.

Small, dedicated teams with focus

In the Shape Up model, teams are smaller and dedicated to one bet.

In Scrum teams, reality often looks different: teams are too big, not truly cross-functional, not fully empowered, and pulled across many projects at once.

In most companies, a complete Scrum implementation has rarely happened — except in those that took the agile transformation seriously and combined Scrum with other methods from the start.

No process theatre — outcome instead of tickets

Shape Up does not prescribe a fixed process for recurring events. That prevents "process theatre."

There are organisations that hold every event mandated by the Scrum Guide, yet the intended effect never materialises. Following the process does not guarantee that the philosophy behind Agile is actually lived.

Shape Up focuses on projects, on outcome.

Scrum, when it is not reflected on carefully, can quickly turn into a system where people focus more on the process than on the outcome.

There are organisations where engineers just work off a heap of tickets and lose sight of the bigger picture.

Shape Up prevents this from the start: no tickets are created; instead, bets are formulated clearly enough that a team even has the chance to work cross-functionally on a piece of work with outcome and value.

Many Scrum teams never get that chance.

Kill criteria from day one

There are organisations that introduced Scrum but never trained their leaders on what Agile actually changes for them.

The consequence: no one defines kill criteria, no one defines stop conditions. Outcome is not measured with hard facts and data.

There are organisations that did understand this and ran their agile transformation with exactly these guardrails. But that is not the norm.

Shape Up is a good alternative for a second attempt. It is clear from the outset when work will be stopped. There is no runaway train — the situation where something gets extended simply because no one defined how to stop it.

The train has no brakes is a well-known German song. And I sometimes think of it when companies have no method for stopping initiatives that are not delivering the value they hoped for — because the desired value was never defined precisely enough, and because no one gave decision-makers a lever to pull.

Shape Up is an ideal alternative for learning exactly that discipline.

Cutting scope, not quality

Scrum, taken seriously, already says that quality must be held and that scope is what gets adjusted.

Which logically means: scope must be reduced regularly in order to deliver an increment at the required quality.

In practice this rarely happens, in part because it is far from intuitive.

Shape Up is lighter here and forces the team to deliver something within the cycle that satisfies the bet.

That cuts scope while quality stays constant. The tight boundaries are useful precisely for learning the counter-intuitive work of reducing scope.

The portfolio level is part of the design

The Scrum Guide does not prescribe a scaling framework. That is why things like the Spotify model and SAFe came about.

Shape Up thinks about the next level from the start.

In the agile transformations I was part of that really did move the needle, the portfolio level was designed in from day one.

Because that is the lever — to avoid doing too many things at the same time, to steer, to stop.

You always need to think about that level, and, if possible, one level above it as well.

Shape Up helps enormously here. And it is lighter than SAFe.

Limits and prerequisites: where Shape Up alone will not carry you

Shape Up will be difficult to implement in teams that do not only build products or software but also handle a heavy stream of requests, daily business, maintenance, operations, and service requests.

Shape Up alone will not cover that; additional methods will be needed.

Another major challenge is when multiple teams are required whose outcomes build on each other or must be integrated.

These questions have to be thought through in advance, so that the bets fulfilled by the different teams do not float free but can be integrated with each other.

For this, you need to look very carefully at each company and design additional, tailor-made frameworks that make everything mesh.

Shape Up will also not work where hierarchical structures or reporting lines make implementation impossible, or where leaders have not yet developed their own vision for what agile working means.

The ground has to be prepared through an active engagement with the underlying philosophy, which itself is rooted in Lean and has been developed over decades.

And for each project run under Shape Up, hierarchies and reporting lines need to be adjusted so they do not work against it.

Lean practice in the automotive industry likes to use war rooms — obeya in Japanese. It is worth asking whether, during the transformation phase, something of that kind is needed, literally or figuratively, to give a new method like Shape Up any soil at all in which to grow.

Lean has never been a grassroots movement; it has always been introduced by top management. It is therefore important that organisations engaging with Shape Up discuss from the top down how they understand it and how they want to apply it.

Part 2: Overview — Shape Up vs. Scrum Guide (2020)

Sources: basecamp.com/shapeup (Ryan Singer) · Scrum Guide 2020 (Schwaber/Sutherland). Only statements that can be supported directly by these two sources. Where one source says nothing on a topic, this is marked as such.

1. Character of the method

Scrum Guide

• defines itself as a lightweight and deliberately incomplete framework
• declares itself immutable: implementing only parts of it, according to the Guide, is not Scrum
• describes no concrete techniques; states that tactics are context-dependent and described elsewhere

Shape Up

• a book that describes how Basecamp works
• contains concrete techniques (e.g. breadboarding, fat marker sketches, hill charts)
• the "Adjust to Your Size" appendix explicitly separates core truths from specific practices, i.e. adaptation is expected

2. Work inventory & selection of work

Backlog

• Scrum: the Product Backlog is the single source of work for the Scrum Team; emergent, ordered, continuously refined
• Shape Up: the chapter "Bets, Not Backlogs" — there is intentionally no central backlog; instead there are decentralised lists and a small number of potential bets per cycle. The book's reasoning: important ideas come back on their own

Deciding what gets built

• Scrum: the Product Owner orders the Product Backlog; the Developers pick items from it during Sprint Planning
• Shape Up: the Betting Table — a meeting during cool-down in which stakeholders decide which pitches to bet on for the next cycle

Preparing the work

• Scrum: Refinement as an ongoing activity (breaking items down, adding detail, order and size)
• Shape Up: Shaping as its own track running in parallel with building; the output is a pitch with five components: problem, appetite, solution, rabbit holes, no-gos

3. Time model

Cycle length

• Scrum: Sprints of one month or less; a new Sprint starts immediately after the previous one
• Shape Up: six-week cycles plus two weeks of cool-down between cycles

Cool-down (Shape Up only)

• time for ad-hoc work, bug fixes and the Betting Table
• the Scrum Guide contains no comparable element

Handling scope and time

• Shape Up: "Fixed time, variable scope" — the appetite defines how much time you want to spend, instead of estimating how long something will take
• Scrum: the Developers decide how much fits into a Sprint; the Guide names past performance, capacity and Definition of Done as the basis for the confidence of the forecast; the Developers are responsible for sizing items

4. Focus, interruptions & parallel work

Shape Up

• according to the glossary, a bet is the decision to dedicate a team to a project for one cycle without interruption, with the expectation to ship
• an explicit "Uninterrupted time" section in the chapter on the Betting Table
• "Keep the slate clean": the next cycle starts without carried-over commitments
• bugs are not pulled into a cycle; they are handled during cool-down (section "What about bugs?")

Scrum

• the Scrum Team is one unit focused on one objective at a time: the Product Goal; it must be fulfilled (or abandoned) before the next one begins
• no changes are made during the Sprint that would endanger the Sprint Goal
• working in Sprints at a sustainable pace, according to the Guide, improves focus and consistency
• the Guide does not regulate whether people or teams may work on multiple products/projects in parallel; the topic is not covered

Team composition

• Scrum: one Scrum Team of typically 10 people or fewer; when multiple teams work on the same product, they share Product Goal, Product Backlog and Product Owner
• Shape Up: project teams of one designer plus one to two programmers; teams are staffed per cycle/project — one of the questions at the Betting Table is "Are the right people available?"

5. Roles

• Scrum: three defined accountabilities — Product Owner, Scrum Master, Developers; the Product Owner is one person, not a committee
• Shape Up: defines no roles in the sense of the Scrum Guide
  • describes activities and groups of people: shapers (senior people, according to the book), participants at the Betting Table, building teams
  • a process role comparable to the Scrum Master does not appear in the book

6. Events

• Scrum: five events — Sprint (container), Sprint Planning (max. 8 h), Daily Scrum (15 min), Sprint Review (max. 4 h), Sprint Retrospective (max. 3 h); time boxes apply to a one-month Sprint
• Shape Up:
  • describes the Betting Table during cool-down as the recurring meeting
  • Daily, Review and Retrospective do not appear in the book
  • status communication runs via hill charts, section "Status without asking"

7. Planning during execution

Scrum

• Sprint Backlog = Sprint Goal + selected items + plan; continuously updated during the Sprint
• items are often broken down into work units of one day or less; how this is done is decided by the Developers alone

Shape Up

• teams are assigned projects, not tasks ("Assign projects, not tasks")
• the book distinguishes "imagined tasks" (thought of up front) from "discovered tasks" (found during the work)
• work is organised into scopes — parts of the project that can be built, integrated and finished independently
• nice-to-haves are marked with "~" and are dropped when time runs out

8. Non-delivery & termination

• Shape Up: circuit breaker — projects that do not ship within a cycle are not extended by default; they end. Extension is the exception (section "When to extend a project")
• Scrum:
  • a Sprint can be cancelled if the Sprint Goal becomes obsolete; only the Product Owner has this authority
  • items that do not meet the Definition of Done go back to the Product Backlog
  • a default mechanism that ends initiatives does not exist in the Guide

9. Completion & quality

• Shape Up: "Done means deployed" — done means shipped within the cycle
• Scrum:
  • Definition of Done as a formal description of the quality state of an Increment
  • increments can be delivered at any time; the Sprint Review is explicitly not a release gate

Handling growing scope

• Shape Up: scope hammering — design, implementation or use cases are questioned to finish inside the fixed timebox; the book states: "Cutting scope isn't lowering quality"
• Scrum: scope can be clarified and renegotiated with the Product Owner during the Sprint without endangering the Sprint Goal; quality does not drop

10. Theoretical foundation

• Scrum: grounded explicitly in empiricism and Lean thinking; three pillars (transparency, inspection, adaptation) and five values (commitment, focus, openness, respect, courage)
• Shape Up: contains no comparable theory or values chapter; as recurring motives the book itself names, among others, targeting risk and handing responsibility to teams

11. Portfolio level (Flight Level 3)

• Shape Up describes a recurring decision mechanism above the team level: pitches → Betting Table → one bet per cycle; together with the Betting Table questions (Is the problem relevant? Is the appetite right? Is the solution attractive? Is now the right time? Are the right people available?)
• the Scrum Guide describes no level above the Scrum Team or above multiple teams working on one product; scaling is only mentioned in that multiple teams on the same product share Product Goal, Backlog and PO
• neither source uses the term "portfolio"