
Shape Up is a product development method that fixes time and varies scope. Teams shape a problem before committing to it, choose which pitches deserve a bet, and give builders an uninterrupted cycle to ship meaningful work.
At Process Street, moving to Shape Up helped reduce a development cycle from roughly six months to six weeks, a 75% reduction. For teams ready to ditch Scrum, Shape Up offers a different way to shorten a dev cycle. The three checklists in this guide turn the method into practical workflows for shaping, betting, and building.
Use this guide to understand the Shape Up methodology, then open the embedded checklists when you are ready to put each phase into practice.
- Shape Up process: Key concepts
- Shape Up processes to help you get started
- Shape Up process: Shaping
- Shape Up process: Betting
- Shape Up process: Building
- Shape Up process: Summing up
Shape Up process: Key concepts

Shape Up was developed at Basecamp and documented by Ryan Singer in Shape Up: Stop Running in Circles and Ship Work That Matters. It is designed for product teams that struggle to move important work from idea to shipped outcome. The method replaces an open-ended backlog and rolling estimates with shaped pitches, explicit appetites, six-week cycles, and a circuit breaker.
The book is a clearly written and illustrated, freely contributed, and easily accessible e-book. Its language and techniques help teams define focused projects, address unknowns, and create more time to think about strategy. A Scrum Shape Up transition also changes collaboration: leaders decide what to bet on, while builders decide how to deliver the chosen outcome.
The central tradeoff is simple: time is fixed, while scope is flexible. A team does not promise every imagined requirement. It commits to solving the core problem within an agreed appetite. Builders can adjust details, split scopes, and cut lower-value work while protecting the outcome that made the bet worthwhile.
This differs from a sprint that begins with a long list of estimated tasks. Shape Up treats the pitch as a strategic boundary, not a complete implementation plan. The people who build the solution decide how to turn that boundary into working software. Managers protect the time, clarify the outcome, and help remove organizational obstacles without directing every discovered task.
Shape Up gives teams techniques to define focused projects, address unknowns, and increase collaboration before and during a build cycle.
Ryan Singer
For the story behind Process Street’s own adoption, read how we cut a development cycle from six months to six weeks. You can also see how a product designer works within Shape Up.
Glossary
These terms form the working language of the framework. The complete Shape Up glossary includes additional detail.
- Appetite: The amount of time we want to spend on a project, as opposed to an estimate.
- Baseline: What customers are doing without the thing we are currently building.
- Bet: The decision to commit a team to a project for one cycle with no interruptions and an expectation to finish.
- Circuit breaker: A risk management technique that cancels projects that do not ship in one cycle by default instead of extending them by default.
- Cool-down: A two-week break between cycles to do ad-hoc tasks, fix bugs, explore ideas, and hold a betting table.
- De-risk: Improve the odds of shipping within one cycle by shaping and removing rabbit holes.
- Discovered tasks: Tasks the team discovers they need to do after they start getting involved in the real work.
- Hill chart: A diagram showing the status of work on a spectrum from unknown to known to done.
- Pitch: A document that presents a shaped project idea for consideration at the betting table.
- Raw idea: A request or feature idea expressed in words that has not been shaped.
- Scope: A part of a project that can be built, integrated, and finished independently of the rest of the project.
Shape Up processes to help you get started

A standard Shape Up cycle gives a team six uninterrupted weeks to build a selected pitch, followed by a two-week cool-down. Small-batch work can use a one- or two-week appetite inside that operating rhythm. The important point is not to keep changing the deadline. The team shapes and trims the solution so the valuable core fits the time available.
The method has three practical activities: shaping work before commitment, betting on the few pitches that matter now, and building with enough autonomy to resolve discovered tasks. Each activity needs clear inputs, decisions, and evidence. A checklist helps the team repeat that discipline without turning Shape Up into a ceremony-heavy process.
Adoption does not require changing every product practice at once. Begin with a problem that matters, can be bounded, and has decision makers willing to protect the team for a complete cycle. Record what was difficult to shape, which unknowns appeared during the build, and what scope had to move. Those observations improve the next pitch and make the operating rhythm more credible.
Process Street brings those checklists into a single Compliance Operations Platform. Docs and Ops capability areas plus built-in AI let teams document the method, run recurring work, assign ownership, collect approvals and evidence, and improve the process over time. If you are new to the platform, the getting started guide covers the basics.
You can also connect these checklists with a broader agile workflow software strategy. Shape Up can stand on its own, but its ideas about bounded work, visible decisions, and protected focus are useful wherever product teams need a more reliable delivery system.
Shape Up process: Shaping

