A Practical Method (Without Fake Precision)
Capacity planning is not about predicting the future perfectly. It is about avoiding a predictable failure: pulling more work than the team can finish to Definition of Done.
This guide gives you a simple, vendor-neutral method to estimate capacity without turning Scrum into micromanagement.
Who this is for: Scrum Masters, Developers, QA, Product Owners
Use this when: sprints frequently spill over, planning feels like guessing, or teams argue about “how much to take”
Examples are illustrative and do not represent complete project solutions.
What “capacity” means (simple definition)
Capacity = the team’s available time/energy to deliver Done work during the sprint, after you account for:
- leave/holidays/on-call
- recurring meetings
- support work and unplanned interruptions
- DoD activities (testing, review, integration, demo prep)
Capacity is a limit, not a performance promise.
Step-by-step capacity planning (the method)
Use this 5-step method every sprint. It is fast and repeatable.
Step 1: Confirm sprint length and working days
- Sprint duration (e.g., 10 working days for a 2-week sprint)
- Remove holidays (if applicable)
Step 2: Count team members who deliver sprint work
Include: Developers, QA, UX (if they deliver sprint work)
Exclude: PO (typically), Scrum Master (unless they deliver sprint work)
Step 3: Reduce known unavailability (per person)
For each team member, reduce:
- planned leave
- on-call / production support blocks
- training days
Step 4: Reduce fixed overhead (meetings + BAU)
Subtract time for:
- ceremonies (planning, daily, review, retro)
- refinement timebox
- recurring organization meetings
- BAU support (tickets, triage)
Step 5: Apply a buffer (mandatory)
Keep a buffer for uncertainty and DoD work:
- Beginner-friendly rule: keep 10–20% buffer each sprint
- If reliability is poor / support load is high: keep 20–30% buffer
Worked example (vendor-neutral)
Imagine a 2-week sprint with 10 working days. The delivery team is 5 people (Dev + QA).
Nominal work hours per person: 6 hours/day (after lunch/admin), so 60 hours/person/sprint
Total nominal: 5 × 60 = 300 hours
Now subtract known unavailability:
Person A leave: 1 day → −6 hours
Person B on-call: 2 half-days → −6 hours
Team total unavailability: −12 hours → 288 hours
Now subtract fixed overhead (timeboxed):
Sprint Planning: 2 hours × 5 = −10
Daily Scrum: 0.25 hr/day × 10 days × 5 = −12.5
Review + Retro: 1.5 hours × 5 = −7.5
Refinement: 1 hour/week × 2 weeks × 5 = −10
Overhead total: −40 hours → 248 hours
Reserve BAU/support:
8% support block: 248 × 0.08 = ~20 hours → 228 hours
Apply buffer (15%):
228 × 0.15 = ~34 hours buffer
Final plannable capacity: ~194 hours
Rule: stop selecting sprint work when you reach ~190–200 hours worth of Done work, not “started work”.
A practical calculation (hours-based)
This is the cleanest “starter method”:
Capacity (hours) = Sum of (Available work hours per person) exclude Overheads exclude Buffer
Where teams go wrong (and how to fix it)
Mistake 1: Planning to 100% capacity
Fix: stop selecting work at ~80–90% of capacity to protect DoD and uncertainty.
Mistake 2: Forgetting BAU/support work
Fix: explicitly reserve a support block (even 5–10% of the sprint).
Mistake 3: Counting “available hours” but ignoring DoD effort
Fix: DoD is real work. Testing, review, integration, demo prep must fit inside capacity.
Mistake 4: Treating the plan as a commitment
Fix: it’s a forecast. Use the Sprint Goal to trade scope when reality changes.
Capacity & Sprint Goal (how to select work correctly)
Use this sequence:
- Agree Sprint Goal
- Calculate rough capacity
- Pull the smallest set of items that supports the goal
- Stop at 80–90% of capacity
- Keep the buffer visible (do not “spend” it during planning)
Mini checklist you can paste into Sprint Planning
Capacity Planning Quick Checklist
- Sprint days confirmed (holidays removed)
- Team members included/excluded correctly
- Leave/on-call captured per person
- Ceremonies and refinement timeboxed and accounted
- BAU/support reserved
- Buffer (10–20%) applied
- Work selection stops at ~80–90% of plannable capacity
FAQ
Should we plan capacity in hours or points?
Either can work. For beginners, hours can help expose meetings/support reality. For mature teams, points with stable velocity is often simpler. Avoid rigid hour-to-point conversions.
What buffer should we keep?
Start with 10–20%. Increase buffer if you have frequent incidents, unstable work, or heavy dependencies.
What if leadership demands full utilization?
Use outcome language: “We plan to deliver Done work reliably. Planning at 100% produces spillover, rework, and lower predictability.”
Next steps
Recommended reading: