Project Management Sprint Planning

---
name: project-management-sprint-planning
description: Plan a sprint end to end — capacity, velocity target, stories pulled from the backlog, sprint goal, task breakdown and risks. Use when a new sprint is about to start and the user needs to decide what the team will commit to. Not for only the goal, or capacity over several sprints; see /project-management-sprint-goal or /project-management-capacity-planning.
metadata:
  argument-hint: "[project] [--skip-checks]"
  workflow: project-management
  phase: 1
  artifact: 01-plan.md
---

# Sprint Planning

Plan a sprint for "$ARGUMENTS". Calculate team capacity, determine velocity target, select stories from the prioritized backlog, define the sprint goal, break stories into tasks, and identify sprint risks.

**Arguments.** `$ARGUMENTS` may contain the project name and optional flags. Take the first token as `<project>` and treat `--skip-checks` as a flag; never include flags in file paths. All paths below use `<project>`. If `--skip-checks` is present, skip the prerequisite check and, **before writing any artifact**, append one line to `.singularskills/log.jsonl`: `{"ts":"<ISO timestamp>","skill":"project-management-sprint-planning","workflow":"project-management","phase":1,"project":"<project>","event":"skipped","artifact":"01-plan.md","note":"<reason or \"none given\">"}`.

## Prerequisites

**Part of a workflow.** This skill is phase 1 (Plan) of the Scrum workflow (`project-management`); cross-domain workflows run it too. First check `.singularskills/log.jsonl` for an open run for this project: a `run-started` line with `"project":"<project>"` and no later `run-finished` line for the same `workflow` and `project`. If one exists, the conductor is running you: continue here. Otherwise, if the user asked to start, run, continue or resume a process or workflow rather than this one step, do not continue here: invoke the `workflow` skill with the workflow the user asked for, or `project-management` when they named none, followed by `<project>`; it runs this phase in order, asks before it writes and records the run. Otherwise continue here: a later phase runs on its own, behind its gate.

