What is the Shape Up framework?

Shape Up is a product development framework created by Ryan Singer at Basecamp (formerly 37signals). It provides a structured approach to defining, building, and shipping software in 6-week cycles, followed by a 2-week cool-down period. Unlike traditional agile sprints, Shape Up emphasizes shaping work upfront, giving teams full autonomy during the build cycle, and enforcing hard deadlines to prevent scope creep.

Shape Up was designed to solve problems that Basecamp experienced with both traditional project management and Scrum: the overhead of two-week sprints felt too short for meaningful work, while longer projects tended to drift without clear boundaries. The framework was publicly documented by Ryan Singer in 2019 in the free online book "Shape Up: Stop Running in Circles and Ship Work that Matters."

Shaping

Shaping is the most distinctive aspect of the framework. Before any work is committed to a cycle, it must be "shaped" -- a process where senior product people define the problem, sketch a solution at the right level of abstraction, and set boundaries.

A shaped piece of work includes:

• Problem definition: a clear statement of what problem is being solved and why it matters.
• Appetite: how much time and effort the team is willing to invest (typically 2 or 6 weeks), rather than an estimate of how long the work will take.
• Solution sketch: a rough solution that is concrete enough to show the approach but abstract enough to leave room for the team to make detailed design and implementation decisions.
• Rabbit holes: identified risks and complexities that could derail the project, with explicit boundaries about what is out of scope.
• No-gos: things that the solution explicitly will NOT include, preventing scope creep.

Shaping happens before the betting table and is done by a small group (typically 1-2 people) who combine product thinking with technical understanding. The output is a pitch -- a document that presents the shaped work to stakeholders.

Appetite vs Estimation

One of Shape Up's most provocative ideas is replacing estimation with appetite. Instead of asking "How long will this take?", Shape Up asks "How much time are we willing to spend on this?"

This shift changes the dynamic fundamentally:

• Estimation starts with scope and produces a timeline: "This feature will take 8 weeks."
• Appetite starts with a time budget and constrains scope: "We're willing to spend 6 weeks on this. What version of this feature can we build in that time?"

With appetite, scope is the variable that flexes to fit the time constraint. This prevents projects from growing unbounded and forces creative trade-offs about what is essential versus what is nice-to-have.

The Betting Table

At the start of each 6-week cycle, a small group of senior stakeholders meets at the betting table to decide which shaped pitches to greenlight. This is not a backlog grooming session -- there is no backlog in Shape Up.

Key principles of the betting table:

• No backlog: pitches that are not selected are not carried forward automatically. If an idea is still important, someone will bring it back with a new or refined pitch.
• Deliberate bets: each pitch accepted is a bet -- the company is wagering that this work is worth 6 weeks of a team's time.
• Informed decisions: participants have read the pitches beforehand and understand the trade-offs.
• Small group: the betting table typically includes the CEO, CTO, and senior product people -- a small enough group to make decisions quickly.

6-Week Cycles

The 6-week cycle is the core building block. Teams are given shaped work at the beginning of the cycle and have 6 weeks to design, build, test, and ship it. Key rules:

• No extensions: if the work is not done after 6 weeks, it does not get an extension. The cycle ends, and the team moves on. This is the "circuit breaker" that prevents runaway projects.
• Team autonomy: teams have full authority to decide how to break down the work, what to build first, and how to make design decisions within the shaped boundaries.
• No daily standups: Shape Up does not prescribe regular check-in meetings. Teams communicate asynchronously and use the hill chart (see below) to show progress.
• Integrated teams: each team includes both designers and programmers who collaborate throughout the cycle.

Cool-Down Period

Between 6-week cycles, there is a 2-week cool-down period. During this time:

• Teams have no scheduled project work.
• Developers fix bugs, address technical debt, and explore new ideas.
• Senior product people shape pitches for the next cycle's betting table.
• Team members can work on side projects or learning.

The cool-down prevents burnout from back-to-back intense cycles and creates space for the unstructured work that keeps a codebase healthy.

Shape Up introduces the hill chart as an alternative to traditional progress tracking tools like burndown charts.

A hill chart represents work as a dot moving over a hill with two phases:

1. Uphill (figuring it out): the team is discovering unknowns, making design decisions, and solving problems. Progress feels uncertain.
2. Downhill (making it happen): the unknowns have been resolved, and the team is executing on a known plan. Progress is predictable.

The hill chart is more honest than a burndown chart because it acknowledges that the early phase of creative work involves figuring out the approach, not just executing tasks. A scope item that has not moved uphill yet represents a risk; one that is over the hill represents predictable execution.

