Shape Up: Basecamp's Six-Week Cycle Method Explained

By Tara Minh · Updated Oct 12, 2026

Shape Up is a product development method created at Basecamp. Senior people "shape" rough ideas into bounded pitches, a betting table picks which ones to fund, and a small team gets one uninterrupted six-week cycle to build each bet. A two-week cool-down follows. There are no sprints, no story points, and no backlog.

Key Facts

• Shape Up comes from Basecamp, and Ryan Singer's book is free to read online.
• A cycle is six weeks long, followed by a two-week cool-down.
• Appetite is the time you want to spend, set before the solution is designed. A small batch is one to two weeks, a big batch is six weeks.
• A pitch has five ingredients: problem, appetite, solution, rabbit holes, and no-gos.
• The circuit breaker is a rule: if a project isn't finished at the end of the cycle, it doesn't get an extension by default.
• Hill charts show each piece of work as either uphill (still figuring it out) or downhill (just execution).

What is Shape Up?

Most teams don't fail because they build slowly. They fail because a project with a vague edge quietly swallows months. Shape Up attacks that problem directly. It fixes the time budget first and makes scope the thing that flexes.

Ryan Singer wrote the method down in a book based on how Basecamp runs its own product work. The book describes two groups working side by side. Shapers are a small, senior group who define the key elements of a solution before anyone commits to it, keeping it concrete enough to act on but loose enough to leave room for decisions. Builders are a small, integrated team of designers and programmers who take full responsibility for a project once it's funded, defining their own tasks and adjusting scope as they learn.

Three ideas hold the whole method together:

• Shaping happens before work is committed.
• Betting replaces backlog grooming and sprint planning.
• Building hands a whole project to a team, not a list of tasks.

If you've used Scrum, the first surprise is how little ceremony there is. The second is how much thinking happens before anyone writes a line of code.

How Shape Up works: the three phases

Phase 1: Shaping