Run this skill's gate before writing: `sh <this skill's folder>/scripts/gate.sh <project> <project root>`, where `<project root>` is the folder that contains `.singularskills/` (use `.` when you are already there). If it exits non-zero, stop and tell the user what it printed, unless `--skip-checks` was given (see Arguments). On a refusal, before you stop, append this line to `.singularskills/log.jsonl` (create the folder and file if missing): `{"ts":"<ISO timestamp>","skill":"project-management-sprint-planning","workflow":"project-management","phase":1,"project":"<project>","event":"refused","artifact":"01-plan.md","note":"<what the gate printed>"}`. Once the gate has passed, or under `--skip-checks` once you have appended the `skipped` line, append this line before you start work: `{"ts":"<ISO timestamp>","skill":"project-management-sprint-planning","workflow":"project-management","phase":1,"project":"<project>","event":"started","artifact":"01-plan.md","note":""}`.

Check that `.singularskills/project-management/<project>/00-initiate.md` exists. If it does not, tell the user to run an Initiate skill first (e.g., project-charter) and stop.

## Process

1. **Read existing context:**
   - Read `.singularskills/project-management/<project>/00-initiate.md` for charter and team context
   - Read `.singularskills/project-management/<project>/01-plan.md` if it exists (for backlog, estimates, and roadmap)
   - Read `references/scrum-guide.md` for Scrum alignment

2. **Calculate team capacity:**
   - Identify team members available for this sprint
   - For each member: available days = sprint length minus PTO, meetings, and other commitments
   - Apply focus factor: 0.6 for new teams, 0.7 for established teams, 0.8 for mature teams
   - **Team capacity** = sum of (available days x focus factor) for all members
   - Express capacity in person-days and convert to available hours (person-days x 6 productive hours)
   - Document any capacity risks (key person on vacation, new team member ramping up)

3. **Determine sprint velocity target:**
   - **New teams:** start with 20-30 story points per sprint (be conservative, use 20 for first sprint)
   - **Existing teams:** use the average velocity of the last 3 sprints
   - Adjust velocity for known capacity changes (team member absent, holiday week)
   - Set a velocity range: committed (80% of target) and stretch (100% of target)
   - Do not overcommit — it is better to finish early and pull more work than to carry over

4. **Select stories from the top of the prioritized backlog:**
   - Pull stories from the top of the backlog (highest priority first)
   - Add stories until the committed velocity is reached
   - Optionally add 1-2 stretch stories up to the full velocity target
   - Verify that selected stories have clear acceptance criteria (if not, they are not sprint-ready)
   - Check for dependencies between selected stories and stories not in the sprint
   - Ensure the selected stories form a coherent set — not just random high-priority items

5. **Define the sprint goal:**
   - Write one clear sentence describing the sprint's purpose and what the team aims to achieve
   - The goal should be outcome-oriented: what value will be delivered, not what tasks will be done
   - All selected stories should contribute to the sprint goal (or be explicitly labeled as side work)
   - Examples: "Enable users to complete the onboarding flow end-to-end" or "Deliver the core search functionality with basic filtering"
   - The sprint goal guides trade-off decisions during the sprint

6. **Break selected stories into tasks:**
   - For each story, identify the implementation tasks (development, testing, review, deployment)
   - Estimate each task in hours (not points — tasks use hours, stories use points)
   - Typical task types: design, frontend, backend, API, database, testing, documentation, review
   - Verify that total task hours do not exceed team capacity in hours
   - Assign tasks to team members based on skills and availability (if team assignments are known)

7. **Identify sprint risks and dependencies:**
   - **Internal risks:** complex stories, new technology, knowledge gaps, tight capacity
   - **External risks:** dependencies on other teams, API availability, pending approvals, data access
   - **Mitigation:** for each risk, define a mitigation action or contingency plan
   - **Dependencies:** map which stories depend on which tasks completing first
   - Define a sprint execution order: which stories should be started first based on dependencies and risk

8. **Write the artifact** — append to `.singularskills/project-management/<project>/01-plan.md` under a `## Sprint Planning` section. Create the file with a `# Plan — <project>` heading if it does not exist; if a `## Sprint Planning` section already exists, replace only that section. The section contains:
   - **Sprint Goal** — one clear sentence
   - **Team Capacity** — members, available days, focus factor, total capacity
   - **Velocity Target** — committed and stretch velocity with rationale
   - **Sprint Backlog** — selected stories with estimates, acceptance criteria status, and priority
   - **Task Breakdown** — tasks per story with hour estimates and assignments
   - **Risks & Dependencies** — identified risks with mitigation and dependency map
   - **Sprint Execution Order** — recommended order for starting stories

## Output

Sprint planning appended to `.singularskills/project-management/<project>/01-plan.md`. Present a summary highlighting:
- Sprint goal
- Team capacity and velocity target
- Number of stories selected (committed vs. stretch)
- Total story points committed vs. team velocity
- Top sprint risks and mitigation plans

**Record the run.** After you have written your section, append this line to `.singularskills/log.jsonl` (the `started` line of Prerequisites, with `"event":"finished"`): `{"ts":"<ISO timestamp>","skill":"project-management-sprint-planning","workflow":"project-management","phase":1,"project":"<project>","event":"finished","artifact":"01-plan.md","note":""}`.

This artifact is shared by every skill of phase 1 (Plan). The frontmatter is written once, by whoever creates the file: if you create it, open it with the block below (`skill` is the phase title, `started` the time of that first write; `gate` is `passed` when the gate ran clean and `skipped` under `--skip-checks`); if it already exists, leave the block alone except to update `finished` and to set `gate` to the worst value among the sections (`skipped` over `passed`).

```yaml
---
skill: Plan
workflow: project-management
phase: 1
project: <project>
started: <ISO timestamp>
finished: <ISO timestamp>
agent: <the agent you run in, or "unknown">
gate: <passed|skipped>
---
```

Open your `## Sprint Planning` section with one italic line, `*<skill name> · <ISO timestamp> · gate: <passed|skipped>*` (your skill name is `project-management-sprint-planning`).

End your section with `### Decisions` and `### Open questions` (one level under your `## Sprint Planning` heading, so the section stays one block), in this shape:

```markdown
### Decisions
- <what was chosen> — <why> — <what was rejected>

### Open questions
- <what the next phase or a reviewer must settle>
```