Plan a sprint that ships — capacity, commitment vs stretch, dependencies, risk-identification, and the pre-sprint discipline that prevents mid-sprint surprises. Distinct from scrum-master (process facilitation) by focusing on the planning artifact itself.
Design a product metrics dashboard — North Star + input metrics + guardrails — that the team actually uses to make decisions. Distinct from north-star-metric (defines THE one number) by focusing on the full dashboard architecture: layers, owners, cadence, visualization, and the discipline that prevents 30-chart dashboards.
Opportunity Solution Tree (Teresa Torres) — a continuous discovery artifact mapping desired outcomes → opportunities → solutions → assumption tests. Use when prioritizing discovery work, structuring weekly customer interviews, mapping multiple solutions to one problem, or auditing whether your roadmap actually moves outcomes.
Map stakeholders by power × interest (or influence × support), design a communication plan, and run the stakeholder-management discipline that prevents surprise objections. Use when launching a major initiative, navigating an enterprise deal, planning a re-org, or pre-empting political resistance to a roadmap change.
Generate complete test scenario coverage from a feature spec: happy paths, edge cases, error handling, accessibility, security, and performance scenarios. Includes a coverage analyzer that flags gaps before QA writes the test plan. Distinct from automated test generation — this is the WHAT to test before HOW.
Go-to-market strategy: ICP × motion × channels × messaging × success metrics × launch plan. Distinct from individual marketing or sales skills by being the integrated cross-functional strategy spanning product, marketing, sales, CS, and finance. Use when launching a new product, entering a new segment, or auditing why an existing GTM isn't working.
Define a sharp Ideal Customer Profile (ICP) — firmographics + behavioral signals + JTBD + trigger event + buyer persona — that marketing, sales, and product can all use. Use when defining a new ICP, refining an existing one based on actual closed customers, or auditing why pipeline / conversion is poor.
| name | sprint-plan |
| description | Plan a sprint that ships — capacity, commitment vs stretch, dependencies, risk-identification, and the pre-sprint discipline that prevents mid-sprint surprises. Distinct from scrum-master (process facilitation) by focusing on the planning artifact itself. |
| license | MIT + Commons Clause |
| metadata | {"version":"1.0.0","author":"borghei","category":"project-management","domain":"execution","updated":"2026-05-27T00:00:00.000Z","python-tools":"sprint_planner.py","tech-stack":"sprint-planning, capacity, agile, story-points"} |
A sprint plan that survives contact with reality. Covers capacity math, commit vs stretch separation, dependency identification, and the pre-sprint review that prevents mid-sprint surprises.
A good goal:
Per team member:
Aggregate across team. This is your real capacity.
Backlog items must be:
Items that fail this are NOT eligible for the sprint. Send back to refinement.
Stuffing 100% of capacity = guaranteed miss. Reality always intrudes.
For each item:
Each dependency needs:
For each item, list likely risks:
Per risk: likelihood, severity, mitigation, owner.
Per item:
sprint_planner.pyAudit capacity utilization, commit/stretch split, dependency clarity, DoD coverage.
python3 project-management/execution/sprint-plan/scripts/sprint_planner.py \
--input sprint_plan.json --format markdown
2 weeks = 10 working days
Per person:
- 10 days × 8 hours = 80 hours raw
- Minus PTO/holidays (e.g., 1 day) = 72 hours
- Minus meetings (~10 hrs) = 62 hours
- Minus on-call (~4 hrs avg) = 58 hours
- Minus interrupts/support (~6 hrs) = 52 hours
- Focus factor 0.7 = ~36 hours of "real" work
Team of 8 × 36 hours = 288 effective hours
= ~28 person-days of real engineering work
Most teams over-estimate capacity by 30-50%. Track actuals to calibrate.
| Filled at | Outcome |
|---|---|
| 100%+ | Always miss |
| 90-100% | Usually miss; no room for unknowns |
| 80-90% | Often achievable; healthy |
| 70-80% | Conservative; safer commits |
| < 70% | Under-committing; team disengaged |
Target: 80% commits + 15% stretch.
| Sprint goal | Why better |
|---|---|
| "Complete checkout MVP" | Outcome-aligned; defines what "done" looks like |
| "Ship feature X + Y + Z" | Feature list; what if one slips? |
| "Improve performance" | Vague; no done state |
A good sprint goal lets you say "we did it" or "we didn't" clearly.
Stories should be 1-5 days each. Stories > 5 days:
Mid-sprint, when you realize commit is too much:
Discipline: descope early. Heroic late nights = burnout + bugs.
references/capacity-math.md — deep on per-person capacity, focus factor, interrupt taxreferences/sprint-anti-patterns.md — common failures + fixesproject-management/scrum-master — process facilitationproject-management/execution/backlog-refinement — pre-sprint item prepproject-management/execution/story-splitting — sizing large storiesproject-management/execution/cycle-time-analyzer — velocity trackingproject-management/sprint-retrospective — post-sprint learningc-level-advisor/vpe-advisor — capacity planning at scale