← notes

Shape up

• source

When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth.

Setting the appetite and coming up with a solution requires you to be critical about the problem. What are we trying to solve? Why does it matter? What counts as success? Which customers are affected? What is the cost of doing this instead of something else?

Shaping

You should start with raw ideas and setting the appetite for them, so that you can narrow them down. A raw idea should not look like "Build a task tracker", but rather more like "Build a task tracker to visualize in-progress work"

Set boundaries

Fixed time, variable scope: Make yourself take decisions on what should be included or not given the imposed time constraint. If something does not fit it:

• Remove stuff
• Split. Good is relative: Be sure to have a well defined goal and what success looks like. Responding to raw ideas: Temper your expectations on ideas. Do not get excited or dismiss it, until you've set the appetite and scope Narrow down the problem: Be sure you are tackling the right problem before jumping into solutions. A raw idea might be much smaller after you've asked what problem are you actually trying to solve.

Find the elements

Move at the right speed: Find the right level of detail you are working at. Do not give specifics, rather work through user flow in plain text and/or very (very) rough sketches.

• Bread-boarding: In plain text, define the places (navigation pages or elements), affordances (buttons, fields, copy) and connection lines.
• Fat marker sketch: Rough draft that leaves lots of room for creative exploration further down the line.

Risks and Rabbit holes

• Trade-offs are harder to make when you are under pressure of the development cycle
• Try to identify early on, any potential rabbit holes the project might trigger, and define which are out of scope, or might become future shape-ups.

Write the pitch

1. Problem: The raw idea, a use case, or something we’ve seen that motivates us to work on this
   • Do not jump straight into "what to build". Clearly define what problem you are trying to solve.
2. Appetite: How much time we want to spend and how that constrains the solution
3. Solution: The core elements we came up with, presented in a form that’s easy for people to immediately understand
4. Rabbit holes: Details about the solution worth calling out to avoid problems
5. No-gos: Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable

Betting

Bets, no backlogs

Removing the idea of the backlogs helps to stop the feeling of always being behind. No backlogs does not mean we can't track things we want to bet on, but don't keep a centralized list. If it matters to you, you track it.

The betting table

TBR ¯\_(ツ)_/¯