Shaping is the pre-work. A shaper takes a raw idea ("customers keep asking for reminders") and turns it into something a team could build without further hand-holding. The book says a good shaped idea is rough (no pixel-perfect screens), solved (the main elements are worked out), and bounded (it's clear what's in and what's out).

The first move is setting the appetite. The book defines appetite as the amount of time you want to spend on a project, as opposed to an estimate. An estimate starts with a design and ends with a number. An appetite starts with a fixed amount of time and ends with a design. That flip is the whole point: instead of asking "how long will this take?", you ask "is this worth six weeks, or only two?" and design to fit.

From there, shapers sketch the key elements, look for risks and rabbit holes (places where the team could burn weeks on something unplanned), and write the whole thing up as a pitch.

Phase 2: Betting

Pitches go to a betting table before each cycle. The book names the attendees at Basecamp as the CEO, the CTO, a senior programmer, and a product strategist, so the people who can say yes are the ones in the room.

A bet is a real commitment. The book's wording is that you give the team the entire six weeks to work exclusively on that thing, with no interruptions. The most you can lose is one cycle.

Notice what's missing: a backlog. The book argues that backlogs are weight you don't need to carry, and that really important ideas will come back to you. If an idea only shows up once and never again, maybe it wasn't a real problem. Anyone who still believes in a passed-over pitch can bring it back at a later betting table.

Phase 3: Building

Once a bet is placed, the team owns the project. The book's term for this is assigning projects, not tasks. The team figures out the tasks, builds in vertical slices (one thin piece that works end to end, rather than all the backend then all the frontend), and groups work into scopes, which are meaningful chunks of the project they can finish and show.

Two practices keep the build honest:

• Hill charts show where each scope really stands.
• Scope hammering keeps the project inside the time box.

Let's look at both.

Six-week cycles and the cool-down

Work runs in six-week cycles. The book describes a cycle as a period where teams work uninterruptedly on shaped projects. Six weeks is long enough to build something meaningful and short enough that everyone can feel the deadline from day one.

After each cycle comes a two-week cool-down. The book calls it a period with no scheduled work where you can breathe, meet as needed, and consider what to do next. In practice, the cool-down is where:

• Teams fix bugs and handle small, ad-hoc tasks.
• Shapers and decision-makers hold the betting table for the next cycle.
• People recover before the next push.

Team size matters too. In a big batch, one project occupies the team for the whole cycle, and the book describes teams of either one designer and two programmers, or one designer and one programmer. In a small batch, the same kind of team works on several projects of about one to two weeks each and has to ship them all before the cycle ends.

What about bugs? The book says bugs aren't automatically more urgent than other work. Only real crises, like data loss, justify interrupting a cycle. Otherwise, you fix them in cool-down, pitch the bigger ones at the betting table, or run a dedicated bug-smash cycle.

Hill charts

A hill chart is a simple picture of progress that avoids the usual "percent complete" guesswork. Each scope is a dot on a hill with two slopes.

• Uphill: you're still figuring out the approach. The book describes this phase as full of uncertainty, unknowns, and problem solving.
• Downhill: you can see all the work involved, and what's left is execution, marked by certainty, confidence, and knowing what to do.

The team moves its own dots, so the chart reflects what they actually know. Comparing snapshots over time shows what's moving and what's stuck. The book's line on this is that a dot that doesn't move is effectively a raised hand. Nobody has to say "I'm blocked." The chart says it for them.

A practical tip: aim to get every scope over the top of the hill early. Do the uncertain, risky scopes first. Saving the unknowns for week five is how projects blow up.

Circuit breaker and scope hammering

The circuit breaker is Shape Up's answer to projects that never end. The book states that if a team doesn't finish, by default the project doesn't get an extension. That caps the downside of any bet and signals that the shaping may need rethinking before more time goes in.

Extensions do exist, but they're rare. According to the book, a project may be extended by a couple of weeks only when the outstanding tasks are true must-haves that survived every attempt at scope hammering, and the remaining work is all downhill with no open questions. Even then, the book says the appetite is usually still enforced.

Scope hammering is the practice of forcefully questioning a design, implementation, or use case to cut scope and finish inside the time box. The book notes that marking a task as a nice-to-have is the hammering itself. It also gives a useful test: compare to baseline, meaning the current reality for customers, instead of comparing to an ideal. The difference is between "never good enough" and "better than what they have now."

Shape Up vs Scrum, Kanban, and Scrumban

Shape Up isn't a drop-in replacement for every context. Here's how it differs from the most common alternatives:

Plain version: Scrum sets the clock and fills it with tasks. Kanban removes the clock and limits work in progress. Shape Up sets a bigger clock and shrinks the scope to fit. If you're deciding between the first two, see Scrum vs Kanban. For the wider family of approaches, what is Agile methodology gives the context.

Shape Up also borrows the spirit of timeboxing, but at the project level rather than the task level. The box is the cycle, and the content of the box changes, not the box.

How to try Shape Up step by step

You don't need to adopt the whole thing. The book itself suggests starting small, including running a single six-week experiment. Here's one way to do it.

1. Pick one candidate project. Choose something meaningful but not mission-critical, with a team of one designer and one or two developers (or the equivalent in your function).
2. Set the appetite before the solution. Ask what this is worth. Two weeks? Six? Write the number down first.
3. Narrow the problem. Write one specific story that shows why the status quo doesn't work. Avoid grab-bag requests like "improve reporting."
4. Sketch the elements. Use rough sketches or a plain list, not polished mockups. Leave decisions for the builders.
5. Hunt for rabbit holes. List the technical or organizational unknowns that could eat the budget. Patch them or declare them out of bounds.
6. Write the pitch. Use the template below. Keep it short enough that a decision-maker reads it in five minutes.
7. Hold a betting table. Decide yes or no. If yes, commit the full cycle and protect the team from interruptions.
8. Let the team map scopes. Builders break the project into scopes and chart them on a hill.
9. Hammer scope weekly. Move nice-to-haves below the line (the book marks them with a tilde in the to-do list).
10. Ship, then cool down. Deploy, fix leftovers, and decide what to bet on next. Don't carry unfinished work forward automatically.

Shape Up pitch template

The five ingredients below come from the book's pitch chapter. Copy this table into a doc and fill in the right-hand column. The example row is illustrative.

Shape Up examples by business function

Shape Up was written for software teams, but the logic of fixed time, flexible scope and one accountable team applies to any project-shaped work. The examples below are illustrative adaptations, not case studies.

Product. A six-week bet on a redesigned onboarding flow. The pitch sets the problem (new users stall at step three), the appetite (six weeks, one designer, two developers), and a no-go (no changes to the pricing page).

Marketing. A two-week small batch to rebuild the top comparison page. The appetite is two weeks because the page is already mostly written. No-go: new video assets. Scopes might be "copy and structure," "tables and schema," and "internal links."

Sales ops. A six-week project to clean up lead routing. Rabbit hole: legacy territory rules nobody can explain. The team uses the hill chart to surface that early, solves it in week one, and then executes downhill.

HR. A four-to-six-week bet on a new-hire checklist across IT, finance, and the hiring manager. The no-go is any change to the payroll system. Hill chart scopes: "equipment ordering," "account access," "first-week schedule."

IT. A small batch to retire a legacy tool. The circuit breaker is useful here: if migration isn't done in the budgeted time, the team stops and reshapes the plan instead of running a migration that drags for quarters.

Shape Up dos and don'ts

Do:

• Set the appetite before you design the solution.
• Write pitches that name rabbit holes and no-gos explicitly.
• Give the team a whole project and the full cycle, uninterrupted.
• Tackle the uncertain scopes first so they cross the hill early.
• Hammer scope every week, and compare to baseline instead of to an ideal.
• Use the cool-down for bugs, small fixes, and the next betting table.

Don't:

• Don't treat the appetite as an estimate you can quietly raise.
• Don't hand builders a list of tasks. Hand them a shaped problem.
• Don't extend by reflex. The circuit breaker only works if you mean it.
• Don't skip shaping because it feels slow. Unshaped work is what makes cycles fail.
• Don't keep a shadow backlog and call it something else.
• Don't copy the cycle length blindly if your work is mostly interrupt-driven support. Kanban may fit better.

When Shape Up is a poor fit

Shape Up assumes you can protect a team for six weeks and that someone senior can shape well. If your team is mostly firefighting, answering tickets, or reacting to a steady stream of small requests, a flow-based approach like Kanban matches the work better. And if nobody in your org can write a bounded pitch, start by practicing shaping on a single project before you commit to the cycle structure.

Putting Shape Up to work

Start with one pitch. Write the five ingredients for a project you've been putting off, set a firm appetite, and ask whether the idea survives being squeezed into it. If it does, you've got your first bet. If it doesn't, you've learned something cheap before spending six weeks.

Related reading

• What Is Scrum?
• What Is Kanban?
• Scrum vs Kanban
• Scrumban
• Timeboxing
• Product Backlog
• Sprint Planning
• WSJF Prioritization