qa-aman Overview
Based on "Shape Up" by Ryan Singer and "The Art of Project Management" by Scott Berkun. The key insight both books share: time is fixed, scope is the variable. Most delivery failures come from treating scope as fixed and time as the flex - which produces the worst outcome (late delivery of bloated scope). A milestone scoped correctly defines what "done enough to ship" looks like within a fixed window, and explicitly names what is deferred.
Workflow
Step 1: Lock the time boundary
Before touching scope, get the time constraint on the table. Ask:
- What is the milestone date or sprint end date?
- Is this date moveable? (If yes, scope discussion changes. If no, proceed.)
- What is the sprint or cycle length?
Shape Up rule: appetite is decided before scope. If the team is willing to spend 6 weeks on this, that is different from 2 weeks - and the solution should change accordingly, not the timeline.
Step 2: Identify the core job to be done
Ask: "What is the one thing this milestone must accomplish for it to be worth shipping?"
This is not a feature list. It is a user or business outcome:
- "Users can complete checkout without calling support"
- "The migration is live with zero data loss"
- "Engineering team has a working CI pipeline"
If the user gives a list of features instead of an outcome, push back: "Which of these features, if not shipped, would make the milestone not worth shipping?"
Step 3: Sort everything into Must / Should / Cut
Take the full feature list or backlog for this milestone and classify each item:
| Category | Criteria | Action |
|---|---|---|
| Must | The milestone does not achieve its core job without this | In scope, non-negotiable |
| Should | Valuable, improves the outcome, but the milestone ships without it | In scope if capacity allows |
| Cut | Nice to have, or solvable with a workaround for now | Explicitly deferred to next cycle |
Berkun's forcing function test for each item: "If we cut this, does the milestone still meet its core job?" If yes, it is a Should or Cut - not a Must.
Step 4: Apply the fat marker sketch
For each Must item, describe it at the right altitude using Shape Up's fat marker principle:
- Write what the user can do, not how it is built
- Leave room for engineers to make implementation decisions
- Flag the rabbit holes: specific traps or complexity that would blow the scope
MUST: [feature/capability]
User can: [what they can do in 1 sentence]
Rabbit holes to avoid: [specific traps - e.g., "don't rebuild the notification system, use existing email infra"]
Complexity signal: [anything here that could expand scope unexpectedly]
Step 5: Generate the milestone scope document
MILESTONE SCOPE - [milestone name]
Cycle: [start date] to [end date]
Core job: [outcome this milestone achieves]
IN SCOPE (Must)
1. [Feature/capability] - [one-sentence user-facing description]
Rabbit holes: [traps to avoid]
2. [Feature/capability] - [description]
Rabbit holes: [traps to avoid]
IN SCOPE IF CAPACITY ALLOWS (Should)
- [Feature] - [description]
- [Feature] - [description]
OUT OF SCOPE (explicitly deferred)
- [Feature]: [why deferred, when it will be revisited]
- [Feature]: [rationale]
OPEN QUESTIONS (must resolve in first half of cycle)
- [Question] - Owner: [name] - Due: [date]
DONE CRITERIA
The milestone is complete when:
- [Specific, measurable condition 1]
- [Specific, measurable condition 2]
- [No Sev 1 defects / performance threshold / user acceptance criteria]
Step 6: Run the scope pressure test
Before locking the scope, ask these three questions:
"If the team discovers this takes 30% longer than expected, what gets cut first?" - The answer should be the Should list. If there is no answer, the scope is under-specified.
"Is there anything on the Must list that a team member might reasonably interpret as 10x bigger than we intend?" - If yes, add a rabbit hole note to that item.
"Is there a workaround that satisfies the core job without building this feature?" - If yes, move it to Should or Cut.
Anti-Patterns
1. Treating the feature list as the milestone Bad: "Milestone 2 = [list of 15 features]" Good: "Milestone 2 = users can complete onboarding without contacting support. These 4 features make that possible."
2. No explicit Cut list Bad: Scope document with only what is included. Good: Out of scope section is as important as in scope. It prevents scope creep during build and manages stakeholder expectations.
3. Must list too large Bad: 12 items in the Must category. Good: Must items should be completable in 70% of the cycle window, leaving buffer for Should and unexpected work. If Must is too large, the real Must list is not yet defined.
4. Rabbit holes not named Bad: "Build the reporting dashboard" with no caveats. Good: "Build the reporting dashboard. Rabbit hole: don't build custom chart library - use existing components. Don't add export to PDF in v1."
5. Done criteria are vague Bad: "Milestone is done when features are built." Good: "Done when: all P0 user stories are accepted, no Sev 1 defects, performance under 200ms on target hardware, stakeholder sign-off received."
Quality Checklist
- Time boundary is fixed and stated at the top
- Core job is one outcome statement, not a feature list
- Every item is classified as Must / Should / Cut
- Must items have fat marker descriptions with rabbit holes named
- Out of scope section is explicit with rationale for each deferred item
- Done criteria are measurable, not subjective
- Scope pressure test has been run (what gets cut if capacity is short?)