plan-sprint

# Plan a Sprint

Plan a time-boxed sprint by selecting refined backlog items up to team capacity, defining a clear sprint goal, and decomposing selected items into actionable tasks. This skill produces a complete sprint plan that guides team work for the duration of the sprint iteration.

## When to Use

- Starting a new sprint in a Scrum or agile project
- Re-planning a sprint after significant scope change
- Transitioning from ad-hoc work to structured sprint cadence
- After backlog grooming when items are ready for sprint inclusion
- Planning the first sprint after project charter approval

## Inputs

- **Required**: Product backlog (prioritized, with estimates)
- **Required**: Sprint duration (typically 1-2 weeks)
- **Required**: Team members and their availability
- **Optional**: Previous sprint velocity (story points or items completed)
- **Optional**: Sprint number and date range
- **Optional**: Carry-over items from previous sprint

## Procedure

### Step 1: Review and Refine Backlog Items

Read the current BACKLOG.md. For each candidate item near the top of the backlog, verify it has:

- Clear title and description
- Acceptance criteria (testable conditions)
- Estimate (story points or T-shirt size)
- No unresolved blockers

Refine any items missing these elements. Split items estimated larger than half the sprint capacity into smaller, more manageable pieces.

**Got:** Top 10-15 backlog items are "sprint-ready" with acceptance criteria and estimates.

**If fail:** If items lack acceptance criteria, write them now. If items can't be estimated, schedule a refinement conversation and select only ready items.

### Step 2: Define Sprint Goal

Write a single clear sprint goal — one sentence stating what the sprint will achieve. The goal should be:

- Achievable within the sprint duration
- Valuable to stakeholders
- Testable (you can verify it was met at sprint end)

```markdown
**Sprint Goal**: [One sentence describing the objective]
```

Example: "Enable users to reset their password through email verification with two-factor authentication."

**Got:** Sprint goal articulated as one clear, testable sentence.

**If fail:** If no coherent goal emerges, the backlog priorities may be scattered — consult the product owner to focus on a single valuable outcome.

### Step 3: Calculate Team Capacity

Calculate available person-days for each team member:

```markdown
## Team Capacity
| Team Member | Available Days | Overhead (%) | Net Capacity |
|-------------|---------------|-------------|--------------|
| [Name] | [Sprint days - PTO] | 20% | [Available × 0.8] |
| [Name] | [Sprint days - PTO] | 20% | [Available × 0.8] |
| **Total** | | | **[Sum] person-days** |
```

Overhead accounts for meetings, reviews, ad-hoc requests (typically 15-25%).

If using story points: use previous sprint velocity as capacity. If first sprint, use 60-70% of theoretical maximum.

**Got:** Capacity calculated in person-days or story points with documented assumptions.

**If fail:** If no historical velocity exists, be conservative — plan to 60% capacity and adjust after the sprint. Better to under-commit and deliver than over-commit and fail.

### Step 4: Select Items and Compose Sprint Backlog

Select items from the top of the product backlog until capacity is reached. Decompose each selected item into tasks (2-8 hours each):

```markdown
# Sprint Plan: Sprint [N]
## Document ID: SP-[PROJECT]-S[NNN]

### Sprint Details
- **Sprint Goal**: [From Step 2]
- **Duration**: [Start date] to [End date]
- **Capacity**: [From Step 3] person-days / [N] story points
- **Team**: [List team members]

### Sprint Backlog
| ID | Item | Points | Tasks | Assignee | Status |
|----|------|--------|-------|----------|--------|
| B-001 | [Item title] | 5 | 4 | [Name] | To Do |
| B-002 | [Item title] | 3 | 3 | [Name] | To Do |
| B-003 | [Item title] | 8 | 6 | [Name] | To Do |
| **Total** | | **16** | **13** | | |

### Task Breakdown

#### B-001: [Item title]
**Acceptance Criteria**: [From backlog item]

- [ ] Task 1: [Description] (4h, [Assignee])
- [ ] Task 2: [Description] (2h, [Assignee])
- [ ] Task 3: [Description] (4h, [Assignee])
- [ ] Task 4: [Description] (2h, [Assignee])

#### B-002: [Item title]
**Acceptance Criteria**: [From backlog item]

- [ ] Task 1: [Description] (3h, [Assignee])
- [ ] Task 2: [Description] (4h, [Assignee])
- [ ] Task 3: [Description] (2h, [Assignee])

#### B-003: [Item title]
**Acceptance Criteria**: [From backlog item]

- [ ] Task 1: [Description] (3h, [Assignee])
- [ ] Task 2: [Description] (4h, [Assignee])
- [ ] Task 3: [Description] (2h, [Assignee])
- [ ] Task 4: [Description] (3h, [Assignee])
- [ ] Task 5: [Description] (4h, [Assignee])
- [ ] Task 6: [Description] (2h, [Assignee])

### Risks and Dependencies
| Risk | Impact | Mitigation |
|------|--------|-----------|
| [Risk 1] | [Impact] | [Mitigation] |
| [Risk 2] | [Impact] | [Mitigation] |

### Carry-Over from Previous Sprint
| ID | Item | Reason | Remaining Effort |
|----|------|--------|-----------------|
| B-XXX | [Item] | [Reason] | [Hours/points] |
```

