Calculator Inputs
Use the responsive planner below to model staffing, focus time, interruptions, and historical delivery behavior.
Formula Used
Effective Days per Member = Sprint Working Days − Public Holidays − Average Leave Days
Gross Team Hours = Team Members × Effective Days per Member × Hours per Day
Meeting Loss Hours = Team Members × Effective Days per Member × Meeting Hours per Day
Net Build Hours = Gross Team Hours − Meeting Loss Hours
Delivery Hours = Net Build Hours × Availability × Focus × (1 − Support Load) × (1 − Collaboration Overhead) × (1 − Buffer) × QA Coverage
Adjusted Capacity Hours = Delivery Hours × Velocity Adjustment
Estimated Story Points = Adjusted Capacity Hours × Story Points per Hour
Percentages are converted into decimal factors before multiplication. This keeps the estimate transparent and easy to tune.
How to Use This Calculator
- Enter the number of delivery team members working in the sprint.
- Set the sprint working days and each person’s daily workable hours.
- Add holidays, average leave, and daily meeting time.
- Adjust availability, focus, support load, collaboration overhead, and QA coverage.
- Use a velocity adjustment if your team usually overperforms or underperforms baseline estimates.
- Add story points per hour if you want an hour-to-points forecast.
- Press Calculate Capacity to show the result beneath the header and above the form.
- Export the visible result summary with the CSV or PDF buttons.
Example Data Table
| Scenario | Members | Sprint Days | Hours/Day | Meetings/Day | Availability | Focus | Support | Buffer | Capacity Hours | Story Points |
|---|---|---|---|---|---|---|---|---|---|---|
| Balanced product sprint | 6 | 10 | 8 | 1.25 | 90% | 85% | 10% | 12% | 176.03 | 123.22 |
| Support-heavy release sprint | 8 | 10 | 8 | 1.5 | 85% | 75% | 20% | 15% | 205.02 | 123.01 |
Frequently Asked Questions
1. What does team capacity mean in software delivery?
Team capacity is the realistic amount of work a team can finish in one sprint after accounting for meetings, leave, support work, focus loss, and planning buffer.
2. Why should I include meeting hours?
Meetings reduce development time directly. Ignoring ceremonies, reviews, and coordination often causes overly optimistic sprint plans and avoidable rollover work.
3. What is the difference between availability and focus?
Availability measures whether people are free for project work. Focus measures how much of that available time becomes productive, uninterrupted execution time.
4. When should I change the velocity adjustment?
Change it when recent sprints consistently finish above or below baseline estimates. It helps the model reflect real delivery behavior instead of ideal assumptions.
5. Why add a contingency buffer?
A buffer protects the sprint from surprise defects, discovery work, and dependency delays. It improves commitment reliability and reduces forced scope cuts late in the sprint.
6. Can I use story points per hour reliably?
Yes, if you derive it from your own historical data. Cross-team point scales vary, so internal trend data is much more trustworthy than generic conversion assumptions.
7. What does pod capacity show?
Pod capacity splits total adjusted hours across active subteams. It is useful when squads work in parallel on separate modules, releases, or streams.
8. Should QA coverage always stay at 100%?
Not always. Lower the value when testing support is limited, shared, or delayed. That creates a more realistic estimate for completed and releasable work.