Capacity Planning That Actually Works

I have tried every capacity planning approach out there. Spreadsheets, Jira plugins, Resource Guru, even a custom Confluence macro. They all share the same flaw: they model capacity as a static number when it is actually a dynamic, context-dependent variable.

The Problem With Hours

Most capacity planning tools ask you to assign hours per person per project. This sounds reasonable until you account for context switching, meetings, on-call rotations, technical debt work, and the fact that a senior engineer's eight hours produces fundamentally different output than a junior engineer's eight hours.

I stopped planning in hours two years ago. I plan in focus days. A focus day is a day where an engineer has at least four uninterrupted hours for deep work. Most engineers get three to four focus days per week. That number is your real capacity, not forty hours.

The Framework

For each sprint, I calculate available focus days per engineer, subtract known interruptions like on-call rotations and recurring meetings, apply a historical accuracy factor based on the last three sprints, and use that final number as the team's true capacity.

The historical accuracy factor is critical. If your team consistently delivers 80 percent of what they commit to, your planning should reflect that. Pretending the team will suddenly hit 100 percent next sprint is not optimism. It is denial.

What Changed

After implementing this framework, our sprint completion rate went from 65 percent to 88 percent within three sprints. We did not get faster. We got more honest about our capacity. Teams stopped overcommitting because the numbers did not let them pretend.

The Tool

I built a simple FastAPI service that pulls sprint data from Jira, calculates focus days, and generates capacity recommendations. It is not pretty, but it works. The best planning tool is the one your team actually trusts.