Shape Up

Image created with Bookframe.

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 com-
municating about unknowns
Scope hammering to separate must-haves from nice-to-haves

we work in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish
Our decisions are based on moving the product forward in the next six weeks, not micromanaging time

Appetite: Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth?
Estimates start with a design and end with a number. Appetites start with a number and end with a design

the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite
The shaped concept is an interaction design viewed from the user’s perspective
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.

Places: These are things you can navigate to, like screens, dialogs, or menus that pop up.
Affordances: These are things the user can act on, like buttons and fields. We consider interface copy to be an affordance, too. Reading it is an act that gives the user information for subsequent actions.
Connection lines: These show how the affordances take the user from place to place.

It may seem a little silly to call fat marker sketches a technique or a tool. The reason for calling them out is we too easily skip ahead to the wrong level of fidelity.

Really important ideas will come back to you.
Delete old pitches
two weeks is too short to get anything meaningful done. Worse than that, two-week cycles are extremely costly due to the planning overhead
after each six-week cycle, we schedule two weeks for cool-down.
Circuit breaker: Teams have to ship the work within the amount of time that we bet. If they don’t finish, by default the project doesn’t get an extension.
There is nothing special about bugs that makes them automatically more important than everything else.
The key to managing capacity is giving ourselves a clean slate with every cycle. That means only betting one cycle at a time
we don’t expect to ship anything at the end of an R&D cycle
- Consider not using the code after a 2-2-2 method poc
Shipping means merging into the main codebase and expecting not to touch it again (when building pre-release)
we always take care to separate problem and solution

The way to really figure out what needs to be done is to start doing real work
When doing the The 12 Week Year, act more like a shaper: rather than having a concrete plan, sketch it out
Start in the middle: build the key feature first and mock the rest
jumped straight into the middle where the interesting problem was and stubbed everything else to get there
at the start of a project, we don’t expect to see accurate scopes.
Nice-to-haves: code that could be cleaned up, edge cases to address, and improvements to existing functionality. Mark nice-to-haves with ~
Work is like a hill:
- It’s good to think of the first third uphill as “I’ve thought about this,” the second third as “I’ve validated my approach,” and the final third to the top as “I’m far enough with what I’ve built that I don’t believe there are other unknowns.”
Instead of comparing up against the ideal, compare down to baseline—the current reality for customers.
- It’s the difference between “never good enough” and “better than what they have now.”
For small teams:
- Set an appetite, shape what to do next, build it, then shape the next thing. Your bets might be different sizes each time: maybe two weeks here, three weeks there.