Sprint Planning Template for Kanban Teams
Kanban teams reject sprint boundaries in favor of continuous flow — work is pulled through the board as capacity becomes available rather than committed at the start of a time-box. This creates a fundamentally different planning model: instead of "what do we commit to this sprint?", the questions are "is the board healthy?", "where are the bottlenecks?", and "what does the data say about how long this work will take?"
This template provides the structure for weekly or biweekly Kanban planning sessions. It covers board replenishment (keeping the Ready queue filled without over-committing), WIP limit enforcement (the mechanism that exposes bottlenecks and prevents multitasking), cycle time analysis (the metric that predicts delivery dates), and throughput forecasting (the tool for project-level delivery estimation). It works for product engineering teams, design teams, and support teams that use Kanban over scrum.
Why Kanban planning is different from sprint planning — and what to do instead
The most common failure mode for Kanban teams is treating the board as a to-do list rather than a flow management tool. Without WIP limits enforced, work accumulates in every column, cycle times balloon, and the board becomes a status dashboard rather than a flow system. The planning meeting becomes a status meeting. Nothing gets delivered faster.
WIP limits are the core mechanism that makes Kanban work. When a column is at its WIP limit, engineers cannot pull new work into that column — they must help unblock the work that is already in progress. This creates a "stop starting, start finishing" culture that is counterintuitive but dramatically more efficient than the default behavior of starting new things when you are blocked on existing things.
Kanban teams also have a different relationship with estimation. Sprint teams estimate story points to fill a sprint capacity. Kanban teams do not need to estimate — they use historical cycle time data to forecast when work will be delivered. If your median cycle time for a story is 4 days with a 90th percentile of 12 days, you can make probabilistic commitments ("90% confidence this will be done within 12 days of starting") without the estimation theater that sprint planning requires.
Template sections
4 sections covering the complete sprint planning workflow.
Board replenishment (weekly)
The board replenishment cadence determines how work flows from the backlog into the Ready column. Replenish weekly (or as needed when Ready becomes empty) by pulling from the prioritized backlog. The Ready column is a buffer — it should contain 1–2 weeks of work at the team's current throughput rate. Over-filling creates false commitment; under-filling creates idle time.
Board replenishment — Week of March 10: Ready column status before replenishment: - Current items: 3 (target: 6–8 for the team's throughput) - Items that left Ready this week: 4 were pulled into In Progress - Target replenishment: 4–5 items to bring Ready to 7–8 Items pulled from backlog (in priority order): 1. [Story title] — Estimated complexity: Small — Business priority: P0 2. [Story title] — Estimated complexity: Medium — Business priority: P0 3. [Story title] — Estimated complexity: Small — Business priority: P1 4. [Story title] — Estimated complexity: Large — Business priority: P1 (split before pulling: see T-89a and T-89b) Items NOT pulled (deferred reasons): - T-92: Waiting on design — cannot start until design review is complete. Blocked flag added.
Tips
- Set a target Ready column size based on 1–2 weeks of throughput, not a fixed number — the target changes as team velocity changes
- Only pull items where all dependencies are met and the item is actually ready to start — a "ready" item that is blocked on a dependency the moment it is started is noise, not capacity
- Large stories should be split before they enter Ready — the Kanban board works best with items that can be completed in 2–4 days
WIP limit enforcement and bottleneck detection
WIP limits are the single most important Kanban control mechanism. When a column reaches its WIP limit, no new work can enter that column until work exits. This forces the team to address bottlenecks rather than pile more work on top of them. Review WIP limit utilization at every planning session.
WIP limit review — Week of March 10: | Column | WIP Limit | Current | Status | Action | |---|---|---|---|---| | Ready | 8 | 7 | Healthy | None | | In Progress | 4 | 4 | AT LIMIT | [See bottleneck analysis] | | In Review | 3 | 3 | AT LIMIT | 2 PRs have been waiting >3 days | | QA/Testing | 2 | 1 | Healthy | None | Bottleneck identified: Both In Progress and In Review are at limit simultaneously. New work cannot enter In Progress. Two PRs in In Review have been waiting for review for >3 days. Bottleneck action: Code review is the bottleneck. In today's standup, the team will identify 2 engineers to context-switch to reviewing PRs. No new stories should be started until the review backlog clears.
Tips
- A column that is consistently at its WIP limit is a bottleneck — the fix is to address the bottleneck process, not to raise the WIP limit
- WIP limits should be set slightly lower than you think is comfortable — the discomfort of hitting the limit is the signal that reveals the process problem
- Track WIP limit violations (items pulled above the limit) — a team that routinely violates WIP limits has not bought into the Kanban model and needs a process conversation, not more data
Cycle time analysis and delivery forecasting
Cycle time is the time from "In Progress" start to "Done" — the key metric for delivery predictability. Track cycle time per item, calculate the median and the 85th/95th percentile distributions, and use them to make probabilistic delivery commitments. Cycle time data eliminates estimation while providing more accurate forecasts.
Cycle time data — last 30 days (42 completed items): | Metric | All items | Small items | Medium items | Large items | |---|---|---|---|---| | Median | 3.2 days | 1.8 days | 3.5 days | 6.8 days | | 85th percentile | 7.1 days | 3.2 days | 7.4 days | 14.2 days | | 95th percentile | 12.3 days | 5.1 days | 11.8 days | 21.4 days | Forecast for a 15-item project: - 50% confidence: 15 × 3.2 = 48 days / throughput rate (6 items/week) = 8 weeks - 85% confidence: 15 × 7.1 = 106.5 days / throughput rate = 17.75 weeks → round up: 18 weeks Conclusion: "We are 85% confident this project will be complete in 18 weeks from today" — this is a more honest commitment than a sprint-based estimate that assumes everything goes to plan.
Tips
- Cycle time outliers (items above the 95th percentile) almost always indicate a specific blocker or scope issue — investigate each one rather than averaging them away
- Separate cycle time by item size or type if your work is heterogeneous — lumping large architectural stories with small bug fixes creates a misleading distribution
- Use Monte Carlo simulation (easily done in a spreadsheet) to generate more accurate project-level forecasts than simple throughput multiplication
Throughput tracking and team health
Throughput (items completed per week) is the Kanban equivalent of velocity. Track it weekly and look for trends: consistent throughput indicates a healthy system; declining throughput indicates a growing bottleneck or increasing WIP. Weekly throughput variation is normal; multi-week trends require investigation.
Throughput trend — last 8 weeks: | Week | Throughput | WIP limit violations | Notable events | |---|---|---|---| | Feb 10 | 7 | 0 | — | | Feb 17 | 8 | 0 | — | | Feb 24 | 5 | 2 | Two engineers on-call escalations | | Mar 3 | 4 | 3 | Large refactoring story blocked review queue | | Mar 10 | 6 | 1 | — | Analysis: The Mar 3 decline correlates with a large story blocking the review queue (the In Review bottleneck from the WIP section). WIP limit violations increased as engineers tried to compensate by starting new work instead of resolving the review backlog. Action: Implement a large story policy — any story estimated >5 days must be split before entering the board.
Tips
- Plot throughput as a control chart (with upper and lower control limits at ±3 standard deviations) — points outside the control limits represent special causes, not random variation
- Do not use average throughput for commitments — use the lower tail (85th percentile slowest week) for conservative commitments and the median for expected delivery dates
- Throughput includes quality: a story that is "done" but fails QA next week is not actually done. Count only truly done items (passed QA, deployed to production) in throughput.
Copy-paste template
# Kanban Planning — Week of [Date] Facilitator: [Name] | Duration: 30 minutes --- ## Board Status | Column | WIP Limit | Current | Status | Action required? | |---|---|---|---|---| | Ready | [8] | [X] | [Healthy / Low / At limit] | [None / Replenish / See below] | | In Progress | [4] | [X] | [Healthy / At limit] | [None / Bottleneck — see below] | | In Review | [3] | [X] | [Healthy / At limit] | [None / Code review backlog] | | QA / Testing | [2] | [X] | [Healthy / At limit] | [None] | **Bottlenecks identified:** [Column name and root cause — or "None"] **Bottleneck action:** [Specific action this week to clear the bottleneck] --- ## Board Replenishment **Items that left Ready this week:** [N items pulled into In Progress] **Target Ready size:** [N — based on 1–2 weeks of throughput] **Items to pull from backlog:** [N items needed to reach target] Items pulled into Ready: | Story | Size | Priority | Dependencies clear? | |---|---|---|---| | [Story title] | Small | P0 | Yes | | [Story title] | Medium | P1 | Yes | Items NOT pulled (with reason): | Story | Reason for deferral | |---|---| | [Story title] | Waiting on design review — blocked | --- ## Cycle Time (Last 30 Days) | Metric | All items | Small | Medium | Large | |---|---|---|---|---| | Items completed | [N] | [N] | [N] | [N] | | Median cycle time | [X] days | [X] days | [X] days | [X] days | | 85th percentile | [X] days | [X] days | [X] days | [X] days | | Outliers (>2×median) | [N items — link to investigation] | | | | **Delivery forecast for [project/epic]:** - Remaining items: [N] - 50% confidence: [N weeks] (median cycle time × items / throughput) - 85% confidence: [N weeks] (85th percentile) --- ## Throughput Trend (Last 6 Weeks) | Week | Throughput | WIP violations | Notes | |---|---|---|---| | [Week] | [N items] | [N] | [Notable events] | **Trend:** [Stable / Improving / Declining — and why] **Action if declining:** [Specific investigation or process change] --- ## This Week's Actions - [ ] [Action to address bottleneck] — Owner: [Name] - [ ] [Board replenishment complete] — Owner: [PM] - [ ] [Process improvement from this session] — Owner: [Name] — Due: [Date]
Frequently asked questions
Generate instead of filling in templates
Connect your tools, and Vantage generates the content using real product data. Free to start.
Free to start. No credit card required.