Scopes

Instead of breaking work into user stories or tasks, Shape Up breaks work into scopes -- meaningful slices of the project that can be completed independently. Good scopes are:

• Integrated: each scope includes design, frontend, backend, and testing -- everything needed to complete that slice.
• Independent: scopes can be completed in any order without blocking each other.
• Meaningful: each scope represents a visible, testable piece of the project.

When Shape Up works better than Scrum

• Product companies building their own product (especially small to mid-sized teams).
• Teams frustrated by the overhead of sprint ceremonies.
• Organizations that want to give teams more autonomy and less micromanagement.
• Products where features can be meaningfully completed in 6 weeks.

When Scrum works better than Shape Up

• Client or agency work where external stakeholders need regular check-ins.
• Large organizations that need coordination across many teams.
• Teams new to agile that benefit from the structure and defined roles of Scrum.
• Environments where work items are typically small and can be delivered within a 2-week sprint.

Step 1: Form small teams

Shape Up works best with small, integrated teams of 2-3 people (typically 1 designer + 1-2 programmers). Larger teams dilute accountability and complicate communication.

Step 2: Learn to shape

Shaping is the hardest skill to develop. Start by reading Ryan Singer's book and practicing the process of defining problems, setting appetites, and creating solution sketches at the right level of abstraction.

Step 3: Run a pilot cycle

Start with a single 6-week cycle for one team. Choose a well-understood project with moderate complexity. Use this cycle to experience the framework firsthand and identify what works and what needs adaptation.

Step 4: Establish the betting table

Define who participates in the betting table and how pitches are submitted and evaluated. Keep the group small (3-5 people) with the authority to make binding decisions.

Step 5: Adopt the cool-down

The 2-week cool-down is essential -- do not skip it. Without it, teams burn out and the shaping process does not have time to produce quality pitches.

Step 6: Use the hill chart

Introduce the hill chart as the primary progress communication tool. Teams update their hill chart regularly (every few days), and stakeholders check it asynchronously instead of requiring status meetings.

• Micro-managing during cycles: the entire point of shaping upfront is to enable team autonomy during the build. If stakeholders intervene with new requirements or daily check-ins, the framework breaks down.
• Extending cycles: the circuit breaker (no extensions) is uncomfortable but essential. If failing projects always get extensions, there is no incentive to scope work appropriately.
• Under-shaping: throwing vague ideas at teams without adequate shaping leads to wasted cycles. A well-shaped pitch requires significant upfront thinking.
• Over-shaping: providing too much detail removes the team's autonomy and creativity. Shape at the right level of abstraction -- define the boundaries, not the implementation.
• Skipping cool-down: without cool-down, technical debt accumulates, shaping quality drops, and teams burn out.

Is Shape Up an agile framework?

Shape Up shares agile values (iterative delivery, team autonomy, customer focus) but does not follow traditional agile practices (sprints, backlogs, daily standups, retrospectives). It is better described as a post-agile or alternative product development methodology that addresses specific problems with agile as commonly practiced.

Can Shape Up work for large organizations?

Shape Up was designed for small to mid-sized product companies. Scaling it to large organizations requires adaptation. Some companies use Shape Up within individual product teams while maintaining a higher-level coordination layer. However, the framework explicitly avoids the scaling mechanisms (SAFe, LeSS) common in large-scale agile.

What happens to bugs in Shape Up?

Minor bugs are addressed during the 2-week cool-down period. Critical bugs that affect users are handled immediately regardless of the cycle. Basecamp does not maintain a bug backlog -- if a bug is not important enough to fix during cool-down, it is not important enough to track.

How does Shape Up handle urgent requests or emergencies?

Shape Up does not have a mechanism for interrupting a cycle with new work. Critical production issues are handled by on-call engineers outside the cycle structure. For business-critical requests that arise mid-cycle, the betting table may choose to address them in the next cycle with a short-form (2-week) pitch.

Can I use Shape Up with Kanban?

Some teams combine Shape Up's shaping and betting process with Kanban for execution within cycles. Instead of breaking work into scopes on a hill chart, they use a Kanban board with WIP limits. This hybrid can work but loses some of Shape Up's distinctive progress tracking benefits.

Does Shape Up work for remote teams?

Yes, and it may actually work better for remote teams than Scrum because it does not rely on synchronous ceremonies. The asynchronous nature of pitch writing, hill chart updates, and cool-down work aligns well with distributed teams across time zones.

For the complete framework, read the free online book: Shape Up by Ryan Singer.