Sprint planning

Skill SkillMedev/product-manager-stack/skills/sprint-planning

Roadmaps, specs, sprints, and analytics — the PM’s full operating kit.

Install

npx -y skills add SkillMedev/product-manager-stack --skill sprint-planning

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Facilitates sprint planning end to end - backlog refinement checks against a Definition of Ready, a one-sentence sprint goal, capacity math from velocity and PTO, story selection and team commitment, task breakdown, and flagged risks with owners. Use when a team asks "plan our next sprint", "how much should we commit to", "write a sprint goal", or keeps blowing sprint forecasts. Do NOT use for running the retrospective after the sprint ends - use sprint-retro-facilitator instead.

SKILL.md

3.4 KB, as published. Nobody here has run it

Sprint Planning

Sprint planning answers two questions: what can we deliver this sprint, and how will we do it? This skill keeps planning focused, realistic, and fast.

Before planning: refine the backlog

Hold backlog refinement ahead of planning (mid-previous-sprint), so stories arrive ready:

Each candidate story meets the Definition of Ready: clear, has acceptance criteria, estimated, dependencies known, small enough to finish in a sprint.
Order the backlog by priority so the top is "next up".
Split any story too big to fit a sprint.

Going into planning with an unrefined backlog is the #1 cause of bad sprints.

Step 1: Set the sprint goal

Start with a single sprint goal - a one-sentence objective the sprint serves (e.g. "Users can reset their password end to end"). The goal:

Gives coherence and a reason to say no to scope creep.
Lets the team make trade-offs mid-sprint without re-planning.

Step 2: Determine capacity

Don't plan to 100% - plan to realistic capacity:

For each member:
  available days in sprint
  - planned PTO / holidays
  - meetings / on-call / support overhead (~20-30%)
  = effective capacity

Use the team's recent velocity (avg points completed over last 3-4 sprints) as the anchor for how much to pull in. Adjust for capacity changes this sprint.

Step 3: Select and commit

Pull stories from the top of the refined backlog until you reach capacity/velocity.
For each, the team confirms it understands the work and acceptance criteria.
The team commits to a forecast it believes is achievable - commitment is the team's, not imposed. Leave a small buffer for the unexpected.

Step 4: Break down into tasks

For committed stories, decompose into tasks (the "how"):

Tasks are concrete steps ("write migration", "add endpoint", "QA flow").
Surfacing tasks reveals hidden work and dependencies before the sprint starts.

Step 5: Flag risks and dependencies

Explicitly call out:

Dependencies on other teams / external inputs - and their status.
Unknowns that could blow up estimates.
Single points of failure (only one person can do X).

Note a mitigation or owner for each risk. Risks named on day 1 are manageable; risks discovered on day 8 are fire drills.

Planning meeting checklist

Sprint goal stated in one sentence.
Capacity calculated, not assumed.
Every committed story meets Definition of Ready.
Stories broken into tasks.
Risks and dependencies flagged with owners.
Team genuinely believes the forecast is achievable.

Anti-patterns

Planning to maximum capacity with no buffer - one surprise sinks the sprint.
Committing to unrefined stories - they expand and derail the plan.
A manager dictating scope - kills ownership and accuracy.
No sprint goal - the sprint becomes a disconnected task list with no way to prioritize.