sprint_planning v1.0.0

name: "sprint_planning" description: "Run sprint planning for a small team: backlog readiness checks, capacity math from real availability and velocity, Sprint Goal setting, item selection to a planning target, and a facilitation runbook. Use when planning a Sprint, preparing for sprint planning, checking whether backlog items are ready, calculating team capacity, or fixing Sprints that keep carrying work over."

Sprint Planning

Purpose

Plan a Sprint the team can actually finish. This skill covers the whole job: check that the top of the backlog is ready, calculate capacity from real availability instead of headcount, set one Sprint Goal, pull items in order until a planning target is reached, and leave with a written plan, named risks, and a confidence check. It follows the 2020 Scrum Guide structure for the event and adds the capacity calculator and checklists the Guide leaves to the team.

Use it for Scrum Sprints of one to four weeks. Teams using Kanban or a Shape Up style cycle can still use the readiness checklist and the capacity math, but the goal and selection steps assume a fixed length Sprint.

Workflow

1. Gather the inputs before anyone sits down

Collect these first. Planning without them turns into guessing in a room.

• Sprint length in working days, and the dates.
• Availability per person: days present, leave, part time share, support or on-call load.
• Points Done for the last 3 to 5 Sprints, plus what carried over each time. Count only work that met the Definition of Done. Half finished items count as zero.
• The Product Goal in one line, and the Product Owner's proposed objective for this Sprint.
• The backlog in order, with the top items refined.
• Action items from the last retrospective that land in this Sprint. They cost capacity like any other work.

If there is no velocity history because the team is new, say so and plan in person-days (step 3 covers both paths). Do not invent a velocity.

2. Run the readiness check on candidate items

Apply references/readiness-checklist.md to the top of the backlog, enough items to cover about one and a half times the expected planning target.

• Hard checks: value stated, testable acceptance criteria, fits inside one Sprint, sized by the team that will build it, dependencies named, no blocking open question, needed assets linked.
• An item that fails a hard check does not enter the Sprint. Send it back with a named owner and the specific gap to close.
• Too big is the most common failure. Split by workflow step, data variation, user type, or happy path first, until each piece can be demoed on its own.

Do this in refinement before planning day when you can. Live refinement in front of the whole team is the main reason planning sessions run long.

3. Calculate capacity, then set the planning target

Run the calculator with real availability:

python3 scripts/capacity.py --sprint-days 10 --focus 0.8 --member "Ana:10:1.0" --member "Ben:8:1.0" --member "Cy:10:0.5" --velocity 32,28,35,30

How the math works:

• Effective person-days per person: days present, times their availability fraction, times the team focus factor.
• Velocity: mean of points Done over the last 3 to 5 Sprints. The script also reports the median and warns when the spread is wide, because a wide spread means the forecast is rough and the team should plan to the low end.
• Raw capacity: mean velocity scaled by this Sprint's effective days against a normal Sprint's days.
• Planning target: raw capacity times a buffer factor. Use 0.8 for a stable team with known work, 0.7 when the team changed, the work is new, or recent Sprints carried work over (--buffer uncertain).

Rules that keep the math honest:

• Count each load once. If the focus factor already covers meetings and interrupts, per person fractions carry only leave, part time, and support. Double counting shrinks capacity on paper and teaches the team the numbers are fake.
• Carryover, bug fixes, support, and retrospective items come out of the same capacity. Nothing rides on top of the target for free.
• Never plan to 100 percent of raw capacity. Unplanned work always arrives, and a Sprint with no slack turns the first surprise into carryover.
• Velocity is a planning input for this team only. Never use it to compare teams or rate individuals, and say that out loud if someone tries.

4. Set the Sprint Goal (the Why)

Sprint Planning in the Scrum Guide covers three topics: why this Sprint is valuable, what can be Done, and how the work will get done. The Sprint Goal answers the first one and must be finished by the end of planning.

