Solution

Team Capacity Planning Dev Teams 2026 | Stop Overcommit

5 devs x 80h = 400h? Wrong. 2 on vacation, 1 in meetings. Real capacity: 250h. GitScrum: calculate actual availability, factor PTO, plan to 85%. $8.90/user. 2 free forever. Free trial.

The Overcommitment Problem Common scenario: ├─ Sprint planning: 'We can do 80 points' ├─ Reality: │ ├─ Sarah: 3 days vacation │ ├─ Mike: Jury duty 2 days │ ├─ John: Leading training session │ ├─ Everyone: Team offsite 1 day │ └─ Actual capacity: 50 points ├─ Result: Sprint fails ├─ Team: 'Why do we always fail?

Not wishful thinking. Calculating Real Capacity Capacity formula: ├─ Team: 5 developers ├─ Sprint: 10 working days ├─ Available hours per day: 6 │ └─ (Not 8 - meetings, breaks, etc.) ├─ Gross capacity: 5 x 10 x 6 = 300 hours ├─ Minus: │ ├─ Sarah vacation: -18 hours │ ├─ Mike jury duty: -12 hours │ ├─ Training session: -6 hours │ ├─ Team offsite: -30 hours │ └─ Total deductions: -66 hours ├─ Net capacity: 234 hours ├─ Focus factor (0.8): 187 hours 187 hours available.

Not 300. Focus Factor Why 80%: ├─ Unexpected meetings: 5% ├─ Production issues: 5% ├─ Helping teammates: 5% ├─ Admin tasks: 5% ├─ Actual coding: 80% Adjust based on role: ├─ Junior developer: 70% focus ├─ Senior developer: 75% focus ├─ Tech lead: 50% focus (more meetings) ├─ Architect: 40% focus (more design work) Realistic factors.

Not optimistic. Visibility Into Availability Team calendar view: ├─ Sprint 18 (Dec 1-14) │ ├─ Sarah: Full capacity │ ├─ Mike: Dec 1-3 vacation (-24h) │ ├─ John: Dec 8 training (-8h) │ ├─ Lisa: Full capacity │ └─ Tom: Dec 12 doctor (-4h) │ │ Team capacity: 264 hours │ Historical velocity: ~50 points │ Recommended commitment: 45-50 points Plan with eyes open.

Historical Velocity Past performance: ├─ Sprint 15: 48 points completed ├─ Sprint 16: 52 points completed ├─ Sprint 17: 45 points completed ├─ Average: 48 points/sprint ├─ Variance: +/- 4 points Next sprint planning: ├─ Capacity similar? Commit ~48 ├─ Capacity reduced?

Adjust down ├─ Capacity increased? Cautiously adjust up Velocity is a planning tool.

Not a performance metric. Skill-Based Capacity Not all hours equal: ├─ Frontend tasks: 40 hours estimated ├─ Frontend capacity: │ ├─ Sarah: 30 hours (specialist) │ ├─ Mike: 10 hours (can help) │ └─ Total: 40 hours - OK │ ├─ Backend tasks: 60 hours estimated ├─ Backend capacity: │ ├─ John: 25 hours │ ├─ Lisa: 20 hours │ └─ Total: 45 hours - PROBLEM Capacity by skill matters.

45 backend hours != 60 hours needed. Leave Management Integration Calendar sync: ├─ HR system shows: │ ├─ Approved vacation │ ├─ Sick leave (when reported) │ ├─ Company holidays │ └─ Team events ├─ Capacity auto-calculated ├─ Sprint planning uses real numbers ├─ No surprises mid-sprint Automated deductions.

No manual tracking. Meeting Load Factor Meetings eat capacity: ├─ Team member: 40 hours/week ├─ Recurring meetings: │ ├─ Standup: 2.5 hours/week │ ├─ Sprint ceremonies: 4 hours/sprint │ ├─ Team meetings: 2 hours/week │ └─ 1:1s: 1 hour/week ├─ Ad-hoc meetings: ~3 hours/week ├─ Total meeting load: 10 hours/week ├─ Coding time: 30 hours/week Meetings must be factored.

Otherwise, perpetual overcommitment. Sprint Commitment Process Healthy planning: ├─ Step 1: Calculate capacity │ └─ Real hours, adjusted for PTO/meetings ├─ Step 2: Review velocity │ └─ What have we actually delivered?

