Sprint Planning & Capacity
It is Monday morning at InsightFlow. You have a team of 12 engineers, a prioritised backlog from L10, and a two-week sprint starting today. You open the sprint planning doc and immediately face the question that derails more sprints than any technical challenge: how much can the team actually do?
Not how much could they theoretically do if everything goes perfectly. Not how much they said they would do in the last optimistic planning session. How much can they reliably commit to — given that two engineers are partially allocated this sprint, one is on PTO for 3 days, the on-call rotation will consume roughly a day of the primary's capacity, and recurring meetings eat another few hours per person per week?
Sprint planning is where the prioritised backlog (L10) becomes an executable commitment. Done well, it gives the team clarity, gives stakeholders a reliable forecast, and gives you a clear story to tell in next week's stakeholder update (L12). Done poorly, it creates a sprint that starts on Monday looking achievable and ends on Friday looking like a failure — not because the team underperformed, but because the plan never accounted for reality.
The Capacity Arithmetic
Before you can plan a sprint, you need to know how many engineering-days you actually have — not calendar days, real productive days after all the things that consume time without being tickets.
For InsightFlow's Sprint 1 of the Workflow Builder initiative, here is the capacity picture:
| Person | Raw Days | PTO | On-Call | Meetings/Overhead | Available Days | Story Points (1pt/day) |
|---|---|---|---|---|---|---|
| Sasha (Engineer) | 10 | 0 | 1.5 (on-call primary) | 1 | 7.5 | 7.5 |
| Leo (Engineer) | 10 | 3 | 0 | 1 | 6 | 6 |
| Priya (Engineer) | 10 | 0 | 0 | 1 | 9 | 9 |
| Tamar (Engineer) | 10 | 0 | 0 | 1 | 9 | 9 |
| Dmitri (Engineer) | 10 | 0 | 0.5 (on-call secondary) | 1 | 8.5 | 8.5 |
| Team total | 50 | 3 | 2 | 5 | 40 | 40 pts raw |
Planning capacity (at 75%): 40 × 0.75 = 30 story points
The 70-80% rule is not pessimism — it is engineering reality. Every sprint encounters interrupts that are not in the plan: a production incident, a question from sales that needs a quick spike, a dependency that turns out to be harder than expected. If you plan to 100% of capacity, those interrupts guarantee misses. If you plan to 75%, they are absorbed.
Teams that consistently plan to 80% capacity and deliver reliably are trusted. Teams that plan to 100% and miss are not — even if they did the same amount of work. Reliability is a product quality. Plan for it.
The Sprint Goal
Before you touch the backlog, write the sprint goal. One sentence. What does a successful sprint look like?
Wrong: "Complete the workflow builder stories, fix the regression from last sprint, handle the auth dependency, and improve dashboard load time."
Right: "Ship the first working version of the Workflow Builder trigger configuration UI so that design can begin user testing."
The difference is scope. The wrong version describes everything the team might do. The right version describes the ONE outcome that defines success. When something unexpected consumes capacity mid-sprint — and it will — the sprint goal tells the team what to protect. Everything else is negotiable.
The sprint is unfocused. Go back to the prioritised backlog and ask: what is the single most important thing the team could ship this sprint? That is your sprint goal. The other items are support work, not goals.
The /sprint-planning Command
The /sprint-planning command from the official product-management plugin generates a complete sprint plan — capacity table, prioritised backlog, risk table, definition of done, and key dates — from the inputs you provide.
What it needs:
- Team members and their availability (PTO, on-call, meetings)
- Sprint length and dates
- The prioritised backlog (from L10 — P0/P1/P2 items)
- Carryover from previous sprints (if any)
- Known dependencies or blocked items
What it produces:
## Sprint Plan: [Sprint Name]
**Dates:** [Start] — [End] | **Team:** [X] engineers
**Sprint Goal:** [One clear sentence]
### Capacity
| Person | Available Days | Allocation | Notes |
|--------|---------------|------------|-------|
### Sprint Backlog
| Priority | Item | Estimate | Owner | Dependencies |
|----------|------|----------|-------|--------------|
| P0 | [Must ship] | [X] pts | [Person] | None |
| P1 | [Should ship] | [X] pts | [Person] | None |
| P2 | [Stretch] | [X] pts | [Person] | None |
### Planned Capacity: [X] pts | Sprint Load: [X] pts ([X]% of capacity)
### Risks
| Risk | Impact | Mitigation |
### Definition of Done
- [ ] Code reviewed and merged
- [ ] Tests passing
- [ ] Documentation updated
- [ ] Product sign-off
### Key Dates
| Date | Event |
Worked Example: Sprint 1, Workflow Builder
Here is the sprint planning invocation for InsightFlow Sprint 1, drawing from the prioritised backlog produced in L10:
/sprint-planning Sprint 1 — Workflow Builder
Team (2-week sprint, starts 2026-03-23):
- Sasha: available 7.5 days (on-call primary this sprint)
- Leo: available 6 days (3 days PTO, returns Thursday week 2)
- Priya: available 9 days
- Tamar: available 9 days
- Dmitri: available 8.5 days (on-call secondary this sprint)
Total: 40 raw days → 30 points planning capacity at 75%
Carryover from Sprint 0 (pre-sprint):
- WF-001: Auth service integration design document (8 pts) —
CARRIED OVER. Was blocked by platform team dependency.
Dependency now resolved. Re-committing this sprint.
- WF-002: Trigger configuration data model (5 pts) — NEW, not started
Top backlog items (RICE-scored from L10):
1. WF-001: Auth integration document — 8 pts (P0)
2. WF-002: Trigger config data model — 5 pts (P0)
3. WF-003: Trigger UI — basic configuration form — 8 pts (P0)
4. WF-004: Workflow step connector — first-party integrations — 8 pts (P1)
5. WF-005: Error state handling and retry logic — 5 pts (P1)
6. WF-006: Dashboard load time optimisation — 3 pts (P1, tech debt)
7. WF-007: Admin audit log — initial implementation — 8 pts (P2, stretch)
Sprint goal: Ship WF-001 through WF-003 so that the trigger
configuration UI is testable by design by end of sprint.
Sample output from /sprint-planning:
Sprint Plan: Workflow Builder Sprint 1
Dates: 2026-03-23 — 2026-04-03 | Team: 5 engineers
Sprint Goal: Ship the trigger configuration UI (WF-001 through WF-003)
so that design can begin user testing by sprint end.
Capacity
| Person | Available Days | Points | Notes |
|---------|---------------|--------|---------------------------|
| Sasha | 7.5 | 7.5 | On-call primary this sprint |
| Leo | 6.0 | 6.0 | PTO: Thu–Sat week 1 |
| Priya | 9.0 | 9.0 | — |
| Tamar | 9.0 | 9.0 | — |
| Dmitri | 8.5 | 8.5 | On-call secondary |
| Total | 40.0 | 40.0 | Planning cap: 30 pts (75%) |
Sprint Backlog
| Priority | Item | Est | Owner | Dependencies |
|----------|-----------------------------------------|------|--------|--------------------|
| P0 | WF-001: Auth integration doc | 8 pt | Sasha | Platform team: done |
| P0 | WF-002: Trigger config data model | 5 pt | Priya | WF-001 |
| P0 | WF-003: Trigger UI — config form | 8 pt | Tamar | WF-002 |
| P1 | WF-005: Error handling & retry | 5 pt | Leo | WF-003 |
| P1 | WF-006: Dashboard load optimisation | 3 pt | Dmitri | None |
| **Total P0+P1** | |**29 pt** | | 97% of capacity ⚠️ |
Stretch (do not commit)
| P2 | WF-004: Step connector — first-party | 8 pt | — | WF-003 |
| P2 | WF-007: Admin audit log | 8 pt | — | None |
Sprint Load: 29 pts / 30 pts capacity = 97% ← REVIEW NEEDED
Risks
| Risk | Impact | Mitigation |
|------|--------|------------|
| Leo PTO during week 1 critical path | WF-005 may slip | Front-load non-Leo items; review mid-sprint |
| WF-003 unblocked only after WF-002 | UI start delayed | Tamar to prepare component architecture while WF-002 is in progress |
Definition of Done
- [ ] Code reviewed and merged to main
- [ ] Tests passing (unit + integration)
- [ ] Design approval on WF-003 trigger UI
- [ ] Product sign-off on WF-001 auth design document
Key Dates
| Date | Event |
|------------|--------------------------------|
| 2026-03-23 | Sprint start / planning complete |
| 2026-03-27 | Mid-sprint check-in |
| 2026-04-02 | Code freeze |
| 2026-04-03 | Sprint demo / retro |
Evaluating the Output
The agent flagged a problem: the sprint is loaded at 97% of capacity. That is too high. You have three options:
- Cut WF-006 (dashboard load, 3 pts) → brings load to 26/30 = 87%. Better, but the tech debt was deliberately prioritised in L10. Document the trade-off.
- Move WF-005 (error handling, 5 pts) to stretch → brings P0-only load to 21/30 = 70%. Clean, but error handling is needed for Sprint 2 testing. Risk is you create a P0 blocker in Sprint 2.
- Accept 97% and flag it → only defensible if Leo is back from PTO before WF-005 is scoped. Check the dependency chain.
The right answer depends on context the agent does not have. This is where your judgment comes in. The agent surfaces the problem. You make the call.
The sprint plan you produce in this exercise feeds directly into Lesson 12, where you will draft three versions of a stakeholder update about Sprint 1's status — and into Lesson 14, where the Stakeholder Update Agent automates that communication pattern.
Try With AI
Use these prompts in Cowork or your preferred AI assistant.
Prompt 1 — Reproduce (apply what you just learned):
Plan a 2-week sprint for InsightFlow using this team and backlog:
Team availability:
- 4 engineers, 10 days each raw
- Engineer A: 2 days PTO
- Engineer B: on-call primary (deduct 1.5 days)
- Engineers C and D: fully available
- All engineers: 1 day meetings overhead
- Planning capacity: 75% of available days
Top backlog items (from L10 RICE scoring):
1. WF-003: Trigger UI — config form (8 pts, P0)
2. WF-004: Workflow step connector (8 pts, P1)
3. WF-005: Error handling and retry (5 pts, P1)
4. Dashboard load optimisation (3 pts, P1)
5. Admin audit log initial implementation (8 pts, P2, stretch)
Sprint goal: Ship the trigger config UI so design can start user testing.
What you're learning: Practising the full /sprint-planning workflow — building the capacity table, confirming load against capacity, and verifying the sprint goal is singular and testable.
Prompt 2 — Adapt (change the context):
Plan a sprint for a different B2B SaaS team with this profile:
- 3 engineers, 2-week sprint
- No PTO this sprint
- 1 engineer is on-call primary (subtract 2 days for primary oncall load)
- All engineers: 1 day of recurring meetings overhead
Backlog:
- Feature A: user role management (13 pts, P0)
- Feature B: audit log CSV export (8 pts, P1)
- Feature C: webhook outbound notifications (8 pts, P1)
- Feature D: advanced search filters (5 pts, P2, stretch)
Sprint goal: Ship user role management to unblock the enterprise pilot.
Check: is the sprint within 70-80% of planning capacity?
If not, which item do you move to stretch first?
What you're learning: Applying capacity arithmetic in a different product context. The question about what to cut first tests whether you understand P0/P1/P2 priority tiers versus mere backlog order.
Prompt 3 — Apply (connect to your domain):
Plan a sprint for your own team's current or next sprint.
Provide:
1. Your team members and their real availability this sprint
(subtract PTO, on-call, meetings)
2. Your sprint's top 5-7 backlog items with rough estimates
3. Any carryover items from last sprint (and why they carried over)
4. Your sprint goal in one sentence
Then check: is the planned load within 70-80% of capacity?
If not, identify the first item to cut or move to stretch — and
explain the trade-off to your engineering lead in two sentences.
What you're learning: The transfer moment — applying sprint planning principles to real work. The engineering lead explanation exercises the communication skill you will build in L12.
Exercise: Plan InsightFlow Sprint 1
Plugin: Official product-management
Command: /sprint-planning
Time: 20 minutes
Step 1 — Build the capacity table
Before running the command, build the capacity table by hand. For InsightFlow Sprint 1:
- 5 engineers, 10 raw days each (2-week sprint)
- Sasha: on-call primary this sprint (subtract 1.5 days)
- Leo: 3 days PTO in week 1 (subtract 3 days)
- Priya, Tamar, Dmitri: fully available
- All engineers: 1 day recurring meetings overhead
- 2 carryover stories from Sprint 0: WF-001 (8 pts) and the new WF-002 (5 pts)
Calculate: raw available days → subtract overhead → multiply by 0.75 → planning capacity in story points.
Step 2 — Run /sprint-planning
/sprint-planning Sprint 1 — Workflow Builder
Sprint dates: 2026-03-23 to 2026-04-03 (2 weeks)
Sprint goal: Ship the trigger configuration UI so design can start
user testing by sprint end.
Team:
- Sasha: 7.5 days available (on-call primary)
- Leo: 6 days available (3 days PTO)
- Priya: 9 days available
- Tamar: 9 days available
- Dmitri: 8.5 days available (on-call secondary)
Planning capacity: 30 points (75% of 40 raw days)
Carryover (2 items from Sprint 0):
- WF-001: Auth service integration design (8 pts) — was blocked,
now unblocked (platform team dependency resolved)
- WF-002: Trigger configuration data model (5 pts) — net new
New backlog items to consider:
- WF-003: Trigger UI basic config form (8 pts, P0)
- WF-005: Error handling and retry (5 pts, P1)
- WF-006: Dashboard load optimisation (3 pts, P1)
- WF-004: Workflow step connector (8 pts, P2, stretch)
Step 3 — Evaluate the output
Check these criteria:
- Is the sprint goal singular? Can you state what "done" looks like in one sentence?
- Is the planned load within 70-80% of capacity? (Red flag: >85%)
- Are all P0 items covered? Are they sequenced correctly (dependencies in order)?
- Is there a risk for Leo's PTO impact on the critical path?
- Are stretch items clearly labelled (do not commit)?
Step 4 — Refine if overloaded
If the sprint is loaded above 85%, decide which item to cut first. Apply this rule: cut the lowest-priority item that does not block anything else in the sprint. Move it to stretch, not the next sprint — it might fit if the sprint runs well.
Send the updated sprint plan to your engineering lead (simulated):
Review my sprint plan for Sprint 1. The original load was [X]%.
I cut [item] to bring it to [Y]%. Here is my rationale for
that cut vs cutting [alternative item]:
[your two-sentence rationale]
Does this match your read of the team's capacity?
Step 5 — Document your sprint plan
Save your final sprint plan document in your working folder. It is the input to L12's stakeholder update — your stakeholder update will report on this sprint's progress.
What You Built
You produced a sprint plan — a capacity-calibrated commitment for InsightFlow Sprint 1 of the Workflow Builder initiative. The plan includes a singular sprint goal, a capacity table with individual overhead deductions, a P0/P1/P2 prioritised backlog within 70-80% of available capacity, a risk table covering the key uncertainties (Leo's PTO, the dependency chain), and a definition of done.
You also practised the judgment call that every sprint plan requires: when the agent flags an overloaded sprint, you decided what to cut and why — which is a skill no command can make for you.
The sprint plan feeds directly into Lesson 12, where you will use /stakeholder-update to draft three audience-calibrated versions of your Sprint 1 status update.
Flashcards Study Aid
Continue to Lesson 12: Stakeholder Communication →