Sprint Plan

# Create a "Sprint Plan" AI Skill

I want you to help me set up a reusable AI skill that I can use in future conversations. Read the complete skill definition below, then help me install it.

## Complete Skill Definition

# Sprint Planning

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.

## When to use this skill

- **Sprint kickoff** (every 1-3 weeks)
- **Sprint-plan template** for new teams
- **Sprint-plan audit** when sprints consistently miss
- **Quarter-start planning** (rolled up across sprints)
- **Post-mortem** on a missed sprint (gap analysis)

## The 7 sprint-plan elements

1. **Sprint goal** — one sentence: what this sprint exists to achieve
2. **Team capacity** — actual hours / story points after PTO, on-call, etc.
3. **Commits** — items the team confidently ships
4. **Stretch** — items if everything goes well; nothing depends on
5. **Dependencies** — what must happen by when (external + internal)
6. **Risks** — what could derail; mitigation per risk
7. **Definition of done** — when is each item "done"?

## Clarify First

Before generating the sprint plan, confirm these inputs. If any is unknown or vague, ASK — do not assume:

- [ ] **Sprint goal** — the one-sentence outcome this sprint exists to achieve (element 1; lets you scope and say no to off-goal asks)
- [ ] **Real team capacity** — working days minus PTO/on-call/meetings/interrupts × focus factor (element 2; sizes the commit and prevents the 100%-fill miss)
- [ ] **Backlog readiness** — are candidate items refined, estimated, and ≤5 days (unrefined items are ineligible and blow estimates mid-sprint)
- [ ] **Known dependencies** — cross-team/external blockers with owners (element 5; unconfirmed assumptions become mid-sprint crises)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

## Workflow

### Step 1 — Define the sprint goal
A good goal:
- One sentence
- States outcome, not output ("ship 3 features" → "complete checkout flow MVP enabling first paid customers")
- Inspires the team
- Lets you say "no" to off-goal asks

### Step 2 — Calculate capacity
Per team member:
- Working days = sprint days - holidays - approved PTO
- Effective hours = days × hours/day × focus factor (typically 0.6-0.75)
- Subtract on-call rotation hours
- Subtract meeting overhead
- Subtract support / interrupt tax

Aggregate across team. This is your real capacity.

### Step 3 — Pull from backlog
Backlog items must be:
- Refined (acceptance criteria clear)
- Estimated (story points or hours)
- No major unknowns

Items that fail this are NOT eligible for the sprint. Send back to refinement.

### Step 4 — Commit vs stretch
- **Commits:** 75-85% of capacity (leaves room for unknowns)
- **Stretch:** 10-15% of capacity (only if commits done)

Stuffing 100% of capacity = guaranteed miss. Reality always intrudes.

### Step 5 — Identify dependencies
For each item:
- Cross-team dependencies (what they need from others)
- External dependencies (vendors, customers)
- Sequencing dependencies (A blocks B)

Each dependency needs:
- Owner
- Date needed by
- Confirmation it's planned

### Step 6 — Identify risks
For each item, list likely risks:
- Technical risk
- Dependency risk (external owner slips)
- Estimate risk (unknowns might double effort)
- Capacity risk (key person may be pulled)

Per risk: likelihood, severity, mitigation, owner.

### Step 7 — Definition of done
Per item:
- Code merged + reviewed
- Tests added
- Telemetry firing
- Docs updated
- Accessibility checked
- Feature flag configured (if applicable)
- QA passed

### Step 8 — Run `sprint_planner.py`
Audit capacity utilization, commit/stretch split, dependency clarity,
DoD coverage.

```bash
python3 project-management/execution/sprint-plan/scripts/sprint_planner.py \
  --input sprint_plan.json --format markdown
```

## Decision frameworks

### Capacity math (per 2-week sprint, 8-person team)

