<aside>

Key concepts

• Shaped versus unshaped work
• Setting appetites instead of estimates
• Designing at the right level of abstraction
• Concepting with breadboards and fat marker sketches
• Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time
• Choosing the right cycle length (six weeks)
• A cool-down period between cycles
• Breaking projects apart into scopes
• Downhill versus uphill work and communicating about unknowns
• Scope hammering to separate must-haves from nice-to-haves </aside>

Introduction

• First, we work in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The majority of our new features are built and released in one six-week cycle.
• Second, we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on.
• When shaping, we focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend?

Part One: Shaping

Principles of shaping

• Wireframes are too concrete
• Word are too abstract

Properties of shaped work

• It’s rough
• It’s solved
• It’s bounded

1. Set boundaries

1. Set the appetite: You can think of the appetite as a time budget for a standard team size. We usually set the appetite in two sizes: Small Batch: This is a project that a team of one designer and one or two programmers can build in one or two weeks. Big Batch: This project takes the same-size team a full six-weeks.
2. Fixed time, variable scope: An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design.
3. "Good" is relative. There's no absolute definition of "the best" solution. The best is relative to your constraints. Without a time limit, there's always a better version. The ultimate meal might be a ten course dinner. But when you're hungry and in a hurry, a hot dog is perfect.
4. Responding to raw ideas. Our default response to any idea that comes up should be: "Interesting. Maybe some day." In other words, a very soft "no" that leaves all our options open. We don't put it in a backlog.
5. Narrow down the problem. We flip from asking “What could we build?” to “What’s really going wrong?” When it comes to unclear ideas, the worst offenders are "redesigns" or "refactorings" that aren't driven by a single problem or use case.