Sprint Plan

Use this skill to produce a concise sprint planning document for engineering or product alignment.

Workflow

1. Identify the sprint outcome in one sentence.
2. Add a concise bullet summary beneath the goal.
3. State why this work matters now, using one concrete example if available.
4. Separate current gaps from proposed work.
5. Keep scope explicit: In Scope and Out Of Scope.
6. Break work into 4-8 workstreams.
7. For each workstream, include Goal, Deliverables, and Done when.
8. Add decision principles only when they clarify tradeoffs.
9. End with definition of done, success metrics, and risks/open questions.

Avoid day-by-day plans unless the user explicitly asks for scheduling.

Template

# \x3CSprint Name>

## Sprint Goal

\x3COne clear sentence describing the outcome.>

## Summary

- \x3CMost important outcome or user-visible change.>
- \x3CMain internal/process improvement.>
- \x3CKey automation, quality, or measurement improvement.>

## Context

\x3CWhy this matters now. Include a canonical example if useful.>

## Current Gaps

- \x3CWhat is broken or missing today.>

## In Scope

- \x3CWhat this sprint will attempt to ship.>

## Out Of Scope

- \x3CWhat this sprint will intentionally avoid.>

## Workstreams

### 1. \x3CWorkstream>

Goal: \x3CShort outcome.>

Deliverables:

- \x3CConcrete deliverable.>

Done when: \x3CObservable completion criteria.>

### 2. \x3CWorkstream>

Goal: \x3CShort outcome.>

Deliverables:

- \x3CConcrete deliverable.>

Done when: \x3CObservable completion criteria.>

## Decision Principles

- \x3CTradeoff or rule that should guide implementation decisions.>

## Definition Of Done

- \x3CSprint-level completion checklist.>

## Success Metrics

- \x3CObservable outcome or metric.>

## Risks / Open Questions

- \x3CUnresolved assumption, dependency, or risk.>

Style

• Be direct and readable.
• Prefer concise bullets over long paragraphs.
• Keep the doc focused on alignment, not exhaustive execution detail.
• Avoid grand strategy unless the sprint depends on it.
• Preserve user-provided language when it is clearer than generic planning jargon.