• The Product Owner proposes how the Sprint could increase the product's value, tied to the Product Goal.
• The whole team writes the goal together: one sentence, one outcome, checkable at the Sprint Review.
• Good shape: an outcome a user or the business can feel, for example "New users can finish signup without help from support."
• Bad shapes: a list of tickets, a vague direction like "improve onboarding", or several goals joined with "and". Several goals means no goal.
• Test: if every item finished but the goal failed, would the Sprint feel like a loss? If the answer is no, rewrite the goal.

5. Select items to the target (the What)

• Pull from the top of the ordered backlog, in order, favoring items that serve the Sprint Goal.
• Keep a running total of selected points and stop at the planning target from step 3. Stopping is the discipline. The item that crosses the target stays out unless the team swaps something of equal or larger size out.
• If an item turns out not ready during selection, park it with its gap and owner, and pull the next ready item.
• List one or two pull-forward options, ready items the team may start only if selected work finishes early and clean. Pull-forward work is not a commitment.
• Handle carryover plainly: re-size what remains, count it once in this Sprint, and name why it carried. Two Sprints of carryover on the same item means the item is too big or blocked, and that gets fixed before it is planned a third time.

6. Sketch how the work gets done (the How)

• Developers break the first selected items into tasks and name owners for the first steps.
• Plan the first two to three days concretely. Keep the rest at item level, detail further out decays fast.
• Name the riskiest item and the first move, inside the first two days, that cuts that risk.
• Write down every external dependency with a person and a date.
• Note where two people would collide on the same code, environment, or review queue, and order the work to avoid it.

7. Close with a confidence check and publish the plan

• Read the Sprint Goal back and take a confidence vote, 1 to 5 from each person. Anyone at 2 or below names what would raise their vote, and the team adjusts scope or plan in the room.
• Publish the plan the same day where the team and stakeholders can see it. Use the output contract below.
• Facilitation timing, prompts, and fixes for common trouble (scope creep mid-session, one voice dominating sizing, a not-ready item stalling the room) are in references/facilitation-runbook.md.
• A full numeric example, inputs to published plan, is in references/worked-example.md.

Timebox: the Scrum Guide caps Sprint Planning at 8 hours for a one-month Sprint, with shorter Sprints usually taking less. Treat the cap as a ceiling, not a target. A small team with a refined backlog should finish a two week Sprint's planning in about 90 minutes to 3 hours.

Output Contract

Every planning run produces one written Sprint Plan with exactly these parts:

• Sprint Goal: one sentence, plus the Product Goal it serves.
• Capacity summary: Sprint days, effective person-days, velocity mean and median if history exists, raw capacity, buffer factor used, and the planning target in points.
• Selected items: each with its size, a note on how it serves the goal (or marked secondary), and its dependencies. Running total shown against the target.
• Pull-forward options: ready items that may be started only if selected work finishes early. Marked as not committed.
• Carryover: any item carried from last Sprint, its new size, and the reason it carried.
• Risks and dependencies: each with an owner and, for external dependencies, a name and a date.
• Confidence: the lowest vote, the reason given, and the adjustment made.
• Dates: Sprint start, Sprint end, review date.

If any part cannot be produced, the plan says which part and why, for example no velocity history for a new team. A plan with a silent gap is a failed plan.

Operating Rules

• Developers decide how much work they can take on. The Product Owner orders the backlog and proposes the objective. Nobody outside the team raises the commitment on the team's behalf.
• The Sprint Goal is the commitment. Individual items can be swapped during the Sprint when learning demands it, as long as the goal holds and the swap is the same size or smaller.
• Readiness is a team agreement, not a Scrum Guide requirement. Keep the checklist short enough that people actually use it, and change it in a retrospective when it misses something real.
• Stop selection at the target even when stakeholders are in the room asking for one more item. The honest answer names what comes out to make room.
• Record the actuals at Sprint end: points Done, carryover, and whether the goal was met. Next Sprint's math is only as good as this record.
• If the team does not use story points, run the same workflow with item counts (throughput over the last 3 to 5 Sprints) or with t-shirt sizes converted to a rough count. The structure matters more than the unit.
• Do not copy percentage impact claims about planning practices from vendor blogs into plans or reports. If a number did not come from the team's own records or a primary source you read, leave it out.