Shape Up Practitioner

FIXED TIME, VARIABLE SCOPE:
Traditional: Fix scope, time stretches (projects run over)
Shape Up: Fix time (6 weeks), scope adjusts to fit
This forces prioritization and prevents runaway projects.

SHAPING vs BUILDING:
Shaping: Senior people define the approach at the right abstraction
Building: A team executes within the shaped boundaries
Shaping happens BEFORE the cycle. Building happens DURING the cycle.

APPETITES, NOT ESTIMATES:
Instead of: "How long will this take?" (bottom-up estimate)
Ask: "How much time is this worth?" (top-down appetite)
Small Batch: 2 weeks of one designer + one developer
Big Batch: 6 weeks of one designer + one or two developers

THE BETTING TABLE:
No backlog. No prioritization of 200 items.
Each cycle: stakeholders look at shaped pitches and BET on which
to build. If a pitch is not bet on, it is not queued - it goes away.
If the idea is important, it will come back in a future pitch.

STEP 1: SET THE APPETITE
"How much time is this idea worth to us?"
- Small batch: 2 weeks (a tweak, improvement, small feature)
- Big batch: 6 weeks (a significant new feature or redesign)
- If the idea needs more than 6 weeks, narrow the scope or break it up
- If you cannot narrow it to 6 weeks, it is not shaped enough

STEP 2: DEFINE THE BOUNDARIES (what is IN and OUT)
Write a clear problem statement:
"When [situation], [user type] cannot [action], which causes [pain]."

Define scope explicitly:
- "This includes: X, Y, Z"
- "This does NOT include: A, B, C" (just as important)
- "Nice to have if time allows: M, N"

STEP 3: SKETCH THE SOLUTION (at the right level of abstraction)
- Use fat marker sketches (not detailed mockups)
- Breadboarding: text-based flow diagrams showing screens, actions, connections
- Just enough detail that a smart team can figure out the rest
- Too abstract = team will flail. Too detailed = team has no room.

BREADBOARD FORMAT:
Place: [Screen/Page Name]
  Affordance: [What user can do here]
  -> Connection: [Where it leads]

Example:
Place: Invoice List
  Affordance: Filter by status (draft, sent, paid, overdue)
  Affordance: Click invoice row
  -> Connection: Invoice Detail

Place: Invoice Detail
  Affordance: Edit line items
  Affordance: Send to client
  -> Connection: Confirmation with send date

STEP 4: DE-RISK
Identify rabbit holes - parts of the solution that could take
forever or have unknown complexity:
- "We need to check if the API supports this before committing"
- "The date picker interaction could be complex - limit to month view"
- Mark technical unknowns and resolve them DURING shaping, not building

PITCH TEMPLATE:

1. PROBLEM
   What is the current pain? Include a specific scenario.
   "When a customer needs to update their billing address, they
    have to contact support because there is no self-service option.
    This generates 200 support tickets per month."

2. APPETITE
   How much time is this worth?
   "6-week big batch" or "2-week small batch"

3. SOLUTION
   Fat marker sketches, breadboards, or annotated flows.
   Show the approach without over-specifying.

4. RABBIT HOLES
   What could go wrong? What have you already de-risked?
   "We confirmed the payment API supports address updates.
    We are NOT handling international address formats in this cycle."

5. NO-GOS
   What is explicitly out of scope?
   "No changes to the invoicing flow. No changes to the admin panel.
    This is customer-facing self-service only."

PITCH REVIEW CRITERIA:
- Is the problem clear and worth solving?
- Does the appetite match the value?
- Is the solution shaped enough but not over-designed?
- Are rabbit holes identified and addressed?
- Can a team ship this in the time allotted?

WHO ATTENDS: CEO/founder, head of product, CTO, senior designer
(small group with authority to commit resources)

WHEN: During the last week of the current cycle (cooldown week)

PROCESS:
1. Review shaped pitches (pre-read before the meeting)
2. Discuss each pitch: Is this the best use of next cycle?
3. Consider: team capacity, strategic priorities, customer urgency
4. BET: Assign teams to pitches for the next cycle
5. Anything not bet on is dropped (not added to a backlog)

KEY PRINCIPLES:
- Uninterrupted time: teams in a cycle are not pulled for other work
- Clean slate: each cycle starts fresh, no carryover
- No half-measures: if a pitch needs 6 weeks, give it 6 weeks
- Trust the team: once bet, the team has full autonomy to build

IF A PROJECT IS NOT FINISHED IN THE CYCLE:
- It does not automatically continue. The cycle is over.
- The team demos what they built. Stakeholders assess.
- If more work is needed, a NEW pitch is shaped for a future cycle.
- This prevents projects from dragging on indefinitely.

WEEK 1-2: FIGURING THINGS OUT
- Team explores the shaped solution
- Discovers the real technical challenges
- Maps out the work into scopes (not tasks)
- This is the most uncertain phase - that is expected

WEEK 3-4: MAKING IT REAL
- Building the core functionality
- Integrating the pieces
- Hill chart should show scopes moving uphill
- Problems discovered here should be solvable within appetite

WEEK 5-6: POLISHING AND SHIPPING
- Cutting scope if needed to hit the deadline
- QA, edge cases, polish
- Final decisions on nice-to-haves (cut if not done by mid-week 5)
- Ship at end of week 6

HILL CHARTS:
Each scope is plotted on a hill:
- Left side (uphill): figuring out the approach, uncertainty
- Top of hill: approach is clear, just need to execute
- Right side (downhill): executing known work

  /\
 /  \
/    \
Figuring   Execution
it out     (known work)

Track movement weekly. Scopes stuck on the uphill side are red flags.

AFTER EVERY 6-WEEK CYCLE: 2 weeks of cooldown

COOLDOWN IS NOT:
- Vacation (though some rest is fine)
- Planning time for the next cycle (betting table happens, but briefly)

COOLDOWN IS FOR:
- Bug fixes and maintenance
- Small improvements that do not need a full cycle
- Exploration and prototyping for future pitches
- Addressing technical debt
- Learning and skill development
- Shaping work for future cycles

THIS IS CRITICAL:
Without cooldown, teams burn out and debt accumulates.
The 6-week cycle works BECAUSE of the 2-week cooldown.

CHALLENGE                            | SOLUTION
-------------------------------------+------------------------------------
Team wants detailed specs            | Trust the shaping level. Let teams
                                     | fill in details during build.
Stakeholders want status updates     | Hill charts provide async visibility.
                                     | No standups or status meetings.
Project might not fit in 6 weeks     | Narrow the scope. Cut nice-to-haves.
                                     | If still too big, break into phases.
Team is stuck uphill on a scope      | Pair with a senior to unblock.
                                     | Or cut that scope entirely.
Bugs pile up without dedicated time  | That is what cooldown is for.
Hard to stop using the backlog       | Try it for 2 cycles. See how it feels.