The Capacity Planning Framework That Stuck

Early in my time at Bounteous, I realized nobody had a consistent way to answer a simple question: do we have enough people to deliver what we have committed to?

Every PM had their own spreadsheet. Some tracked by hours, some by story points, some by gut feel. None of them talked to each other. When leadership asked for a portfolio-level capacity view, it took a week to assemble one, and the data was already stale by the time it was ready.

So I built a framework. Not because anyone asked me to, but because I needed it for my own accounts.

The Model

Step 1: Normalize capacity units. I standardized on available person-days per sprint, excluding holidays, PTO, and meetings overhead. A full-time developer in a two-week sprint has roughly 8.5 available days, not 10. This adjustment alone fixed half the over-commitment problems.

Step 2: Map demand against capacity. Every committed deliverable gets a rough person-day estimate at the epic level. I do not need task-level granularity for planning. I need to know that Epic A needs approximately thirty person-days and I have forty available across the team.

Step 3: Buffer for the unknown. I allocate 15% of capacity as buffer — this covers technical debt, production issues, and the inevitable scope creep that no amount of change management fully prevents.

Step 4: Visual dashboard. One view that shows capacity versus demand per team, per sprint, rolling four sprints out. Green means comfortable. Yellow means tight. Red means we need to have a conversation.

How It Spread

Other PMs started asking for my spreadsheet. I cleaned it up, wrote a one-page guide, and shared it at a PM community of practice session. Within two quarters, it became the standard template across the portfolio.

The best frameworks are the ones that solve a real problem so clearly that adoption happens through pull, not push.