Shaping happens before a build team receives a project. A small group looks at current product priorities, finds a problem worth solving, chooses an appetite, and works the idea into a pitch with enough definition to be bet on. The question changes from “How long will this specification take?” to “How much time are we willing to spend, and what solution fits that boundary?”
The four stages of shaping
- Set boundaries: Define the problem, the appetite, and what the team will not solve in this bet.
- Rough out the elements: Sketch the solution at the right level of abstraction with breadboards, fat-marker sketches, or comparable rough models.
- Address risks: Find rabbit holes, dependencies, unclear interactions, and technical unknowns before commitment.
- Write the pitch: Present the problem, appetite, proposed solution, risks, and no-gos so decision makers can evaluate the bet.
An appetite is not an estimate. An estimate asks how long a predetermined solution might take. An appetite sets the maximum investment and forces the solution to earn its place inside that boundary. Shape Up commonly distinguishes small batches of one or two weeks from big batches of six weeks. A project should not quietly grow beyond the cycle.
Risk work is where shaping becomes more than planning. Bring in people who understand design, engineering, service delivery, security, or another affected area. Show them the rough solution and ask: “What are we missing?” and “What could turn this six-week build into an eighteen-week build?” The answers reveal rabbit holes and potential scope creep while there is still time to change the approach.
A strong pitch leaves room for builders to make implementation decisions. It explains the value and boundaries without becoming a task list. When the largest risks are handled and the pitch is clear enough to compare with other opportunities, it is ready for the betting table.
Once the boundaries have been set, the elements roughed out, and risks addressed, it is time to write the pitch. This sequence distinguishes shaping from estimation in Scrum and other agile frameworks. Addressing risks before commitment does not remove discovery, but it prevents obvious unknowns from consuming the build cycle.
The shaper should also describe the baseline. Showing what customers do today keeps the proposed solution grounded in observable behavior. It prevents the pitch from becoming a collection of attractive screens with no clear problem. When a pitch includes a baseline, appetite, rough solution, risks, and no-gos, the betting table can judge the opportunity without asking a build team to repeat the discovery work.
Shaping checklist
This checklist helps a shaping group distinguish shaped from unshaped work, set an appetite, model a solution at the right level of abstraction, address risks, and prepare a pitch.
Open the Shape Up Process: Shaping checklist.
Shape Up process: Betting

Betting is the leadership decision that assigns a shaped pitch to a team for the next cycle. During cool-down, decision makers consider new pitches and any older pitch someone has deliberately chosen to revive. They weigh the value of the problem, the quality of the shaped solution, the appetite, the available people, and the opportunity cost of choosing one bet over another.
What happens at the betting table?
The betting table is not a popularity vote and it is not a ranking exercise where a senior person’s preference automatically carries extra points. The people responsible for product direction make explicit commitments. A selected pitch receives a team and protected time. An unselected pitch does not become an obligation that silently follows everyone into the next meeting.
That clean slate is one of Shape Up’s sharpest departures from backlog-driven planning. Ideas can be recorded and reconsidered, but the method avoids treating every unbuilt request as debt. If an older pitch still matters, someone brings it back with current conviction. Otherwise, the next betting table focuses on the best shaped opportunities available now.
Once a bet is made, the team needs a stable problem and appetite. Interruptions undermine the model because the cycle assumes focused ownership. New information can change how builders solve the problem or which scope they cut, but it should not turn the pitch into an endless stream of new requirements.
Betting checklist
This checklist guides the second phase: preparing the betting table, evaluating shaped pitches, making a commitment, assigning a team, and protecting the chosen bet.
Open the Shape Up Process: Betting checklist.
Shape Up process: Building