├─ Step 3: Pull from backlog │ └─ Until capacity filled ├─ Step 4: Leave buffer │ └─ 10-15% for unknowns ├─ Step 5: Commit │ └─ Team agrees it's achievable Pull to capacity. Not push beyond.

Carry-Over Tracking Watch the pattern: ├─ Sprint 15: 5 tasks carry over ├─ Sprint 16: 4 tasks carry over ├─ Sprint 17: 6 tasks carry over ├─ Average: 5 tasks/sprint ├─ Issue: Systematic overcommitment If carry-over is consistent: ├─ Capacity calculation is wrong ├─ Estimates are optimistic ├─ Scope creep happening ├─ Fix the root cause Carry-over = Feedback signal. Resource Allocation View Who's working on what: ├─ Sarah (40h capacity) │ ├─ Task 1: User auth - 16h │ ├─ Task 2: Profile page - 12h │ ├─ Code reviews: 8h │ └─ Buffer: 4h │ └─ Total: 40h - Balanced │ ├─ Mike (30h capacity - vacation) │ ├─ Task 3: API endpoint - 20h │ ├─ Code reviews: 5h │ └─ Buffer: 5h │ └─ Total: 30h - Balanced Individual balance.

No one overloaded. Buffer Planning Always include buffer: ├─ Sprint capacity: 200 hours ├─ Committed work: 170 hours (85%) ├─ Buffer: 30 hours (15%) Buffer uses: ├─ Unexpected bugs ├─ Production incidents ├─ Scope clarification ├─ Helping teammates ├─ Unplanned meetings No buffer = Guaranteed failure.

Buffer = Flexibility. Capacity vs.

Velocity Different concepts: ├─ Capacity: Hours available to work ├─ Velocity: Points completed per sprint ├─ Relationship: Correlated, not equal Use both: ├─ Capacity: 'We have 200 hours' ├─ Velocity: 'We complete ~50 points' ├─ Ratio: ~4 hours per point ├─ Next sprint: 180 hours available ├─ Expected: ~45 points Capacity sets ceiling. Velocity predicts completion.

Handling Urgent Work Unplanned work happens: ├─ Sprint capacity: 200 hours ├─ Planned work: 170 hours ├─ Buffer: 30 hours ├─ Day 3: Urgent bug takes 20 hours ├─ Result: Buffer absorbs it ├─ Sprint: Still succeeds Without buffer: ├─ Day 3: Urgent bug takes 20 hours ├─ Something gets dropped ├─ Sprint: Fails ├─ Team: Frustrated Buffer is insurance. Long-Term Planning Quarterly view: ├─ Q1 2025 Capacity │ ├─ Sprint 1: 220h (holidays impact) │ ├─ Sprint 2: 280h (full team) │ ├─ Sprint 3: 250h (training week) │ ├─ Sprint 4: 280h (full team) │ ├─ Sprint 5: 200h (team offsite) │ ├─ Sprint 6: 280h (full team) │ └─ Quarter total: ~1500 hours │ └─ Expected: ~375 points Plan features across quarter.

Know what's realistic. Team Growth Planning Capacity changes: ├─ Current: 5 developers, 250h/sprint ├─ New hire joins Sprint 4: │ ├─ Sprint 4: 40% productivity (ramp-up) │ ├─ Sprint 5: 60% productivity │ ├─ Sprint 6: 80% productivity │ └─ Sprint 7+: 100% productivity ├─ Capacity increase gradual │ └─ Not instant +50h Onboarding takes time.

Factor into capacity. Part-Time Team Members Handling contractors/part-time: ├─ Team: │ ├─ Sarah: Full-time (40h) │ ├─ Mike: Full-time (40h) │ ├─ Contractor: 20h/week │ └─ Intern: 15h/week ├─ Total hours: Different from 4 people ├─ Capacity: 40+40+20+15 = 115h/week Count actual hours.

Not headcount. Getting Started 1.

Sync leave calendars 4. Enter known PTO/meetings 5.

See calculated sprint capacity 6. Plan sprints to 85% capacity 7.

Track and adjust over time Plan what's possible. Not what's wished.

The GitScrum Advantage

One unified platform to eliminate context switching and recover productive hours.

problem.identify()

The Problem

Planning ignores reality - 5 developers x 80 hours = 400 hours, right? Wrong. Vacation, PTO, meetings, training not factored.

Systematic overcommitment - Every sprint, team commits too much. Every sprint, carry-over. Pattern repeats. Morale drops.

