Navigate Ways of Working
← Index

Guides

Cheatsheets

Cheatsheet

Project Sizing

How to break work down by size band, rules at each scale, what counts as tangible output, how to decompose large work into increments with off-ramps, and sizing anti-patterns.

Every sprint produces a tangible output that moves toward the goal and can be reviewed by someone outside the squad.

1–3 days
Tier 1: Feature
○ No special sizing rules
○ No milestones needed
○ No PRD
✓ Ticket with acceptance criteria

Go/No-Go PM decides

1 sprint
Tier 1 or small Tier 2
○ No special sizing rules
○ No milestones needed
✓ PRD if Tier 2
✓ Delivers output at sprint end

Go/No-Go PM (+ Head of Product if Tier 2)

2–4 sprints
Tier 2 or small Tier 3
● Sprint-level milestones
● Tangible output every sprint
● Phases defined in PRD
✓ PRD required

Go/No-Go PM + Head of Product. CTO if 4 sprints.

4+ sprints
Tier 3: Initiative
● Independently shippable increments
● Each increment 1–4 sprints
● Go/no-go at each increment
● Each can be paused or killed

Go/No-Go Head of Product + CTO + Exec. Board if capital.

What Counts as Tangible Output?

Every sprint must produce something concrete that can be reviewed. It doesn’t have to be a UI demo.

⚡
API endpointDemonstrated via Postman or tests
🔄
Data pipelineProcessing test data end-to-end
📐
Architecture + ADRFoundational decision documented
🔬
Spike reportTechnical approach proved/disproved
🗄️
Schema + migrationRunning against test data
☁️
InfrastructureProvisioned and documented
🖥️
UI flowWhen it naturally exists
📊
Integration test suiteProving system behaviour

Anti-pattern: the invisible sprint. “We wrote a lot of code but there’s nothing to show.” If the squad can’t point to a concrete output, the work wasn’t broken down well enough.

How to Decompose 4+ Sprint Work

1
Identify the core value
What’s the minimum that delivers the primary user value? This is increment 1.
↓
2
Define increments of 1–4 sprints
Each must be independently shippable. If it can’t function without the next increment, rethink the split.
↓
3
Set success criteria per increment
Specific, measurable. “Does this validate the hypothesis enough to continue?”
↓
4
Define sprint milestones within each increment
Tangible output every sprint. Phases go in the PRD.
↓
5
Go/no-go at each increment boundary
Review metrics, validate hypothesis, decide to proceed, adjust, or stop.

The point is off-ramps. If increment 1 ships and metrics don’t support the hypothesis, you can stop without wasting the full investment. This only works if increments are genuinely independent.

Sizing Anti-Patterns

✕Sprint with no reviewable output → Break down further
✕8-sprint monolith where everything depends on everything → Genuine increments with off-ramps
✕Artificial UI just to have a demo → Demonstrate real progress in any form
✕“Phase 1: backend, Phase 2: frontend” → Each increment delivers user value
✕Arbitrary split at 4-sprint mark → Split at natural value boundaries
✕Milestones defined after sprint starts → Milestones defined in PRD before build
✕Go/no-go is a rubber stamp → Real decision with metrics and evidence
✕Increment 2 already in progress before increment 1 reviewed → Sequential commitment

For the full sizing rules in context, see the Product Process guide (Project Sizing Rules section).