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

Output	Where
documentation/sprints/sprint-{N}-kickoff.md	Committed sprint plan (format below)
Sprint/cycle	JIRA sprint / Linear cycle / ADO iteration created or populated; local: sprint: N set on each ticket. Tickets moved in
Docs page (Confluence, Notion, ADO Wiki, or local)	Sprint overview page via the docs adapter

Sprint Kickoff Document

The kickoff document follows prompts/coding/templates/sprint-plan-template.md — the single source of truth for its format (sections: Sprint Goal, Context, Capacity & Timeline, Architecture Spec Links, Skill Routing Table, Task Execution Order / Execution Waves, Review Checklist, Key Codebase Locations, Working Conventions, Cuts & Deferrals, Open Questions, Retrospective). Use the template's Capacity & Timeline table and carry the per-ticket Engine column through the wave tables unchanged.

In addition to the template sections, include an Execution Strategy block — the contract sprint-executor reads in mode: parallel (omit for serial-only sprints):

• Mode: parallel | serial
• Isolation: worktree
• Max concurrency: {min(widest wave, 4)}
• Worktree naming: ../.sdd-worktrees/sprint-{N}/{ticket-id} on branch exec/{ticket-id}, off sprint base sprint-{N}
• See skills/task-executor/references/parallel-execution.md for the mechanism.

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, exec:{engine} labels, requirement labels
• Their descriptions for dependency hints

The exec:{engine} per ticket was assigned by the backlog-manager (Phase 2). Carry it through unchanged into the kickoff's Engine column — the sprint planner does not re-classify or override it (the user already reviewed it at the Phase-2 gate). The agent:{engine} label (agent:claude / agent:codex, from the ol-sdd-workflow multi-engine pattern) is accepted as an alias when no exec: label is present; if both are present and disagree, exec: wins. Only if a ticket has neither label, default it (complex → claude, simple → codex) and flag it back so the backlog stays the source of truth.

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 (with the per-ticket Engine column)
• Execution strategy: mode (parallel/serial), worktree isolation, max concurrency, and the engine mix (n claude / m codex)
• Any cuts or deferrals and their rationale
• Risks and open questions

Gate: user approves before any sprint/cycle/iteration 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)
• skills/task-executor/references/parallel-execution.md — the worktree + subagent + engine mechanism the Execution Strategy block configures for sprint-executor

---

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.