Jan 25, 2025

Engineering Velocity & Capacity Calculator

Stop guessing at sprint capacity. Use real data and proven formulas to plan realistic sprints, track velocity trends, and build predictable delivery schedules. Free calculator and templates included.

Why Velocity Tracking Matters for Dev Teams

The Sprint Planning Problem:

It's Monday morning. Sprint planning meeting. Your PM asks: "How many story points can we commit to this sprint?"

Without velocity data, you guess:

"Maybe 40 points? We did that last time..."
"John's on vacation, so probably less..."
"We have that production incident to handle..."
"Let's say 35 points to be safe?"

Two weeks later:

You completed 28 points (20% under commitment)
Stakeholders are frustrated with "slow progress"
Team feels bad about "underperforming"
Next sprint planning: same guessing game

The Real Problem: You're planning based on feelings, not data.

The Solution: Calculate and track engineering velocity.

⚠️ INTERACTIVE VELOCITY CALCULATOR

[PLACEHOLDER FOR INTERACTIVE CALCULATOR]

This section will contain an interactive JavaScript calculator with the following features:

Calculator Features:

Input Fields:

Team Size - Number of developers on the team
Sprint Length - Days in sprint (typically 10-14 days)
Hours Per Day - Working hours per developer per day
Meeting Time - Daily standup + planning + retro (hours/day)
Historical Velocity - Average story points completed in last 3-5 sprints
Story Point to Hour Ratio - Your team's average hours per story point

Calculations:

Gross Capacity = Team Size × Sprint Days × Hours/Day
Meeting Overhead = Meeting Hours × Sprint Days × Team Size
Net Capacity = Gross - Meetings - Buffer (20%)
Suggested Sprint Commitment = Based on historical velocity
Velocity Trend = Last 5 sprints with trend line
Capacity Per Developer = Individual allocation

Output Displays:

Sprint capacity in hours
Recommended story point commitment
Buffer allocation for unexpected work
Individual developer capacity
Velocity trend chart
Comparison to team benchmark

Export Options:

Download as PDF
Export to CSV
Save to Corcava project

Understanding Engineering Velocity

What is Velocity?

Velocity Definition: Velocity is the average amount of work a development team completes during a sprint, typically measured in story points or hours.

Key Concepts:

Story Points:

Relative measure of complexity and effort
Not time estimates (intentionally abstract)
Team-specific calibration
Typically use Fibonacci sequence (1, 2, 3, 5, 8, 13, 21)

Velocity:

