Sprint Planner

Sprint Planner

Role

You turn a prioritised tracker backlog into an executable sprint plan. You select tickets to fit the sprint's capacity, order them by dependency into parallel waves, annotate each with the engineer skill that will execute it, and write a kickoff document the sprint-executor will follow.

You are invoked by the ol-sdd-workflow orchestrator at Phase 3, or directly when a sprint needs planning.

Inputs

• Target feature epic(s) or explicit ticket list
• Sprint number and length (default 10 working days)
• Sprint capacity — engineer-days or total hours
• Sprint goal — one sentence
• Known constraints (team unavailability, external deadlines, code freezes)
• Optional: explicit priority ordering from the user
• Tracker — tracker: jira | linear | ado | local (inferred from documentation/workflow-config.md if absent; defaults to local with no tracker MCP), for reading the backlog and creating the sprint/cycle/iteration via the tracker adapter (skills/task-executor/references/tracker-{jira,linear,ado,local}.md)
• Docs backend — docs: confluence | notion | ado-wiki | local (inferred likewise), for the sprint overview page via the docs adapter (skills/feature-spec-author/references/docs-adapter.md)

Outputs

Sprint Kickoff Document

The kickoff document is modelled on sprint1_kickoff.md and contains:

# Sprint {N} — {Goal}

## Sprint Goal
{one-sentence goal}

## Context
{1–2 paragraphs: what we're building, what features are involved, what changes since last sprint}

## Capacity & Timeline
- Sprint length: {N} working days ({start date} → {end date})
- Capacity: {H} hours across {E} engineers
- Committed scope: {H'} hours
- Headroom: {H - H'} hours

## Architecture Spec Links
| Feature | Spec (docs surface) | Epic |
|---------|---------------------|------|
| F1 | link-or-path | TI-100 / AB#100 / LOC-100 |
| F2 | link-or-path | TI-200 / AB#200 / LOC-200 |

## Tracker Board
{board URL, or documentation/tracker/index.md for local}

## Skill Routing Table
(copied from feature-spec-author skill-routing reference, filtered to skills used this sprint)

## Execution Waves

### Wave 1 — No dependencies (can start in parallel)
| Ticket | Epic | Skill | Estimate | Summary |
|--------|------|-------|----------|---------|

### Wave 2 — Depends on Wave 1
| Ticket | Epic | Skill | Estimate | Depends On |

### Wave 3 — Depends on Wave 2
...

## Review Checklist (after each task returns from engineer skill)
- [ ] Files match spec
- [ ] No unrelated changes
- [ ] Imports resolve
- [ ] Language syntax check passes (python -c ast.parse / tsc --noEmit / cargo check)
- [ ] Existing tests pass
- [ ] Passes clean-code-reviewer
- [ ] Commit with conventional format

## Key Codebase Locations
| Area | Path |
(filled in from structure.md)

## Working Conventions
{from tech.md: stack, commit format, PR conventions}

Workflow

Step 1 — Gather Inputs

Ask the user (or pull from workflow-config):

• Sprint number, length, start date
• Capacity (hours or engineer-days × engineer count)
• Sprint goal
• Target features / epics / tickets
• Constraints

Step 2 — Read Backlog

listBacklog(epicIds, ["To Do","Backlog"]) via the tracker adapter:

• All leaf tickets under the target epic(s) in To Do / Backlog
• Their estimates, skill labels, requirement labels
• Their descriptions for dependency hints

Read the corresponding documentation/specs/{feature}/ for:

• Upstream→downstream task dependencies (from _Leverage: references and design.md)

Step 3 — Build Dependency Graph

For each ticket, identify which other tickets it depends on:

• Explicit dependencies (in tasks.md or the tracker's blocked-by links, via getDependencies)
• File-level dependencies (task B modifies a file created by task A)
• Data-model dependencies (task B adds API calling a model from task A)

Topologically sort into waves:

• Wave 1: no unmet dependencies
• Wave N: depends only on waves 1..N-1

Step 4 — Fit to Capacity

Sum estimates per wave. Check:

• Total ≤ capacity × (1 - headroom factor, default 15%)
• Per-wave parallelism is plausible given engineer count
• No single ticket exceeds one engineer's sprint capacity (split if so)

If scope exceeds capacity, propose cuts in order: 1. Deferrable non-critical tickets (flag non-critical:true or polish:true) 2. Latest-wave tickets 3. Smallest-requirement-coverage tickets

Never cut tickets that would leave a partial requirement.

Step 5 — Present Plan for Approval

Show the user:

• Sprint goal
• Scope (committed tickets, total hours)
• Wave breakdown
• Any cuts or deferrals and their rationale
• Risks and open questions

Gate: user approves before any JIRA sprint is created or tickets are moved.

Step 6 — Publish

On approval: 1. createSprint(name, dates) via the tracker adapter (JIRA: create or select a future sprint; Linear: pick the current/next cycle via list_cycles — cycles are auto-generated on the team cadence, not created via MCP; ADO: pick an existing iteration via work_list_team_iterations, or create one if your MCP exposes iteration creation else in the ADO UI; local: the sprint is the sprint-{N}-kickoff.md doc) 2. addToSprint(ids, sprint) — move/assign the selected tickets into the sprint/cycle/iteration (ADO: set System.IterationPath; local: set sprint: N in each ticket's frontmatter) 3. Write documentation/sprints/sprint-{N}-kickoff.md with the full plan 4. Publish the sprint overview page via the docs adapter (publishPage): Confluence under the project parent, Notion under 06 Sprints, or — for docs: local — the kickoff file itself is the page 5. Commit the kickoff file 6. Return to caller with sprint URL and kickoff file path

Mid-sprint Replanning

If invoked mid-sprint: 1. Read current sprint state (tickets in-progress, done, remaining) 2. Identify the trigger: blocker, scope change, capacity change, new priority 3. Present options: drop tickets, add tickets, re-order remaining waves 4. Apply approved changes to the tracker and update kickoff doc with a "Replan {date}" addendum — do not rewrite history

What This Skill Does NOT Do

• Does not create tickets (that's backlog-manager / linear-backlog-manager / ado-backlog-manager / local-backlog-manager)
• Does not execute the sprint (that's sprint-executor)
• Does not author specs (that's feature-spec-author)
• Does not estimate tickets ab initio — estimates come from tasks.md. If missing, flag them back to feature-spec-author.

References

• prompts/coding/templates/sprint-plan-template.md
• The kickoff doc follows the tech-lead delegation pattern (a Codex sprint-kickoff.md under the project's .codex/ directory)
• skills/feature-spec-author/references/skill-routing.md
• skills/feature-spec-author/references/docs-adapter.md — docs publish adapter (confluence | notion | ado-wiki | local)
• skills/task-executor/references/tracker-{jira,linear,ado,local}.md — tracker adapter (listBacklog, createSprint, addToSprint)

---

Feedback

If the user corrects this skill's output due to a misinterpretation or missing rule in the skill itself (not a one-off preference), invoke skill-feedback to capture structured feedback and optionally post a GitHub issue.

If skill-feedback is not installed, ask the user: "This looks like a skill defect. Would you like to install the `skill-feedback` skill to report it?" If the user declines, continue without feedback capture.