CtrlK
BlogDocsLog inGet started
Tessl Logo

sprint-plan

Capacity-gated sprint planning — runs capacity math, carry-over check, and a definition-of-ready gate before committing scope. Usage: /sprint-plan <goal> [capacity]

60

Quality

71%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.gemini/skills/sprint-plan/SKILL.md
SKILL.md
Quality
Evals
Security

/sprint-plan

Create a sprint plan for $ARGUMENTS with explicit capacity math, a carry-over check, and a definition-of-ready gate. The first token(s) of $ARGUMENTS are the sprint goal; a trailing number is treated as team capacity (story points or person-days). If no capacity is given, compute it in Phase 1 — never invent it.

Usage

/sprint-plan <goal> [capacity]
# e.g. /sprint-plan "Checkout v2 ready for beta" 34

Phase 1 — Capacity Math (do the arithmetic, show it)

  1. Raw capacity = team size × working days in sprint × focus factor (default 0.7; ask if unknown)
  2. Deductions — subtract, explicitly and line by line: holidays/PTO, on-call/support rotation, ceremonies (~10%), known interrupts
  3. Velocity cross-check — compare against the rolling average of the last 3 sprints' completed (not committed) points. If computed capacity exceeds trailing velocity by >15%, plan to trailing velocity and say so.

Output a small table: raw → deductions → net capacity → trailing velocity → planning number.

Phase 2 — Carry-Over Check (before adding anything new)

  1. List every item carried over from the last sprint (not Done at sprint close)
  2. Re-estimate remaining effort — never carry the original estimate
  3. Carry-over consumes capacity first; new scope only gets what is left
  4. If carry-over exceeds ~30% of capacity, flag it as a systemic over-commitment signal and recommend a smaller commitment this sprint, not a bigger push

Phase 3 — Definition-of-Ready Gate (per story)

A story may enter the committed scope only if all of these hold — otherwise it goes to "needs refinement", not the sprint:

  • User story has a clear actor, action, and outcome (INVEST-compliant)
  • Acceptance criteria written and testable
  • Estimated by the team (not by the planner alone)
  • Dependencies identified and either resolved or scheduled
  • Small enough to finish within the sprint (split if not)

Generate INVEST-checked stories from an epic with:

python3 product-team/agile-product-owner/skills/agile-product-owner/scripts/user_story_generator.py

Phase 4 — Output Structure

  • Sprint goal — one sentence; everything committed must serve it
  • Capacity table — from Phase 1
  • Carry-over — from Phase 2, listed first in committed scope
  • Committed scope — stories that passed the DoR gate, summing to ≤ planning number
  • Stretch scope — clearly separated; pulled only if committed scope finishes
  • Risks and dependencies — with named owners
  • DoR exceptions — empty if the gate was honored; otherwise justify each

Repo Assets (verified paths)

  • Skill: product-team/agile-product-owner/skills/agile-product-owner/SKILL.md
  • Sprint planning template: product-team/agile-product-owner/skills/agile-product-owner/assets/sprint_planning_template.md
  • Sprint planning guide: product-team/agile-product-owner/skills/agile-product-owner/references/sprint-planning-guide.md
  • Story generator: product-team/agile-product-owner/skills/agile-product-owner/scripts/user_story_generator.py

Related

  • /sprint-health — mid-sprint health check
  • /user-story — single-story generation with INVEST checks
Repository
alirezarezvani/claude-skills
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.