What is Shape Up?
Shape Up was created by Basecamp to help midsized companies build products better, and faster. You can find the book here.
At its heart, Shape Up embraces three core principles that make it unique:
Fixed timeboxes — Work happens in six-week cycles with a two-week cooldown period between each cycle. This creates a natural rhythm that prevents project scope from expanding indefinitely.
Appetite, not estimates — Instead of asking "how long will this take?", Shape Up asks "how much time is this problem worth?" This flips the traditional approach on its head, focusing on business value rather than engineering estimates.
Shaping before building — Projects are carefully shaped before they're committed to a cycle. This means defining the solution at the right level of abstraction—concrete enough to guide the team but abstract enough to leave room for creativity.
The Shape Up process flows through distinct phases:
Shaping — A small group works to define the problem, set boundaries, identify risks, and sketch a solution that's detailed enough to be feasible but loose enough to allow for interpretation.
Betting — Leadership reviews shaped work and decides which projects to commit to for the upcoming cycle, without maintaining a traditional backlog.
Building — Small, autonomous teams (typically 1-2 programmers and 1 designer) work through the full stack to build vertical slices of functionality, with no daily check-ins or micromanagement.
Cooldown — Teams use the two-week period between cycles to fix bugs, explore new ideas, or tackle small improvements that don't warrant a full cycle.
What makes Shape Up different is its focus on autonomy and accountability. Teams aren't micromanaged with daily standups or story point debates. Instead, they're given clear problems to solve within fixed timeframes and the freedom to figure out how to get there.
This approach might be right for your team if you're struggling with:
Projects that keep growing without clear endpoints
Overwhelming backlogs that create more stress than value
Micromanagement that stifles creativity and ownership
Difficulty shipping meaningful work in predictable timeframes
Shape Up Articles
If you're already somewhat familiar with Shape Up, or you're looking for something more specific, check out some of our more in depth articles. Otherwise, our overview of Shape Up continues below.
Fixed Timeboxes & Cycles
The rhythm of Shape Up is built around fixed timeboxes that create a predictable cadence for product development. Here's how it works:
Six-Week Cycles
In Shape Up, work happens in six-week cycles. Why six weeks? It's long enough to build something meaningful but short enough to see the end from the beginning. This timeframe strikes the perfect balance:
Long enough to tackle substantial problems and deliver complete features
Short enough to maintain urgency and focus throughout the cycle
Creates a natural deadline that forces tough decisions about scope
The fixed timebox means there are no extensions. When the six weeks are up, the team ships what they've built—no exceptions. This constraint drives better decision-making throughout the cycle.
Two-Week Cooldown
After each six-week cycle, teams enter a two-week cooldown period. This isn't downtime—it's a purposeful break from scheduled feature work where teams can:
Fix bugs that emerged during the cycle
Explore technical improvements or refactoring
Investigate new ideas that might become shaped work
Catch their breath before the next intense cycle begins
Benefits of Fixed Timeboxes
This predictable rhythm creates several advantages:
Prevents project scope from expanding indefinitely (no "one more sprint" syndrome)
Creates natural deadlines that drive prioritization and decision-making
Allows teams to completely focus on building without interruptions
Provides regular opportunities to course-correct at the organizational level
The cycle-based approach stands in stark contrast to continuous sprint methodologies where work flows endlessly from one sprint to the next, often without meaningful breaks or opportunities to reset.
Appetite-Driven Development
One of Shape Up's most revolutionary concepts is the focus on appetite rather than estimates. This fundamentally changes how teams approach product development.
What is Appetite?
Appetite is the amount of time you're willing to spend on a problem—how much the solution is worth to you. Instead of asking "how long will this take?" (an estimate), Shape Up asks "how much time is this problem worth?" (an appetite).
Appetites typically come in two sizes:
Small Batch — Worth about two weeks of work for a small team
Big Batch — Worth about six weeks of work for a small team
Flipping the Traditional Approach
In traditional development:
Teams define the solution in detail
Engineers estimate how long it will take
Leadership decides whether to approve based on the estimate
With appetite-driven development:
Leadership decides how much time a problem is worth
Solutions are shaped to fit within that constraint
Teams figure out what they can deliver within the fixed timebox
Benefits of Appetite-Driven Development
This approach creates several advantages:
Forces prioritization based on business value rather than technical complexity
Prevents solution bloat by constraining how much time can be spent
Eliminates the "estimation game" where teams pad estimates and managers negotiate them down
Creates a fixed boundary that drives creative problem-solving within constraints
By starting with appetite, teams are forced to think differently about scope. The question becomes "what's the best solution we can deliver within this timeframe?" rather than "how long will it take to build everything we want?"
"Instead of treating the scope as fixed and the time as variable, fix the time and treat the scope as variable." — Ryan Singer, Head of Strategy at Basecamp
This mindset shift is central to Shape Up's ability to deliver meaningful work in predictable timeframes without the stress of constantly shifting deadlines or expanding scope.
The Shaping Process
Shaping is the critical up-front work that happens before a project is committed to a cycle. It's a thoughtful process that defines problems and outlines solutions at the right level of abstraction.
What is Shaping?
Shaping is the process of taking raw ideas and transforming them into potential projects that are:
Rough enough — Leaving room for the team to fill in the details and make implementation decisions
Solved enough — Key elements of the solution are figured out to reduce risk
Bounded — Clear about what's in and out of scope
Shaping is typically done by a small group working separately from the building teams. They might include product managers, designers, tech leads, or senior engineers who understand both the business needs and technical constraints.
The Four Steps of Shaping
The shaping process follows four main steps:
Set Boundaries — Define the appetite (how much time the solution is worth) and the problem to be solved
Rough Out the Solution — Sketch the core elements without getting lost in details; focus on the key workflows and interactions
Address Risks and Rabbit Holes — Identify potential problems or complexities and either solve them or explicitly exclude them from scope
Write the Pitch — Document the shaped work in a format that can be presented at the betting table
Finding the Right Level of Abstraction
The key to effective shaping is working at the right level of abstraction:
Too abstract — "We need a better onboarding experience" (leaves too many open questions)
Too concrete — Detailed mockups and specifications (removes team autonomy and creativity)
Just right — "A three-step wizard that captures user role, team size, and integration needs" (defines the structure while leaving implementation details to the team)
Benefits of Proper Shaping
When done well, shaping:
Reduces risk by solving key problems before committing to the work
Sets clear expectations about what will (and won't) be delivered
Gives teams the right balance of guidance and creative freedom
Prevents mid-project scope creep and "discovery" of major problems
The shaping process is deliberately separate from building. Shapers don't make promises on behalf of the builders, and shaped work isn't committed until it's bet on at the betting table.
"Shaping is a closed-door, creative process. We're making something out of nothing." — Ryan Singer
The Betting Table
The betting table is where decisions are made about which shaped projects to commit to for the upcoming cycle. It's a critical part of Shape Up that replaces traditional backlog grooming and sprint planning.
What is the Betting Table?
The betting table is a meeting where key stakeholders decide which projects to schedule for the next cycle. It's called "betting" because:
There's an element of risk and uncertainty in any project
You're making a time-bound commitment of resources
You're choosing to place your bets on certain projects over others
Typically, the betting table includes:
Product leadership
Tech leadership
Design leadership
Other key decision-makers with the authority to commit resources
How Betting Works
The betting process follows these steps:
Review Pitches — Examine the shaped work that's been prepared
Consider Capacity — Look at team availability for the upcoming cycle
Place Bets — Decide which projects to commit to
Assign Teams — Determine who will work on each bet
Unlike traditional product development, there's no backlog in Shape Up. Projects that aren't bet on aren't tracked in a list of future work. They simply remain unscheduled, and may be reconsidered in future betting meetings if they're still relevant.
The Pitch
Projects are presented at the betting table in the form of a pitch. A good pitch includes:
Problem — What customer need or business opportunity are we addressing?
Appetite — How much time do we want to spend on this? (Small or big batch)
Solution — What's the core of our approach?
Rabbit Holes — What specific complexities or problems have we thought through?
No-Gos — What are we explicitly not doing in this solution?
Benefits of the Betting Approach
This approach creates several advantages:
Forces tough prioritization decisions to happen explicitly
Creates clean slates between cycles rather than endless continuity
Prevents the accumulation of stale "someday" work in backlogs
Makes commitments concrete and time-bound
"We don't have backlogs. No project is ever scheduled by default. We don't roll the work from one cycle to the next if we don't finish in time." — Shape Up methodology
The betting table creates a rhythmic, intentional approach to product development where work is consciously chosen rather than automatically flowing from a backlog.
Autonomous Teams & Building
Once a project is bet on, it enters the building phase where a small, autonomous team takes full ownership of delivering the solution within the fixed timebox.
Team Structure
Shape Up teams are intentionally small and cross-functional:
1-2 programmers
1 designer
No dedicated project manager or product owner
These small teams have complete autonomy to figure out how to implement the shaped solution within the six-week timeframe. There are no daily standups, no story points, and no micromanagement.
The Building Process
The building phase follows a distinct approach:
Get One Piece Working — Start by building one vertical slice of the solution from UI to database
Map the Territory — Break down the work into tasks as you go, not all upfront
Show Progress — Track work as "To Do," "In Progress," or "Done" with no intermediate steps
Integrate Design and Programming — Designers and programmers work together throughout the cycle
Scope Hammering
As the cycle progresses, teams practice "scope hammering" — the continuous process of making scope adjustments to ensure the project fits within the fixed timebox. This includes:
Identifying core vs. nice-to-have elements
Finding simpler solutions to complex problems
Making cuts when necessary to hit the deadline
Maintaining quality while adjusting scope
Benefits of Autonomous Teams
This approach creates several advantages:
Increases ownership and accountability
Eliminates handoffs and communication overhead
Fosters creativity in problem-solving
Reduces the need for detailed specifications
Creates space for deep, focused work
"When you give a team a project, you're giving them a problem to solve, not a solution to implement." — Shape Up methodology
The autonomous team approach stands in stark contrast to traditional development where tasks are assigned to individuals, work is tracked at a granular level, and teams report progress in daily meetings.
Is Shape Up Right for Your Team?
Shape Up offers a compelling alternative to traditional agile methodologies, but it's not for everyone. Here's how to determine if it might be the right fit for your team.
Signs Shape Up Might Be Right for You
Consider adopting Shape Up if your team experiences:
Projects that consistently run over their estimated time
Backlogs so large they've become unmanageable and demotivating
Endless meetings that interrupt actual productive work
Teams that lack autonomy and constantly need approval
Difficulty shipping meaningful work in predictable timeframes
Burnout from the constant pressure of never-ending sprints
Challenges to Consider
Shape Up might not be the best fit if:
Your organization requires detailed long-term roadmaps
You have contractual obligations with fixed scope and deadlines
Teams aren't trusted to work autonomously
Your projects typically require large teams working in coordination
Stakeholders need very detailed specifications before development begins
Getting Started with Shape Up
If you're interested in trying Shape Up, consider these steps:
Start Small — Try the approach with one team on one project before rolling it out more broadly
Adapt to Your Context — You don't have to adopt every element of Shape Up; take what works for your situation
Build Shaping Skills — Effective shaping is crucial; invest time in learning how to define projects at the right level of abstraction
Create Space for Focus — Shield teams from interruptions during cycles to maximize the benefit of uninterrupted work time
Embrace the Mindset — Shape Up is as much about changing how you think about product development as it is about specific practices
Common Adaptations
Many teams successfully adapt Shape Up to their needs:
Adjusting cycle length (four weeks instead of six, for example)
Adding lightweight check-ins while preserving team autonomy
Maintaining a lightweight backlog for small items while using Shape Up for larger projects
Incorporating user research into the shaping process
"Shape Up isn't a rigid framework. It's a set of principles and techniques that you can adapt to your environment."
Whether you adopt Shape Up fully or incorporate elements of it into your existing process, the focus on appetite-driven development, thoughtful shaping, and autonomous teams can help your organization deliver more meaningful work with less stress.
Shape Up Articles
Here's the rest of our articles on Shape Up
