Shape up method

Shape Up is a product development methodology developed at Basecamp (formerly 37signals) as an alternative to both Scrum and traditional project management. It organizes work into six-week cycles with a two-week cooldown, emphasizes upfront "shaping" of work before teams begin, and gives development teams full autonomy to figure out how to deliver within fixed timeframes. Unlike Scrum's continuous sprints and extensive ceremonies, Shape Up focuses on larger bets with more breathing room.

Why it matters

Many teams find that Scrum's two-week sprints create certain problems: constant planning overhead, pressure that doesn't allow for deep work, sprint-to-sprint grind without breaks, micro-management through story points and velocity tracking, and difficulty tackling larger problems in small increments.

Shape Up addresses these by working in longer cycles, reducing ceremonies, and trusting teams to manage themselves within fixed time boundaries.

Core concepts

Six-week cycles provide enough time to build something meaningful while maintaining urgency. At the end of six weeks, teams ship what they've built. If work isn't done, it doesn't automatically continue; it must be re-evaluated and re-pitched. This creates natural deadlines and forces scope management throughout the cycle rather than at the end.

Cooldown follows each six-week cycle with a two-week period. During cooldown, teams fix bugs and address technical debt, leadership shapes work for the next cycle, people can explore personal projects, and the organization catches its breath. This prevents the relentless pressure that causes burnout.

Shaping happens before work reaches a team, when senior people define the work. Shaping specifies the problem (what user need or business problem are we solving?), the appetite (how much time is this worth - one week or six weeks?), the solution sketch (rough direction but not detailed specification), boundaries (what's explicitly out of scope), and rabbit holes (potential complications to watch for). Shaping is deliberate strategic work done by senior product and technical people, happening during cooldown or in parallel with ongoing development.

Pitches are written proposals that make the case for doing shaped work. They include the problem and its importance, the appetite (time budget), the solution approach, and potential risks and how to mitigate them. Leadership reviews pitches during the betting table meeting and decides what to fund for the next cycle.

Betting table is where stakeholders meet at the end of cooldown to decide what to build next. They review pitches and make bets - which pitches to fund for the next cycle, who will work on each bet, and what gets deferred or rejected. This replaces the continuous backlog grooming of Scrum with discrete decision points.

Full autonomy means once a bet is made, the team has complete independence. No daily standups unless they want them, no story points or velocity tracking, no external check-ins on progress, and full responsibility for figuring out how to ship. Teams manage their own time and approach within the six-week constraint.

Scope hammering is built into the methodology. As teams work, they continuously evaluate what's essential versus what's nice-to-have. When time pressure mounts, they "hammer" scope - cutting less important work to ship the core value on time. Scope flexibility within fixed time is fundamental.

Shape up vs. scrum

The methodologies differ significantly. Cycle length in Shape Up is 6 weeks plus 2 cooldown, while Scrum typically uses 2-week sprints. Planning in Shape Up is done by seniors before the cycle, while Scrum involves the full team in sprint planning. Estimation in Shape Up uses appetite (time budget), while Scrum uses story points and velocity. Daily ceremonies are not required in Shape Up but are standard in Scrum. Team autonomy in Shape Up is complete within the cycle, while Scrum involves sprint backlog commitment. Scope in Shape Up is flexible within fixed time, while Scrum fixes scope within the sprint. Progress tracking in Shape Up uses optional hill charts, while Scrum uses burndown charts. Shape Up has no perpetual backlog, while Scrum maintains a product backlog.

Shape Up works well for teams that find Scrum ceremonies burdensome, organizations that trust their teams, products where six-week chunks make sense, companies with senior people able to do shaping work, and teams that struggle with the sprint-to-sprint grind.

Scrum might be better for teams needing more structure and guidance, highly uncertain work requiring faster feedback, organizations with external dependencies on sprint cadence, teams that benefit from velocity tracking, and situations requiring more predictable delivery dates.

Implementing shape up

Shaping practice takes skill. Shapers must understand the problem deeply, have enough technical knowledge to sketch solutions, know when to be specific and when to leave room, write clearly and persuasively, and identify risks before teams encounter them. Organizations adopting Shape Up often struggle here first.

Betting discipline requires decision-making rigor: actually saying no to good ideas, not overloading cycles, trusting shaped work without second-guessing, and accepting that some bets won't pay off.

Team readiness means teams need to function well with autonomy, including self-management skills, technical capability to make good decisions, comfort with ambiguity, and ability to ship complete work.

Leadership trust requires genuine delegation: no checking in mid-cycle, accepting team decisions about scope, trusting that nothing ships broken, and resisting the urge to micromanage.

Shape up and customer feedback

Shape Up emphasizes doing the right work, not just doing work right. Shaping should be informed by deep understanding of user needs, and the problem definition in pitches should connect to real customer problems.

Tools like Klero help shapers understand customer needs at the depth required for good shaping. When you can see exactly what customers are asking for, what's causing pain, and how requests cluster into themes, shaping becomes more grounded in genuine user needs rather than assumptions.