Template Overview

Sprint planning meetings set the execution cadence for software engineering teams. When planning lacks discipline—overestimating capacity, accepting poorly scoped user stories, or failing to agree on a singular sprint goal—teams end up demoralized by repeated sprint rollovers and missed delivery commitments.

A structured Sprint Planning Brief ensures that engineering capacity is realistically calibrated against planned time-off and support rotations before user stories are committed.

This template provides an agile planning layout: team velocity baselines, capacity calculations, refined user story commitments with point estimates, and explicit out-of-scope boundaries.

Markdown Template Structure

Copy the block below or click Download .md File to add this template directly to your personal vault:

---
title: "Sprint Planning Brief: [Sprint Number / Name]"
date: [YYYY-MM-DD]
sprint_number: 25
sprint_duration: "2 Weeks ([YYYY-MM-DD] to [YYYY-MM-DD])"
scrum_master: "[[Agile Coach / Lead]]"
product_owner: "[[Product Manager Name]]"
target_velocity_points: 55
committed_points: 52
tags: [sprint, agile, planning, engineering, backlog]
---

# Sprint Planning Brief: [Sprint Number / Name] — [YYYY-MM-DD]

## 1. Unifying Sprint Goal
> [!IMPORTANT] Core Sprint Commitment
> Complete the Markdown Template Gallery release: deploy 120 validated templates across 12 categories, achieve 100% SEO gate validation, and push to production with zero regressions.

## 2. Team Capacity & Availability Calibration
- **Total Engineers:** 4 full-time systems engineers.
- **Time-Off Deductions:** [[Engineer B]] on PTO for 2 days (-8 points).
- **On-Call Support Tax:** [[Engineer A]] dedicated to primary on-call rotation (-10 points).
- **Net Available Capacity:** 52 story points.

## 3. Committed User Story Backlog
| Story ID | Story Title / Scope | Lead Owner | Story Points | PRD / RFC Reference | Status |
| :--- | :--- | :--- | :--- | :--- | :--- |
| CORE-101 | Implement client-side template download and copy buttons | [[Alex Rivera]] | 5 pts | [[PRD-Templates-Gallery]] | Committed |
| CORE-102 | Build automated 8-gram shingle uniqueness verification | [[Sophia Wu]] | 8 pts | [[RFC-SEO-Gates]] | Committed |
| CORE-103 | Author Batch 1 templates for meetings, 1-on-1s, and retros | [[Content Lead]] | 13 pts | [[Spec-Template-Catalog]] | Committed |
| CORE-104 | Finalize Cloudflare Worker routing and edge asset caching | [[Elena Rostova]] | 8 pts | [[Architecture-Edge-Deploy]] | Committed |
| CORE-105 | Resolve CoreAudio buffer edge cases under system throttling | [[Alex Rivera]] | 13 pts | [[RFC-Audio-Pipeline]] | Committed |
| **Total** | | | **47 pts** | | **Buffer: 5 pts** |

## 4. Explicit Out-of-Scope Scope Boundaries
- *Do not begin work on:* Multi-vault automatic file watching (deferred to Sprint 26).
- *Do not begin work on:* Windows / Linux binary compilation targets.

## 5. Definition of Done (DoD) Checklist
- [ ] Code committed to main with >80% automated unit test coverage.
- [ ] Passed all 24 automated SEO gates via `pnpm gates`.
- [ ] Tested and verified on physical Apple Silicon hardware (M1, M2, and M3).
- [ ] Documentation updated in repository and linked in internal vault.

Filled Real-World Example

Here is a realistic example demonstrating how this template captures actual deliberations:

---
title: "Sprint Planning: Sprint 25 Kickoff"
date: 2026-10-09
sprint_number: 25
committed_points: 48
tags: [sprint, agile, planning]
---

# Sprint Planning: Sprint 25 Kickoff — October 9, 2026

## 1. Sprint Commitment
Ship the complete 120-template gallery with all 12 categories passing SEO Gate 13 uniqueness floors.

## 2. Stories Committed
- Author remaining template batches 2 through 4.
- Verify production deployment on Cloudflare Workers edge.
- Submit all 405 canonical URLs to IndexNow.

## 3. Capacity
Net capacity: 50 points. Total committed: 48 points.

When to Use and When to Avoid

When to Use

  • Use at the beginning of each two-week agile sprint planning cycle.
  • Use to establish a shared sprint goal and calculate realistic engineering capacity.
  • Use to define explicit scope boundaries and prevent mid-sprint scope creep.

When to Avoid

  • Avoid using for daily quick blocker updates (use [[daily-asynchronous-standup]]).
  • Avoid using for retrospective post-sprint evaluations (use [[blameless-sprint-retrospective]]).

On-Device AI Integration

Generate structured sprint planning records with Oyma:

Analyze the sprint planning meeting transcript:
1. Identify the single unifying sprint goal agreed upon by product and engineering.
2. Calculate net engineering capacity accounting for vacations and on-call rotations.
3. Tabulate all committed user stories with story point estimations, owners, and specs.
4. Record items explicitly designated as out of scope for the upcoming sprint.
Output in clean, disciplined CommonMark.

Your team’s sprint backlogs and velocity estimates remain entirely private on your Mac.

Frequently Asked Questions

How does this sprint planning template calculate true team capacity?

The template factors in developer time-off, on-call support duties, and architectural overhead rather than assuming 100% engineering capacity.

Why is an explicit Sprint Goal required?

A sprint without a single unifying goal becomes a disjointed grab-bag of random tickets. The sprint goal provides alignment when trade-offs arise midway through the iteration.

Can user stories be linked to PRDs?

Yes. Each story in the commitment table includes wikilinks to relevant Product Requirement Documents (PRDs) and engineering RFCs.