Average story points completed per sprint
Based on last 3-5 sprints for accuracy
Team-specific (can't compare across teams)
Improves with team stability

Capacity:

Available working hours in a sprint
Accounts for meetings, overhead, buffer
Used to validate velocity commitments
Helps identify overcommitment

The Velocity Formula

Basic Velocity Calculation:

Velocity = Sum of story points completed in last N sprints ÷ N

Example:
Sprint 1: 42 points
Sprint 2: 38 points
Sprint 3: 45 points
Sprint 4: 40 points
Sprint 5: 43 points

Velocity = (42 + 38 + 45 + 40 + 43) ÷ 5 = 41.6 points/sprint

Capacity Calculation:

Gross Capacity = Team Size × Sprint Days × Hours/Day
Net Capacity = Gross Capacity - Meetings - Admin - Buffer

Example (5-person team, 10-day sprint):
Gross = 5 developers × 10 days × 8 hours = 400 hours
Meetings = 5 devs × 10 days × 1.5 hrs = 75 hours  
Admin overhead = 10% × 400 = 40 hours
Buffer (20%) = 80 hours
Net Capacity = 400 - 75 - 40 - 80 = 205 hours

Story Point to Hour Conversion:

Hours per Point = Total hours tracked ÷ Story points completed

Example from last sprint:
Total time tracked: 210 hours
Story points completed: 42 points
Hours/Point = 210 ÷ 42 = 5 hours/point

For next sprint:
Net capacity: 205 hours
Commitment = 205 ÷ 5 = 41 story points

Calculating Team Capacity

The Capacity Planning Framework

Step 1: Calculate Gross Capacity

This is the theoretical maximum if everyone worked 100% of the time:

Gross Capacity = Team Size × Sprint Days × Hours per Day

Examples:
3-person team, 2-week sprint (10 days), 8-hour days:
= 3 × 10 × 8 = 240 hours

5-person team, 2-week sprint (10 days), 8-hour days:
= 5 × 10 × 8 = 400 hours

8-person team, 3-week sprint (15 days), 7-hour days:
= 8 × 15 × 7 = 840 hours

Step 2: Subtract Meeting Time

Account for all team ceremonies:

Typical Meeting Time Per Sprint:

Daily standup: 15 min/day × sprint days = 2.5 hours (10-day sprint)
Sprint planning: 2 hours
Sprint review/demo: 1 hour
Retrospective: 1 hour
Refinement/grooming: 2 hours
Total: ~8.5 hours per developer per sprint

For 10-day sprint, 5 developers:

Meeting time = 8.5 hours × 5 developers = 42.5 hours

Step 3: Subtract Administrative Overhead

Account for non-development work:

Typical Administrative Overhead:

Code reviews: 5-10% of capacity
Emails and Slack: 5-10% of capacity
Team coordination: 2-5% of capacity
Documentation: 2-5% of capacity
Total: 15-25% of gross capacity

For 400-hour gross capacity:

Admin overhead = 20% × 400 = 80 hours

Step 4: Add Buffer for Unexpected Work

Account for production issues, urgent bugs, and scope changes:

Typical Buffer:

Mature product: 10-15%
Growing product: 15-20%
Early-stage product: 20-30%

For established product:

Buffer = 15% × 400 = 60 hours

Step 5: Calculate Net Capacity

Net Capacity = Gross - Meetings - Admin - Buffer
Net = 400 - 42.5 - 80 - 60 = 217.5 hours

This is your realistic sprint capacity.

Accounting for Team Variations

Part-Time Team Members:

Developer working 50% capacity:
Contribution = 0.5 × (Sprint Days × Hours/Day)
= 0.5 × (10 × 8) = 40 hours gross capacity

Vacation and Time Off:

Developer taking 3 days vacation in 10-day sprint:
Available days = 10 - 3 = 7 days
Contribution = 7 × 8 = 56 hours gross capacity

New Team Members:

First sprint: 25-50% productivity (onboarding)
Second sprint: 50-75% productivity
Third sprint: 75-90% productivity
Fourth sprint: ~100% productivity

New developer in first sprint:
Contribution = 0.4 × (10 × 8) = 32 hours gross capacity

Multiple Skill Levels:

Senior dev: 1.2x multiplier (faster, fewer blockers)
Mid-level dev: 1.0x baseline
Junior dev: 0.7x multiplier (learning, needs review)

Effective capacity calculation:
2 seniors: 2 × 1.2 × 80 = 192 hours
2 mid-level: 2 × 1.0 × 80 = 160 hours
1 junior: 1 × 0.7 × 80 = 56 hours
Total: 408 hours gross (from 5 people × 80 = 400)

Story Point Estimation Guide

What Are Story Points?

Story Points are NOT:

❌ Hours or days
❌ Calendar time
❌ Complexity alone
❌ Comparable across teams

Story Points ARE:

✅ Relative effort estimates
✅ Combination of complexity, effort, and uncertainty
✅ Team-specific calibration
✅ Planning and prediction tool

The Fibonacci Scale

Why Fibonacci? (1, 2, 3, 5, 8, 13, 21, 34)

The increasing gaps reflect increasing uncertainty in larger estimates:

1 Point - Trivial

Simple config change
One-line bug fix
Update text content
~1 hour of work

2 Points - Simple

Small UI change
Simple form validation
Basic API endpoint
~2-3 hours of work

3 Points - Moderate

New page with existing components
Database query optimization
Multi-step form
~4-6 hours of work

5 Points - Complex

New feature with multiple components
Complex business logic
Database schema change
~8-12 hours of work

8 Points - Very Complex

Multi-page feature
Integration with external service
Significant refactoring
~15-20 hours of work

13 Points - Highly Complex

Major feature spanning multiple areas
New architecture component
Complex integration
~25-35 hours of work

21+ Points - Epic

Too large - should be broken down
Multiple sprints of work
Needs decomposition

Estimation Best Practices

1. Use Reference Stories

Identify 3-5 "calibration stories" at different point values
"3 points is like when we built the export feature"
Compare new stories to reference stories

2. Planning Poker

Team estimates together
Everyone shows their estimate simultaneously (avoid anchoring)
Discuss discrepancies
Converge on consensus estimate

3. Consider All Factors

Complexity - How hard is the code?
Effort - How much work is required?
Uncertainty - How well do we understand it?
Dependencies - What else needs to happen first?

4. When in Doubt, Go Higher

Larger estimate includes buffer
Better to over-deliver than under-deliver
Uncertainty should increase estimate

5. Track Actual Time

Compare story points to actual hours tracked
Calculate your team's hours-per-point ratio
Use data to improve future estimates

Velocity Tracking and Trends

Recording Sprint Velocity

What to Track:

After each sprint, record:

Story points committed - What you planned
Story points completed - What you finished
Completion percentage - Completed ÷ Committed
Total hours tracked - Actual time invested
Hours per point - Hours ÷ Points completed
Team size - FTE count for the sprint
Major events - Holidays, production issues, team changes

Example Sprint Record:

Sprint 12 (Jan 10-21, 2025):
- Points committed: 42
- Points completed: 38
- Completion: 90%
- Hours tracked: 195
- Hours/point: 5.1
- Team: 4.5 FTE (1 person 50% on support)
- Events: 2-day holiday, minor production issue (4 hours)

Calculating Rolling Velocity

Why Rolling Average?

Smooths out sprint-to-sprint variations
More predictable than single sprint
Captures team's sustained pace

3-Sprint Rolling Average:

Sprint 10: 35 points
Sprint 11: 42 points
Sprint 12: 38 points

Velocity = (35 + 42 + 38) ÷ 3 = 38.3 points/sprint

5-Sprint Rolling Average (Recommended):

Sprint 8: 40 points
Sprint 9: 38 points
Sprint 10: 35 points
Sprint 11: 42 points
Sprint 12: 38 points

Velocity = (40 + 38 + 35 + 42 + 38) ÷ 5 = 38.6 points/sprint

Velocity Trends and Patterns

Upward Trend (Improving):

Sprint 1: 30 points
Sprint 2: 34 points  
Sprint 3: 37 points
Sprint 4: 40 points
Sprint 5: 42 points

Trend: +3 points/sprint improvement

Causes:
✅ Team gaining experience with codebase
✅ Improved estimation accuracy
✅ Better development processes
✅ Reduced technical debt

Downward Trend (Declining):

Sprint 1: 45 points
Sprint 2: 42 points
Sprint 3: 38 points
Sprint 4: 35 points
Sprint 5: 32 points

Trend: -3.25 points/sprint decline

Causes to investigate:
❌ Increasing technical debt slowing development
❌ Growing code complexity
❌ Team burnout or morale issues
❌ Increasing production support load
❌ Losing experienced team members

Volatile (Unstable):

Sprint 1: 40 points
Sprint 2: 28 points
Sprint 3: 45 points
Sprint 4: 30 points
Sprint 5: 43 points

Variance: ±15 points

Causes:
❌ Inconsistent estimation
❌ Unpredictable scope changes
❌ Production emergencies
❌ Variable team availability
❌ Poor sprint planning

Stable (Predictable):

Sprint 1: 38 points
Sprint 2: 40 points
Sprint 3: 39 points
Sprint 4: 41 points
Sprint 5: 38 points

Average: 39.2 points, Variance: ±2 points

Indicators of health:
✅ Consistent team composition
✅ Good estimation practices
✅ Predictable sprint scope
✅ Effective sprint planning
✅ Minimal production emergencies

Industry Benchmarks and Comparisons

Velocity Benchmarks by Team Size

Small Team (2-3 developers):

Typical velocity: 20-35 points/sprint
Hours per point: 4-6 hours
Sprint capacity: 80-140 net hours

Medium Team (4-6 developers):

Typical velocity: 35-60 points/sprint
Hours per point: 4-5 hours
Sprint capacity: 140-260 net hours

Large Team (7-10 developers):

Typical velocity: 60-100 points/sprint
Hours per point: 5-7 hours (coordination overhead)
Sprint capacity: 280-520 net hours

Note: These are rough guidelines. Your team's velocity is unique and depends on many factors.

Velocity by Experience Level

Junior Team (< 1 year experience):

Lower velocity initially
Improving trend expected
More hours per point (learning time)
Higher estimation variance

Mid-Level Team (1-3 years experience):

Stable velocity
Good estimation accuracy
Standard hours per point
Consistent delivery

Senior Team (3+ years experience):

High velocity
Excellent estimation
Lower hours per point
Very consistent delivery

Completion Rate Benchmarks

Healthy Completion Rates:

90-110% - Excellent (completed close to commitment)
80-90% - Good (slight under-delivery)
110-120% - Over-delivery (may be under-estimating)

Problem Indicators:

<75% - Chronic over-commitment or poor estimation
>125% - Significant under-commitment or inflated estimates

Using Velocity for Sprint Planning

The Velocity-Based Planning Process

Step 1: Calculate Current Velocity

Last 5 sprints: 38, 42, 40, 39, 41 points
Current velocity = (38 + 42 + 40 + 39 + 41) ÷ 5 = 40 points

Step 2: Adjust for Known Factors

Base velocity: 40 points

Adjustments:
- Team member on vacation: -10%
- Holiday in sprint: -5%
- New team member joining: +5% (ramping up)

Adjusted velocity = 40 × (1 - 0.10 - 0.05 + 0.05) = 36 points

Step 3: Verify Against Capacity

Net capacity this sprint: 200 hours
Hours per point (historical): 5 hours/point
Capacity-based commitment = 200 ÷ 5 = 40 points

Velocity-based: 36 points
Capacity-based: 40 points

Conservative commitment: 36 points (use lower number)

Step 4: Select Stories

Start with highest priority items
Add stories until reaching target (36 points)
Include mix of sizes for flexibility
Leave small buffer for scope changes

Step 5: Validate with Team

Does this feel achievable?
Any concerns about specific stories?
Technical dependencies resolved?
Team agrees to commitment

Planning for Uncertainty

Confidence Levels:

High Confidence (80-90% sure):

Commit to full velocity
Well-understood stories
Stable team
No major unknowns

Medium Confidence (70-80% sure):

Commit to 90% of velocity
Some uncertainty in stories
Team changes
Minor dependencies

Low Confidence (60-70% sure):

Commit to 75-80% of velocity
Significant unknowns
New technology or domain
Many dependencies

Example:

Base velocity: 40 points
Confidence: Medium (new feature area)

Conservative commitment = 40 × 0.9 = 36 points

Real-World Examples

Example 1: Startup Dev Team

Team Profile:

3 developers (1 senior, 2 mid-level)
2-week sprints (10 working days)
Building new SaaS product
High velocity improvement expected

Capacity Calculation:

Gross capacity = 3 devs × 10 days × 8 hours = 240 hours
Meetings = 3 × 8 hours = 24 hours
Admin (20%) = 48 hours
Buffer (25% - early stage) = 60 hours
Net capacity = 240 - 24 - 48 - 60 = 108 hours

Velocity Tracking:

Sprint 1: 18 points (5 hrs/point = 90 hours)
Sprint 2: 22 points (4.8 hrs/point = 106 hours)
Sprint 3: 25 points (4.5 hrs/point = 113 hours)
Sprint 4: 28 points (4.2 hrs/point = 118 hours)
Sprint 5: 30 points (4 hrs/point = 120 hours)

Current velocity: 24.6 points/sprint
Trend: +3 points/sprint improvement
Next sprint commitment: 32 points

Analysis: ✅ Healthy upward trend (team learning codebase)
✅ Decreasing hours/point (increasing efficiency)
✅ Conservative buffer appropriate for early stage
✅ Can increase commitment as trend continues

Example 2: Agency Dev Shop

Team Profile:

6 developers (mix of client projects and support)
2-week sprints
Mix of client work and internal tools
Need buffer for client emergencies

Capacity Calculation:

Gross capacity = 6 devs × 10 days × 7.5 hours = 450 hours
Meetings = 6 × 10 hours = 60 hours
Client support (average) = 60 hours
Admin (15%) = 68 hours
Buffer (15%) = 68 hours
Net capacity = 450 - 60 - 60 - 68 - 68 = 194 hours

Velocity Tracking:

Sprint 1: 38 points (198 hours tracked)
Sprint 2: 35 points (175 hours - holiday)
Sprint 3: 40 points (205 hours)
Sprint 4: 32 points (160 hours - production emergency)
Sprint 5: 39 points (195 hours)

Current velocity: 36.8 points/sprint
Adjusted for this sprint:
- 1 developer 50% (client escalation) = -10%
- No holidays = 0%

Next sprint commitment: 36.8 × 0.9 = 33 points

Analysis: ✅ Velocity variance reflects reality of agency work
✅ Support buffer prevents over-commitment
✅ Adjustments for known constraints
✅ Conservative planning protects client relationships

Example 3: Enterprise Product Team

Team Profile:

8 developers (mature product team)
3-week sprints
Established product with tech debt
Very stable team composition

Capacity Calculation:

Gross capacity = 8 devs × 15 days × 8 hours = 960 hours
Meetings = 8 × 12 hours = 96 hours
Code review (10%) = 96 hours
Admin (12%) = 115 hours
Buffer (12%) = 115 hours
Net capacity = 960 - 96 - 96 - 115 - 115 = 538 hours

Velocity Tracking:

Sprint 1: 85 points (545 hours)
Sprint 2: 83 points (532 hours)
Sprint 3: 88 points (555 hours)
Sprint 4: 84 points (538 hours)
Sprint 5: 86 points (548 hours)

Current velocity: 85.2 points/sprint
Hours/point: 6.35 hours (reflects maturity + tech debt)
Variance: ±2.5 points (very stable)

Next sprint commitment: 85 points

Analysis: ✅ Excellent stability indicates mature team
✅ Slightly higher hours/point due to code complexity
✅ Predictable delivery enables long-term planning
✅ Small buffer reflects low uncertainty

Common Velocity Mistakes

Mistake 1: Comparing Velocity Across Teams

The Problem: "Team A has velocity of 50 points, Team B has 30 points. Team A is more productive!"

Why It's Wrong:

Story points are team-specific calibrations
Team A's "5 points" ≠ Team B's "5 points"
Different domains have different complexity
Team size, experience, tech stack all differ

What to Do Instead:

Track each team's velocity independently
Compare trends within same team over time
Use hours-per-point if you must compare
Focus on delivery value, not velocity numbers

Mistake 2: Using Velocity as Performance Metric

The Problem: "Your velocity is down this sprint - you need to work faster!"

Why It's Wrong:

Velocity is for planning, not performance evaluation
Using it for performance encourages gaming (inflating estimates)
Natural variation is normal
Ignores complexity differences between sprints

What to Do Instead:

Use velocity for capacity planning only
Evaluate teams on outcomes and value delivered
Investigate trends, not individual sprint variations
Build trust, don't punish low velocity

Mistake 3: Pressuring Team to Increase Velocity

The Problem: "Let's commit to 50 points this sprint - we can do it!"

Why It's Wrong:

Leads to over-commitment and burnout
Encourages cutting corners (quality suffers)
Inflates estimates to appear successful
Destroys velocity as a useful planning tool

What to Do Instead:

Let velocity be what it is
Focus on sustainable pace
Improve processes to naturally increase velocity
Celebrate consistent delivery, not high numbers

Mistake 4: Ignoring Capacity Constraints

The Problem: "Our velocity is 40 points, so we'll commit to 40 points - even though half the team is on vacation."

Why It's Wrong:

Velocity assumes stable team composition
Doesn't account for varying circumstances
Leads to failed sprint commitments
Erodes stakeholder trust

What to Do Instead:

Adjust velocity for known constraints
Calculate capacity independently
Use both velocity AND capacity for planning
Be transparent about constraints

Mistake 5: Not Tracking Velocity Long Enough

The Problem: "We've done 2 sprints - our velocity is 35 points!"

Why It's Wrong:

Too small sample size
Natural variation not smoothed
Team still calibrating estimates
Not predictive yet

What to Do Instead:

Track at least 5 sprints before relying on velocity
Use wider buffer early on
Expect velocity to improve as team matures
Be patient with the process

Downloadable Templates

Sprint Velocity Tracker (Spreadsheet)

Columns to Track:

Sprint number & dates
Points committed
Points completed
Completion %
Hours tracked
Hours per point
Team FTE
Major events/notes
3-sprint rolling average
5-sprint rolling average

Formulas:

Completion % = (Points Completed / Points Committed) × 100
Hours per Point = Hours Tracked / Points Completed
3-Sprint Avg = AVERAGE(last 3 sprints)
5-Sprint Avg = AVERAGE(last 5 sprints)

Capacity Planning Template

Calculate for Each Sprint:

Team Composition
- Developer names
- Availability % (accounting for vacation, etc.)
- Skill level multiplier
Time Calculations
- Gross capacity per developer
- Total gross capacity
- Meeting time deduction
- Admin overhead deduction
- Buffer allocation
- Net capacity
Commitment
- Current velocity
- Adjustments for this sprint
- Capacity-based max
- Recommended commitment

Story Point Reference Card

Create Your Team's Calibration:

Points	Complexity	Example Stories	Typical Hours
1	Trivial	Config change, text update	0.5-1
2	Simple	Small UI fix, simple endpoint	2-3
3	Moderate	Form validation, query optimization	4-6
5	Complex	Multi-component feature	8-12
8	Very Complex	Integration, schema change	15-20
13	Highly Complex	Major feature	25-35
21+	Epic	Break down into smaller stories	N/A

Integrating with Corcava

Using Corcava for Velocity Tracking

1. Sprint Board Setup

Create boards representing sprints
Use columns for workflow stages
Add story point estimates in task "amount" field
Track time on each task

2. Time Tracking Integration

Automatic time tracking on tasks
Real-time hours per story point calculation
Time reports filtered by sprint/board

3. Sprint Reports

Project performance reports
Time and task analytics
Velocity trends over time
Team performance metrics

4. Sprint Planning Workflow

Review last 5 sprints in time reports
Calculate velocity from completed tasks
Create new sprint board
Add tasks up to velocity target
Team starts time tracking on new sprint

5. Continuous Improvement

Export time data for analysis
Compare estimates to actual time
Identify patterns in over/under estimation
Refine story point calibration

Getting Started with Velocity Tracking

Week 1: Establish Baseline

Actions:

Set up sprint board structure
Train team on story point estimation
Create reference stories for calibration
Begin tracking first sprint
Track all time on tasks

Deliverables:

Sprint board with estimated tasks
Team agreement on story point scale
Time tracking started

Week 2-10: Collect Data

Actions:

Run 5 sprints (2-week sprints = 10 weeks)
Record velocity after each sprint
Track hours per story point
Note any major events or anomalies
Don't change estimation approach yet

Deliverables:

5 sprint velocity records
Hours-per-point ratio
Initial trends identified

Week 11+: Use Data for Planning

Actions:

Calculate rolling 5-sprint velocity
Use velocity for next sprint planning
Compare commitment to capacity
Track completion percentage
Refine estimation as needed

Deliverables:

Velocity-based sprint planning
Improved estimation accuracy
Predictable delivery

Conclusion: Data-Driven Sprint Planning

Stop guessing at sprint capacity. Start planning with real data.

What You've Learned:

✅ Calculate team capacity - Account for meetings, overhead, and buffer
✅ Track velocity - Rolling average from last 5 sprints
✅ Estimate with story points - Relative sizing, not hours
✅ Plan realistic sprints - Use both velocity and capacity
✅ Track trends - Identify improvements or issues early
✅ Avoid common mistakes - Don't compare teams or pressure for higher velocity

The Result:

Predictable sprint delivery
Stakeholder trust in commitments
Sustainable team pace
Data for continuous improvement
Better long-term planning

Ready to start tracking velocity?

Use Corcava's integrated time tracking and project management to automatically calculate your team's velocity, track trends, and plan realistic sprints.

Next Steps:

Set up your first sprint board - In Corcava
Estimate with story points - Use the Fibonacci scale
Track time on all tasks - Use automatic or manual tracking
Record sprint results - After each sprint completion
Calculate velocity - After 5 sprints, use data for planning

Transform sprint planning from guesswork to science. Your team, your stakeholders, and your sanity will thank you.

Related Resources:

Ready to get started?Sign up for Corcava today and start tracking your engineering velocity.