No visibility into availability - Who's on vacation next sprint? Who has jury duty? Nobody knows until sprint starts.

Meeting load invisible - Developer has 40 hours/week. But 15 hours are meetings. Only 25 hours for coding. Surprise.

Velocity misused - 'We did 50 points last sprint with full team.' Next sprint: 2 people out. Still commit 50 points. Fail.

Skills not balanced - Have 100 hours capacity. Need 60 hours frontend work. Only 30 hours frontend-capable people available. Bottleneck.

solution.implement()

The Solution

Real capacity calculation - Factor in PTO, meetings, training, holidays. Get actual available hours. No surprises mid-sprint.

Calendar integration - Sync with HR/leave systems. See who's out when. Capacity automatically adjusted.

Velocity-based planning - Historical velocity guides commitment. Last 5 sprints averaged 48 points? Commit ~48 points.

Skill-based visibility - See capacity by skill type. Frontend hours, backend hours. Identify bottlenecks before sprint starts.

Buffer built in - Plan to 85% capacity. 15% buffer absorbs unplanned work. Sprints succeed more often.

Focus factor per role - Tech lead at 50% coding time. Junior at 70%. Senior at 75%. Realistic individual capacity.

workflow.steps()

How It Works

Set Team Capacity

Each team member sets available hours per week. Factor in meetings, recurring commitments. Realistic baseline.

Sync Leave Calendar

Import PTO, holidays, training days. System automatically deducts from capacity. No manual tracking needed.

Calculate Sprint Capacity

System shows available hours for sprint. Account for all factors. Clear number to plan against.

Plan to 85%

Commit work up to 85% of capacity. Leave 15% buffer. Sprints succeed. Team morale improves.

expertise.verify()

Why GitScrum

GitScrum addresses Team Capacity Planning Software for Development Teams - Stop Overcommitting Every Sprint through Kanban boards with WIP limits, sprint planning, and workflow visualization

Methodology

Problem resolution based on Kanban Method (David Anderson) for flow optimization and Scrum Guide (Schwaber and Sutherland) for iterative improvement

Capabilities

Kanban boards with WIP limits to prevent overload
Sprint planning with burndown charts for predictable delivery
Workload views for capacity management
Wiki for process documentation
Discussions for async collaboration
Reports for bottleneck identification

Industry Practices

Kanban MethodScrum FrameworkFlow OptimizationContinuous Improvement

features.related()

Related Features

View all features

Sprint Planning

Sprint capacity - See available hours for sprint. Compare to committed work. Plan realistically. Succeed consistently.

Team Management

Individual capacity - Each member's availability visible. PTO, meetings, focus factor. No one overloaded.

Time Tracking

Actual vs. planned - Track time spent. Compare to capacity estimates. Improve accuracy over time.

Kanban Boards

Visual project management that actually fits how {vertical} work. Create unlimited Kanban boards with custom columns—from 'Client Review' to 'Ready to Deploy'—and set WIP limits that prevent the bottlenecks {city} teams know too well. Every card, comment, and status change syncs instantly across devices, so whether your {vertical} team is in the office or remote across {city}, everyone sees the same real-time picture.

Notifications

Not all updates deserve your attention. Customize what triggers notifications—get pinged for client comments but skip internal chatter. Daily digests keep {city} remote teams synced without inbox avalanches. Connect Slack, Discord, or email—wherever your {vertical} team actually checks.

Frequently Asked Questions

Still have questions? Contact us at customer.service@gitscrum.com

What focus factor should we use?

Start with 80% for developers. Adjust based on role: Tech leads at 50% (more meetings), juniors at 70% (learning time), seniors at 75%. Track actual vs. planned over sprints and adjust. Every team is different.

How do we handle unplanned work during sprint?

That's what the 15% buffer is for. Urgent bug? Production issue? Buffer absorbs it. If unplanned work exceeds 15% regularly, track that - either increase buffer or address why so much unplanned work happens.

Should we use hours or story points for capacity?

Use both. Capacity is in hours (concrete, factual). Velocity is in story points (relative complexity). Hours tell you how much time is available. Points tell you how much work that typically represents. They complement each other.

What about part-time team members or contractors?

Count actual hours, not headcount. A half-time contractor is 20 hours, not 40. A part-time employee working 3 days is 24 hours, not 40. Capacity is about available hours, not people count.

Ready to solve this?

Start free, no credit card required. Cancel anytime.