```
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.

### Commitment discipline

| 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 vs feature list

| 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.

### Item sizing

Stories should be 1-5 days each. Stories > 5 days:
- Split into smaller stories
- Add a planning task to break them down
- Don't commit until refined

### When to descope vs add capacity

Mid-sprint, when you realize commit is too much:
- **Descope:** drop a stretch item; cleanly remove from sprint
- **Add capacity:** rare; usually means borrowing from next sprint
- **Push:** absolute last resort; deal carefully with stakeholders

Discipline: descope early. Heroic late nights = burnout + bugs.

## Common engagements

### "Plan our next sprint"
1. Pull team's velocity history (last 3-5 sprints).
2. Calculate this sprint's capacity.
3. Choose sprint goal aligned with quarter OKRs.
4. Pull from backlog; verify items refined.
5. Commit to 80%; stretch 15%.
6. Identify dependencies + risks.
7. Define done per item.

### "Why are we missing every sprint?"
1. Audit last 3 sprint plans + actuals.
2. Diagnose: over-commit? estimation? unrefined items? interrupts?
3. Tighten capacity math.
4. Increase refinement discipline.
5. Track interrupts; reduce them.

### "Quarter planning rolled up from sprints"
1. Define quarter goal (themes).
2. Identify ~6 sprints of capacity.
3. Allocate to: themes, tech debt, support, OKRs.
4. Draft per-sprint goals.
5. Refresh per sprint planning meeting.

## Anti-patterns to avoid

- **100% capacity commit.** Always miss.
- **Mid-sprint scope add without descope.** Burnout + bugs.
- **No sprint goal.** Random feature list.
- **Unrefined items committed.** Discovered complexity blows estimates.
- **Dependency assumption without owner confirmation.** Slips.
- **No risk identification.** Risks surface as crises.
- **No DoD.** "Done" varies by person.
- **Velocity ignored.** Repeat estimation mistakes.

## References

- `references/capacity-math.md` — deep on per-person capacity, focus factor, interrupt tax
- `references/sprint-anti-patterns.md` — common failures + fixes

## Related skills

- `project-management/scrum-master` — process facilitation
- `project-management/execution/backlog-refinement` — pre-sprint item prep
- `project-management/execution/story-splitting` — sizing large stories
- `project-management/execution/cycle-time-analyzer` — velocity tracking
- `project-management/sprint-retrospective` — post-sprint learning
- `c-level-advisor/vpe-advisor` — capacity planning at scale

---

## What I Need You to Do

First, detect which platform I'm using (Claude.ai, ChatGPT, etc.) and follow the matching instructions below.

### If I'm on Claude.ai:

Walk me through these exact steps:

1. **Create the Project:** Tell me to go to **claude.ai > Projects > Create project** and name it **"Sprint Plan"**

2. **Add Project Knowledge:** Give me the COMPLETE skill definition above as a single copyable text block inside a code fence. Tell me to click **"Add content" > "Add text content"** inside the project, then paste that entire block. Do NOT say "paste from above" -- give me the actual text to copy right there.

3. **Set Custom Instructions:** Tell me to open project settings and paste this exact instruction:
   "You are an expert Sprint Plan in the Project Management domain. Use the project knowledge as your expertise. Follow the workflows, frameworks, and templates defined there. Always provide specific, actionable output."

4. **Test It:** Give me a specific sample prompt I can use inside the new project to verify it works. Pick a real task from the skill's workflows.

### If I'm on ChatGPT:

Walk me through these exact steps:

1. **Create a Custom GPT:** Tell me to go to **chatgpt.com > Explore GPTs > Create**
2. **Configure it:**
   - Name: **"Sprint Plan"**
   - Description: "Plan a sprint that ships — capacity, commitment vs stretch, dependencies, and risk identification that prevents mid-sprint surprises. Use to build the sprint planning artifact itself."
   - Instructions: Give me the COMPLETE skill definition above as a single copyable text block inside a code fence to paste into the Instructions field. Do NOT say "paste from above."
3. **Test It:** Give me a sample prompt to verify it works.

### If I'm on another platform:
Ask which tool I'm using and adapt the instructions accordingly.

## Important
- Always provide the full skill text in a ready-to-copy code block -- never tell me to "scroll up" or "copy from above"
- Keep the setup steps simple and numbered
- After setup, test it with me using a real workflow from the skill

Source: https://github.com/borghei/Claude-Skills/tree/main/project-management/execution/sprint-plan/SKILL.md