Shape Up: how Basecamp ditched sprints (and why it might work for your team too)

If your team is stuck in an endless cycle of two-week sprints that never seem to deliver meaningful outcomes, the Shape Up method offers a radically different approach. Developed by Ryan Singer at Basecamp (now 37signals), Shape Up rejects the core assumptions of Scrum—fixed sprints, point estimation, backlogs—in favor of longer cycles, fixed time with variable scope, and a betting table that forces hard prioritization decisions.

Shape Up isn’t for everyone. But for teams drowning in ceremony or struggling to ship complete features, it might be exactly what you need.

What is Shape Up?

Shape Up is a product development methodology that Basecamp refined over nearly two decades of building software. Ryan Singer documented the approach in his 2019 book (available free at basecamp.com/shapeup), and it’s since been adopted by companies like Buildkite, Chord Commerce, and UserVoice.

The framework rests on three core activities that happen in sequence:

1. Shaping — Senior people define the problem and solution at the right level of abstraction
2. Betting — Leadership commits to shaped work for the next cycle (or doesn’t)
3. Building — Small teams execute autonomously with full responsibility for the outcome

The key insight behind Shape Up is that most projects fail not because teams can’t build fast enough, but because the work wasn’t properly defined before building started. Scrum assumes you can figure things out as you go through refinement and iteration. Shape Up argues you should figure out more upfront—but not so much that you’re writing detailed specs.

The three phases explained

Shaping: the work before the work

Shaping happens before a project reaches the team. It’s done by senior product people (often a mix of product and engineering leadership) who have the context to make tradeoffs and the authority to define scope.

A shaped project has four properties:

• It’s rough. Not wireframes or detailed specs—more like fat-marker sketches that show the solution concept without dictating implementation details.
• It’s solved. The main elements of the solution are figured out. Open questions that could derail the project have been addressed.
• It’s bounded. The scope is clear—what’s included and (critically) what’s explicitly excluded.
• It’s estimated at the appetite level. Instead of asking “how long will this take?” you ask “how much time is this worth?” That becomes the time box.

Singer introduced a sketching technique called breadboarding for shaping. Named after the boards used to prototype electronics, breadboards show the components and connections of a solution without visual design. You sketch places (screens or locations), affordances (buttons, fields, actions), and connection lines showing how users flow through the experience.

For more visual features, Shape Up uses fat-marker sketches—drawings intentionally made with thick markers so you can’t add too much detail. The goal is communicating the concept, not the final design.

Betting: the hard prioritization

Once work is shaped, it goes to the betting table—a meeting where stakeholders decide what to build in the next cycle. This typically happens during the two-week cooldown between cycles.

The betting table is deliberately different from typical prioritization:

• No backlog. Shaped work that doesn’t get bet on is discarded. If it matters enough, someone will re-pitch it later with updated context.
• Full commitment. When you bet on something, you’re committing the full cycle to it—no pulling people off mid-cycle.
• Circuit breaker. If work isn’t done by the end of the cycle, it doesn’t automatically continue. You re-evaluate whether to bet on it again.

This creates healthy pressure on shaping. If your shaped pitch isn’t compelling enough to bet on, it goes away. There’s no “we’ll get to it eventually” backlog that becomes a guilt-inducing graveyard of abandoned ideas.

Building: autonomous execution

Once work is bet on, small teams (typically one designer and one or two developers) take full ownership. They get the shaped pitch, but they figure out the tasks, make design decisions, and solve problems as they arise.

Shape Up introduces the concept of hill charts to track progress. Unlike burndown charts that measure tasks completed, hill charts show whether work is “uphill” (still figuring things out) or “downhill” (executing on known work). A dot on the left side of the hill means there’s still uncertainty; a dot on the right means it’s just a matter of finishing the work.

This matters because traditional progress tracking is often misleading. A team can complete 80% of planned tasks and still be stuck on a fundamental problem. Hill charts surface that risk early.

How 6-week cycles actually work

Shape Up uses 6-week build cycles followed by a 2-week cooldown. Here’s why:

Six weeks is long enough to build something meaningful. Two-week sprints often force teams to slice work into pieces that don’t deliver standalone value. With six weeks, you can ship a complete feature that users actually notice.

Six weeks is short enough to see the end. Longer projects create planning anxiety and scope creep. When everyone knows there’s a hard deadline in six weeks, decisions get made faster.

The cooldown prevents burnout and handles maintenance. The two weeks between cycles is for bug fixes, tech debt, exploration, and recovery. It’s not a vacation—it’s unstructured time for work that doesn’t fit into cycles.

During the cycle, there are no standups, no sprint planning, no story points. Teams self-organize and communicate asynchronously. The constraint is the deadline, not the process.

Why there’s no backlog

