🏃

Sprint Planner

Plan and calculate sprint capacity

Sprint Duration

Team Size

Hours per Day

Focus Factor (%)

Account for meetings, interruptions (typically 60-80%)

Team Days Off

Sprint Capacity

280

Total Hours

Story Points (est)

Available Days

400

Raw Hours

Hours/Person

Sprint Tasks

Allocated Hours0 / 280

280 hours remaining

Sprint Velocity History

Sprint 1points

Sprint 2points

Sprint 3points

Average Velocity

Suggested Commitment

Planning Tips

•Leave 15-20% buffer for unexpected work

•Use historical velocity as a guide, not a target

•Account for holidays, PTO, and planned absences

•Don't commit to more than team capacity

What is Sprint Planning Calculator?

A sprint planning calculator helps teams estimate their capacity for an upcoming sprint by factoring in team size, sprint length, individual availability (vacations, meetings, non-sprint work), and historical velocity. It outputs the number of story points or tasks the team can realistically commit to.

How to use this calculator

1Enter your team size and remove members on leave or with significant non-sprint commitments.
2Set the sprint length in days (10 days for 2-week sprints).
3Input each team member's available hours per day, accounting for meetings and other overhead.
4Review the calculated sprint capacity in person-hours or story points.
5Compare against your backlog and commit only to items within capacity, using historical velocity as a sanity check.

Why this matters for founders

Overcommitting in sprints is the most common agile failure mode -- it demoralizes teams, produces rushed work, and destroys predictability. Accurate capacity planning turns sprints from aspirational wishlists into reliable delivery commitments.

How to read the results

•Use historical velocity (average story points completed in past 3-5 sprints) as the primary input, not team optimism.
•Reduce capacity for meetings, on-call rotations, holidays, and expected interruptions -- a developer's 'coding capacity' is typically 60-70% of their total hours.
•Two-week sprints are the most common and recommended cadence; one-week sprints have too much overhead, four-week sprints lose urgency.
•If actual velocity consistently differs from planned capacity by more than 20%, your estimation or planning process needs calibration.

Industry benchmarks

Average developer productivity is 5-6 productive hours per 8-hour day. Two-week sprints are standard for teams of 3-9 developers. Velocity should stabilize within 3-4 sprints of working together. Sprint goal completion rate should be above 80% for a healthy team.