sprint-planning
$
npx mdskill add mohitagw15856/pm-claude-skills/sprint-planningTransform raw backlog items into a structured, achievable sprint with clear goals, velocity-calibrated scope, and team-ready output.
SKILL.md
.github/skills/sprint-planningView on GitHub ↗
--- name: sprint-planning description: "Structure and facilitate sprint planning sessions. Use when asked to plan a sprint, organise backlog items, assign story points, create sprint goals, or prepare sprint planning agendas. Produces a sprint goal, velocity-calibrated backlog, capacity plan, risk flags, and a structured sprint planning meeting agenda." --- # 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 ## Inputs to Request From User 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
More from mohitagw15856/pm-claude-skills
- 360-feedback-templateDesign a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
- ab-test-plannerDesign statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
- accessibility-auditGenerate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
- account-planBuild a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.
- aeo-optimizerOptimize an article for Answer Engine Optimization (AEO) — restructuring content so AI engines like ChatGPT, Perplexity, and Claude can extract, quote, and cite it. Rewrites headings as questions, drops 50-80 word answer capsules, audits paragraph length, and flags trust signals. Use when asked to AEO-optimize, make content AI-readable, improve AI citation chances, or adapt an article for answer engines.
- ai-ethics-reviewConduct an ethical review of an AI or ML feature, model, or product. Use when asked to run an AI ethics review, assess AI risks, audit a model for bias, or produce an AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with prioritised mitigations.
- ai-product-canvasStructure 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.
- ambiguity-resolverStructure vague opportunities and unclear briefs into actionable one-page problem statements. Use when asked to clarify a vague brief, frame an undefined problem, make sense of an unclear opportunity, or when the user says 'we need to figure out what to do about X' or 'I've been asked to look into Y'. Produces a structured problem brief with reframed questions, scoped boundaries, and a minimum viable research plan.
- api-docs-writerWrite clear, developer-facing API documentation. Use when asked to document an API endpoint, write API reference docs, create a developer guide, or turn a raw spec/Postman collection into documentation. Produces endpoint documentation with descriptions, parameters, request/response examples, and error codes.
- api-versioning-strategyWrite an API versioning strategy document for a service or API platform. Use when asked to define versioning policy, plan API deprecation, classify breaking changes, or document version lifecycle. Produces a complete versioning strategy with breaking-change classification table, deprecation timeline, migration guide template, and client communication template.