The “no backlog” policy is the most controversial part of Shape Up, and it’s worth understanding why Basecamp made this choice.

Traditional backlogs create several problems:

• They grow forever. Items get added faster than they’re completed, creating a depressing inventory of broken promises.
• They require constant maintenance. Grooming sessions, priority changes, re-estimation—all overhead that doesn’t ship product.
• Old items become stale. That feature request from 18 months ago? The context has changed, the requester may have churned, and the market has moved on.
• They create false accountability. “It’s in the backlog” becomes an excuse that satisfies no one.

Shape Up’s alternative: if something is important enough to do, it’ll come back. Someone will re-pitch it. If it doesn’t come back, it wasn’t actually important. This feels brutal, but it matches reality—most backlog items never get built anyway.

For customer requests and bugs, Shape Up suggests keeping a simple list that people can reference when shaping. But it’s a resource for shaping, not a commitment queue.

Shape Up vs. Scrum vs. Kanban

Understanding how the Shape Up method differs from other approaches helps clarify when to use it:

Shape Up vs. Scrum:

• Scrum has 2-week sprints; Shape Up uses 6-week cycles
• Scrum estimates in points; Shape Up uses appetite (how much time something is worth)
• Scrum has defined roles (PO, SM, Team); Shape Up has shapers and builders
• Scrum has ceremonies (standup, planning, retro); Shape Up has almost none
• Scrum refines as you go; Shape Up shapes upfront

Shape Up vs. Kanban:

• Kanban is continuous flow; Shape Up has discrete cycles with hard stops
• Kanban uses WIP limits; Shape Up uses time boxes
• Kanban works from a backlog; Shape Up has no backlog
• Both minimize ceremony; Shape Up adds more structure around shaping

The fundamental difference is where uncertainty gets resolved. Scrum assumes you’ll learn through iteration and adjust. Kanban assumes you’ll optimize flow over time. Shape Up assumes you can resolve most uncertainty before building starts—if the right people do the shaping work.

When Shape Up works best

Shape Up isn’t universal. It works well for:

Product companies building for their own product. Basecamp built Shape Up for Basecamp. When you own the product and roadmap, you can make the tradeoffs that Shape Up requires. Agencies or teams with external stakeholders have less flexibility.

Teams with senior, autonomous builders. Shape Up gives teams significant autonomy. That only works if builders can make good decisions independently. Junior teams or teams used to detailed specs may struggle initially.

Products with complex features that don’t slice well. If your work naturally takes 4-8 weeks to be meaningful, Shape Up fits better than forcing everything into two-week increments.

Organizations drowning in process. If your team spends more time in ceremonies than building, Shape Up’s minimal process is refreshing.

Companies that can tolerate 6-week commitments. If your market requires faster pivots, or stakeholders need constant visibility, Shape Up’s longer cycles may not work.

The downsides and criticisms

Shape Up has real limitations:

Shaping is hard and requires senior talent. The framework’s success depends entirely on shaping quality. If you don’t have experienced people who can shape well, you’re just doing waterfall with less documentation. Singer acknowledges this—the book spends the most pages on shaping because it’s the hardest part.

The circuit breaker can waste work. If a project doesn’t finish in six weeks, you don’t automatically continue it. That’s the point—it prevents runaway projects. But it also means potentially throwing away five weeks of work. This requires cultural buy-in that not everyone has.

It’s not designed for operational work. Bug fixes, support escalations, and ongoing maintenance don’t fit neatly into 6-week cycles. Basecamp handles this during cooldown, but teams with heavy operational loads may need hybrid approaches.

Stakeholder management gets harder. “No backlog” means you can’t point to a roadmap showing when someone’s request will ship. Some organizations—especially those with enterprise sales or board reporting requirements—can’t operate this way.

Adoption is all-or-nothing for some parts. You can borrow concepts from Shape Up (like appetite-based scoping or hill charts), but the full system works as an integrated whole. Partial adoption may miss the point [INTERNAL_LINK: product development methodologies].

Getting started with Shape Up

If Shape Up sounds like it might work for your team, start here:

1. Read the book. It’s free, it’s short, and it’s well-written. Don’t try to implement from summaries.
2. Start with one team. Don’t roll out org-wide. Test with a single product team that has the autonomy to try something different.
3. Focus on shaping first. The biggest shift is learning to shape well. Practice writing pitches before you change cycles or eliminate your backlog.
4. Give it three cycles. Six weeks isn’t enough to judge. You need 3-4 cycles to experience the full rhythm and work out the kinks.

The Shape Up method won’t solve every product team’s problems. But if you’re exhausted by Scrum theater and want a framework that prioritizes shipping meaningful work over following a process, it’s worth serious consideration. The best way to know if it works for you is to try it—with the understanding that, like any methodology, the value comes from thoughtful adaptation, not religious adherence.

Frequently asked questions