**Got:** Sprint backlog with items selected up to capacity, each decomposed into tasks with time estimates.

**If fail:** If total points exceed capacity, remove the lowest-priority item. Never exceed capacity by more than 10%. If dependencies block sequencing, re-order or defer items.

### Step 5: Document Commitments and Save

Write the sprint plan to `SPRINT-PLAN.md` (or `SPRINT-PLAN-S[NNN].md` for archival). Confirm:

- Sprint goal is achievable with selected items
- No team member is overallocated (>100% capacity)
- Dependencies between items are sequenced correctly
- Carry-over items are accounted for in capacity
- All acceptance criteria copied from backlog items

Run a final validation:

```bash
# Check that total task hours align with capacity
grep -A 100 "Task Breakdown" SPRINT-PLAN.md | grep -o '([0-9]*h' | sed 's/[^0-9]//g' | awk '{sum+=$1} END {print "Total hours:", sum}'
```

**Got:** SPRINT-PLAN.md created with complete sprint backlog and task breakdown. Total hours should be ≤80% of available person-days × 8 hours.

**If fail:** If commitments don't align with goal, revisit item selection in Step 4. If task hours exceed capacity, remove the last item or decompose tasks more granularly.

## Validation

- [ ] Sprint goal is one clear, testable sentence
- [ ] Team capacity calculated with documented assumptions (overhead %, PTO accounted)
- [ ] Selected items do not exceed capacity (points or person-days)
- [ ] Every selected item has acceptance criteria copied into task breakdown
- [ ] Every selected item is decomposed into tasks (2-8 hours each)
- [ ] No team member overallocated beyond 100% capacity
- [ ] Carry-over items from previous sprint documented with remaining effort
- [ ] Dependencies between items sequenced correctly
- [ ] Risks and mitigations documented
- [ ] SPRINT-PLAN.md file created and saved

## Pitfalls

- **No sprint goal**: Without a goal, the sprint is just a bag of tasks. The goal provides focus and a basis for scope decisions mid-sprint.
- **Over-commitment**: Planning to 100% capacity ignores interruptions, bugs, and overhead. Plan to 70-80% to leave buffer for the unexpected.
- **Tasks too large**: Tasks over 8 hours hide complexity and make progress tracking difficult. Decompose until tasks are 2-8 hours.
- **Ignoring carry-over**: Unfinished items from the last sprint consume capacity this sprint. Account for them explicitly in capacity calculations.
- **Sprint goal as item list**: "Complete B-001, B-002, B-003" is not a goal. A goal describes the outcome: "Users can reset their password through email verification."
- **No task ownership**: Every task should have an assignee at planning time to surface capacity conflicts early.
- **Skipping acceptance criteria**: Tasks without acceptance criteria can't be tested. Copy acceptance criteria from backlog items into the task breakdown section.

## Related Skills

- `manage-backlog` — maintain and prioritize the product backlog that feeds sprint planning
- `draft-project-charter` — provides project context and initial scope for the first sprint
- `generate-status-report` — report sprint progress and velocity to stakeholders
- `conduct-retrospective` — review sprint execution and improve the planning process
- `create-work-breakdown-structure` — WBS work packages can feed the backlog in hybrid agile-waterfall approaches