Sprint Planning skill for Codex

A sprint plan is done well when the team can state one sprint goal in a sentence, the committed work fits the lower end of the team’s demonstrated throughput after absences and reserved capacity, every committed item met the definition of ready before planning started, and the plan says what gets dropped first if things go wrong.

Inputs to gather

1. Last 3-6 sprints of throughput: points or item counts completed (not committed). From GitHub Projects, Jira or Linear exports if the user provides them; via gh or an MCP connector if configured (needs network). Never estimate history from memory.
2. Availability: holidays, leave, on-call rotation, conferences, onboarding.
3. Carry-over: unfinished items from the current sprint and why.
4. Candidate items: the top of the ordered backlog, refined.
5. Team conventions: AGENTS.md, CONTRIBUTING.md, or a team wiki may define sprint length, estimation unit and definition of done.

Capacity

available days  = sum over people of (sprint working days - leave - holidays)
focus factor    = 0.6-0.8  (meetings, reviews, support; use team history if known)
capacity days   = available days x focus factor
reserve         = 15-25% of capacity for bugs, support, on-call
plannable days  = capacity days - reserve

Convert to points with the team’s own history: expected points = median velocity x (available days this sprint / available days in a typical sprint). Plan to the lower bound (the lowest of the last six sprints, or the 25th percentile with more history, scaled the same way), not the best sprint.

Example: 5 engineers, 10-day sprint, one person out 3 days, a public holiday for all: (5 x 9) - 3 = 42 available days, versus 50 typical; median velocity 34 points, lowest 28; expected 34 x 42/50 = 28.6, low end 28 x 42/50 = 23.5. Commit about 24 points, list about 5 more as stretch.

Sprint goal

• One sentence describing an outcome, not a list of tickets: “Admins can invite and remove members in production behind the team_invites flag.”
• At least 60-70% of committed points should serve the goal; the rest is maintenance and reserved work.
• The goal gives the team a basis for trade-offs mid-sprint: work that does not serve it is what slips first.

Definition of ready

An item enters planning only if:

• It has a clear outcome and acceptance criteria ($acceptance-criteria)
• It is small enough to finish in about half the sprint or less ($user-stories)
• Dependencies are resolved or scheduled, with named owners
• Designs or API contracts it needs exist
• The team has estimated it

Items that fail go back to refinement, not into the sprint “to figure out later”.

Refinement session (mid-sprint, before planning)

- [ ] Review top ~1.5 sprints' worth of backlog items
- [ ] Split anything larger than half a sprint
- [ ] Add or tighten acceptance criteria
- [ ] Flag unknowns; create time-boxed spikes for them
- [ ] Re-estimate items whose scope changed
- [ ] Re-order with the product owner

Planning workflow

- [ ] 1. Review last sprint: completed, carried over, reasons
- [ ] 2. Compute availability and capacity (show the arithmetic)
- [ ] 3. Product owner proposes the sprint goal and ordered candidates
- [ ] 4. Check definition of ready; send failures back
- [ ] 5. Pull items in order until the lower-bound capacity is reached
- [ ] 6. Mark stretch items and the first items to drop
- [ ] 7. Break committed items into tasks if the team does that
- [ ] 8. Write the sprint plan; confirm before updating the tracker

Moving tickets into a sprint, changing assignments or posting the plan to a shared channel changes shared state: show the changes and get approval first.

Sprint plan template

# Sprint 42 plan (Nov 3 - Nov 14)
Goal: <one sentence outcome>

## Capacity
People: 5 | Available days: 42 (typical 50) | Focus factor 0.7 | Reserve 20%
Velocity last 6: 34, 36, 28, 34, 39, 31 -> median 34, lowest 28 -> scaled 28.6 / 23.5
Commitment: 24 points | Stretch: 5 points

## Committed (serves goal)
| Item | Points | Owner | Notes |
## Committed (maintenance / reserve)
## Stretch
## Drop first if needed
## Risks and dependencies
## Carry-over from sprint 41 and why

Diagnosing chronic spillover

Symptom	Likely cause	Change
Same items carry over repeatedly	Items too large or poorly understood	Enforce half-sprint size limit; add spikes
Velocity swings more than 30%	Unplanned work not reserved	Track interruptions; raise reserve
Many items 80% done at sprint end	Too much work in parallel	Limit work in progress; swarm on items
Goal never met but points look fine	Commitment is unrelated tickets	Require 60%+ of points to serve the goal
Estimates drift upward each sprint	Points used as a performance target	Stop comparing velocity across teams or people

Gotchas

• Velocity is a planning tool for one team, not a productivity metric. Never compare it across teams or use it in reviews.
• Committing to the average means missing half the time; plan to the lower bound.
• Carry-over is re-estimated for the remaining work; do not double count its points.
• Do not assign estimates yourself; propose relative sizes only if the team asks.
• New joiners contribute little capacity in their first sprint; count them at about 25-50%.

Verification

Recompute the capacity arithmetic from the inputs and confirm the commitment is at or below the scaled lower bound; check every committed item passes the definition of ready; confirm at least 60% of committed points map to the goal; and confirm the plan names the items to drop first.