Shape Up

Origin & evolution

Ryan Singer developed Shape Up over roughly a decade of building and shipping Basecamp's own product, refining a set of practices that departed substantially from Scrum and Kanban in both rhythm and philosophy. Basecamp published the method as a free online book in 2019 under the title Shape Up: Stop Running in Circles and Ship Work that Matters. Singer wrote it as a practitioner's account of how Basecamp actually worked, not as a theoretical framework, which gives the text a concrete texture absent from most methodology writing.

The method attracted wide attention because it named problems that Scrum practitioners recognised, in particular the treadmill of sprint planning, the accumulating weight of a backlog nobody trusts, and the mismatch between two-week cycles and work that genuinely takes six weeks to do well. Shape Up does not position itself as a universal replacement for agile methods: Singer is explicit that it describes what works for a small, senior, product-focused team and that teams in different contexts will need🫀NeedUserA user need, pain, desire, or constraintView reference → to adapt it. Since 2019 it has been adopted selectively, with some teams taking the full method and others borrowing specific concepts such as appetite, betting, and the cooldown.

How it works in practice

Shape Up has four phases that repeat on a fixed cadence:

Shaping happens before the cycle, outside the building team. A small group, typically including a senior designer or product strategist, defines the work at the right level of abstraction. A shaped pitch describes the problem, the appetite (a fixed time budget, not an estimate), the rough solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference →, and the known risks🎲RiskComplianceA risk to the product or businessView reference →. It is specific enough to build from and loose enough for the team to make their own decisions about implementation. Shaping is done at the problem level, not the task☑️TaskProduct SpecificationA unit of work within a story or epicView reference → level.

Betting is the decision point. Before each cycle, the people who set priorities review the available shaped pitches and bet on which ones will run. Items not selected do not go into a backlog: they are set aside and must be re-pitched if they remain relevant. This is a deliberate choice. Basecamp argues that a groomed backlog of deferred work creates an illusion of progress and a debt of obligation. The betting table is a meeting, not a process.

Building is the six-week cycle. A small team receives a pitch, forms its own tasks, and is trusted to deliver a complete, shippable outcome🏆OutcomeStrategyA desired business or user outcomeView reference → within the time boundary. There are no sprint reviews, no daily standups, and no updates to a project manager. The team's job is to scope down to what is actually buildable in six weeks and ship it. Shape Up introduces the concept of a hill chart, a visual tool for teams to report progress in terms of unknowns resolved and work descending toward completion, which is more informative than a percentage complete.

Cooldown is the two-week period after the cycle. Teams fix bugs🐛BugProduct SpecificationA defect or unexpected behaviourView reference →, explore ideas, and do whatever maintenance and learning🧠LearningValidationAn insight gained from an experimentView reference → work fell outside the cycle. It is not filler: it is the time for the system to breathe before the next cycle begins.

A concrete example. A small team at a SaaS company bets on a shaped pitch for a new CSV export feature⭐FeatureProduct SpecificationA product capability or featureView reference →. The pitch specifies the appetite as six weeks, the rough solution as a background-job exporter with email delivery, and two known risks: the job queue infrastructure needs a one-time upgrade, and large exports over one million rows need a separate handling path. The team takes the pitch, breaks it into their own sub-tasks on day one, resolves the queue upgrade question in week two, and ships a complete, documented feature at the end of week six. Nothing from the cooldown period accumulated on a backlog during the cycle.

When to use it (and when not)

Shape Up fits teams that own a complete product surface, have senior enough members to work without detailed task breakdowns, and have organisational support for fixed-time betting in place of a perpetual sprint pipeline. It works well when two-week sprints feel too short for the work and when backlog grooming has become a ritual that consumes planning energy without producing clarity.

It earns its keep less well in organisations where delivery is tightly coupled to external commitments, where contract terms or regulatory requirements demand predictable sprint-by-sprint reporting, or where teams are large enough that coordination across subgroups requires more explicit handoff structure than Shape Up provides. The method also demands genuine shaping work before each cycle: teams that try to run six-week cycles without investing in the shaping phase arrive at the betting table with half-formed ideas and end up doing the shaping inside the cycle, which is precisely what the method warns against. A common failure is treating the six-week cycle as a longer sprint and carrying the same sprint habits into it, which produces the same problems at greater cost.

In the Unified Product Graph

Shape Up is a flow framework in the planning category. Its four phases map onto distinct entity types in the Unified Product Graph:

• Shaping, the phase where a pitch is defined with appetite and rough solution, produces a feature⭐FeatureProduct SpecificationA product capability or featureView reference → entity: the concrete capability💪CapabilityStrategyAn ability that enables value deliveryView reference → or outcome the team is committing to deliver.
• The Betting Table, the decision meeting where pitches are selected or set aside, produces a decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → entity: the explicit, owned record of what was chosen and what was not.
• Building, the six-week cycle in which a small team executes a shaped pitch end to end, maps to an epic📜EpicProduct SpecificationA large body of work that can be broken into storiesView reference → entity: the body of coordinated work that delivers the feature.
• Cooldown, the two-week rest and repair period between cycles, maps to a task☑️TaskProduct SpecificationA unit of work within a story or epicView reference → entity: the discrete maintenance, learning, and exploratory work that takes place outside a formal cycle.

The Unified Product Graph models the Shape Up flow as a connected chain: a feature⭐FeatureProduct SpecificationA product capability or featureView reference → shaped and pitched is linked to the decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → that placed it in a cycle, which connects to the epic📜EpicProduct SpecificationA large body of work that can be broken into storiesView reference → that delivered it. The task☑️TaskProduct SpecificationA unit of work within a story or epicView reference → entities from cooldown can connect back to the features or epics📜EpicProduct SpecificationA large body of work that can be broken into storiesView reference → they maintain. That chain makes the method's accountability visible: every shipped feature traces to a bet.