Receber por email
← Voltar para o catálogo

sprint-planning

Estrutura e facilita sessões de planejamento de sprint, organizando itens do backlog, atribuindo story points e definindo metas de sprint. Gera uma meta de sprint, um backlog calibrado por velocidade e uma agenda estruturada para a reunião de planejamento.

991estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add mohitagw15856/pm-claude-skills

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/sprint-planning-mohitagw15856/svg)](https://www.skillteca.com.br/skills/sprint-planning-mohitagw15856)
#ai

Skills relacionadas

Ver todas de DevOps e Infra →

Alerta por categoria

Receba novas skills de DevOps e Infra toda segunda

1 email curto, só com as skills novas de DevOps e Infra. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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
Compartilhar X LinkedIn