Building begins when a team receives a bet. The pitch gives builders a problem, an appetite, boundaries, and known risks, but it does not prescribe every task. The team discovers the real work as it goes. That autonomy is paired with a hard responsibility: finish a meaningful solution within the cycle.
Build one vertical slice
Start by getting one small piece completely working. Building in a vertical slice means focusing on getting one scope done as quickly as possible to gain momentum in a project. Both front-end and back-end elements must work together. Completing a slice reveals more than spreading effort across disconnected layers. It exposes practical constraints, gives the team something real to evaluate, and makes later scope choices easier.
As the project becomes clearer, group related work into scopes. A useful scope describes a coherent part of the customer experience, not a department or technical layer. Scopes should be small enough to finish and meaningful enough that their status tells the team something about the project.
Use a hill chart to show uncertainty
A hill chart is a diagram showing the status of work on a spectrum from unknown to known to done. On the uphill side of the diagram, there are still unknowns or unsolved problems. Progress may feel slow because important questions remain unanswered. At the top, the team understands the approach. On the downhill side of the diagram, all unknowns are solved and the remaining work is execution.
That distinction produces a better conversation than a percentage-complete status. A scope can have many tasks checked off while a critical unknown still threatens the project. The hill chart makes that uncertainty visible. A manager can ask what is keeping a scope uphill, while builders can explain the specific problem without pretending that task counts equal progress.
If the work threatens the appetite, builders use scope hammering to separate must-haves from nice-to-haves. They protect the core outcome, simplify edge cases, and remove details that do not justify delaying the bet. The circuit breaker remains real: projects do not automatically receive another cycle simply because time ran out.
Teams should update the hill chart from their own understanding, not from a manager’s interpretation of activity. A scope moves uphill when its unknowns become clearer and downhill when the solution is understood and execution is advancing. If a scope stays uphill, the useful response is to discuss the unresolved question, bring in the right expertise, or reduce the problem. More status reporting does not solve uncertainty.
Building checklist
This checklist covers the final phase, from forming scopes and completing a first slice to updating the hill chart, managing discovered work, hammering scope, and shipping the bet.
Open the Shape Up Process: Building checklist.
Shape Up process: Summing up

Shape Up works because its practices reinforce one another. Shaping reduces avoidable risk before commitment. Betting limits work in progress and assigns real capacity. Building gives a focused team the room to discover the best implementation while the appetite and circuit breaker keep the investment bounded.
The framework is not a promise that every bet will succeed. Its control mechanism is a capped downside. A team can learn from a pitch that does not ship, but the organization does not automatically compound the cost by granting unlimited extensions. Leaders can reshape the idea, make a new bet with better information, or decide that another opportunity deserves the next cycle.
With thought, experimentation, and adaptation, the method can reduce unnecessary meetings and help a product team ship quickly and more often. The goal is not to copy every Basecamp practice. It is to preserve the connected logic of shaped work, deliberate bets, uninterrupted time, flexible scope, visible unknowns, and a real circuit breaker.
Shape Up principles to carry into every cycle
- Shape before commitment: Define the problem, appetite, boundaries, solution outline, risks, and no-gos before assigning a build team.
- Use appetites instead of estimates: Fix the time and design a solution that fits.
- Keep pitches rough but meaningful: Remove major unknowns without turning the pitch into a rigid specification.
- Make explicit bets: Select a small number of pitches and give them real teams with uninterrupted time.
- Start each betting table with a clean slate: Do not let an unbounded backlog dictate the next cycle.
- Build in vertical slices: Finish one coherent piece early so the team learns from integrated work.
- Organize work into scopes: Track meaningful parts of the customer experience rather than disconnected task lists.
- Separate unknowns from execution: Use hill charts to expose where the team is still solving the problem.
- Hammer scope: Protect the core value and cut lower-priority detail when the appetite is at risk.
- Honor the circuit breaker: Reassess unfinished work instead of extending it by default.
The three embedded Process Street checklists give your team a repeatable path through shaping, betting, and building. Start with one real problem, choose an honest appetite, and let the process reveal where better boundaries or clearer decisions will improve the next cycle.
The post Ditch Scrum! 3 Shape Up Processes & Checklists to 5x Your Dev Cycle first appeared on Process Street | Compliance Operations Platform.
0 Commentaires