sprint-planning
The sprint-planning skill structures and executes sprint planning sessions by transforming backlog items into actionable sprints. Use it when organizing a sprint, estimating story points, defining sprint goals, assigning work to team members, or preparing meeting agendas. It produces a focused sprint goal, velocity-calibrated backlog with acceptance criteria, capacity plans accounting for team availability, risk identification, and a structured two-hour meeting agenda with timings.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/sprint-planning && cp -r /tmp/sprint-planning/plugins/pm-delivery/skills/sprint-planning ~/.claude/skills/sprint-planningSKILL.md
# Sprint Planning Skill Transform raw backlog items into a structured, achievable sprint with clear goals, velocity-calibrated scope, and team-ready output. ## What This Skill Produces - **Sprint Goal** — single, outcome-focused sentence the whole team can rally around - **Sprint Backlog** — prioritised list of user stories with story point estimates and acceptance criteria - **Capacity Plan** — team availability breakdown accounting for holidays, meetings, and focus time - **Sprint Planning Agenda** — structured 2-hour meeting agenda with timings - **Risk Flags** — blockers or dependencies that could derail the sprint ## Required Inputs Ask for (if not already provided): - Sprint duration (1 or 2 weeks) - Team size and velocity (average story points per sprint) - Top 3–5 backlog items or epics to pull from - Any known absences, holidays, or team events - Previous sprint's incomplete items (carry-overs) ## Sprint Goal Formula Use this structure: > "This sprint we will [deliver X outcome] so that [user/business benefit], measured by [success indicator]." Never write sprint goals as task lists. Always outcome-first. ## Story Point Calibration | Complexity | Points | Description | |---|---|---| | Trivial | 1 | Clearly understood, no unknowns | | Small | 2 | Straightforward, minor effort | | Medium | 3 | Some complexity, clear path | | Large | 5 | Complex, needs design or research | | Very Large | 8 | High uncertainty, may need splitting | | Epic | 13+ | Too large — must be split before sprint | Flag any item estimated at 8+ and recommend splitting. ## Capacity Formula ``` Available capacity = (Team size × Sprint days × Focus hours/day) × Availability factor Focus hours/day: 6 (accounting for meetings, Slack, admin) Availability factor: 0.7–0.85 depending on holidays/events Story points to commit = Historical velocity × Availability factor ``` ## Output Format ### Sprint [N] — [Start Date] to [End Date] **Sprint Goal:** > [Goal statement] **Team Capacity:** [X] story points available (based on [Y] team members, [Z]% availability) **Sprint Backlog:** | Priority | Story | Points | Owner | Acceptance Criteria | |---|---|---|---|---| | 1 | [Story title] | [N] | [Team member] | [When X then Y] | **Carry-Overs from Previous Sprint:** - [Item] — Reason for carry-over: [brief explanation] **Risks & Dependencies:** - [Risk description] → Mitigation: [action] **Sprint Planning Agenda:** - 00:00–00:10 — Review sprint goal and team capacity - 00:10–00:40 — Walk through backlog items, confirm estimates - 00:40–01:20 — Assign stories, identify dependencies - 01:20–01:50 — Review acceptance criteria per story - 01:50–02:00 — Confirm sprint commitment and close ## Guidelines - Always challenge stories missing acceptance criteria — flag them explicitly - Recommend the team commits to 80% of available capacity, not 100% - If no velocity data is provided, assume 20–30 points for a 5-person team as a starting point - Highlight any story with unclear ownership as a blocker ## Quality Checks - [ ] Sprint goal is outcome-focused (not "implement X" — something like "users can do Y") - [ ] Team capacity is calculated using actual availability, not theoretical 100% - [ ] Every story has an acceptance criterion (flag any that don't) - [ ] Stories estimated at 8+ points are flagged for splitting - [ ] Carry-overs from last sprint are accounted for in capacity ## Anti-Patterns - [ ] Do not write sprint goals as task lists — goals must be outcome-focused and scoreable pass/fail at sprint end - [ ] Do not commit to 100% of available capacity — always recommend 80% to preserve slack for unplanned work - [ ] Do not carry stories with no acceptance criteria into the sprint — flag them as blockers before committing - [ ] Do not allow stories estimated at 8+ points into the sprint without splitting them first - [ ] Do not ignore carry-over items when calculating capacity — they consume capacity and must be accounted for before new work is pulled in
Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.