Capacity Planning Mistakes I Keep Seeing

Capacity planning sounds simple. Figure out how much work your team can do, then assign that much work. In practice, almost everyone gets it wrong. After eleven years in this industry, here are the mistakes I see most often.

Mistake 1: Planning at 100% Capacity

No one produces eight hours of focused work in an eight-hour day. Meetings, Slack, email, context switching, and basic human needs eat into that. I plan at sixty to seventy percent capacity for individual contributors. If someone has four hours of meetings, they have maybe two to three hours of real development time. Plan accordingly.

Mistake 2: Ignoring Leave and Holidays

This seems obvious but I have watched multiple teams plan a sprint without accounting for a public holiday that falls mid-sprint. Build a team calendar. Check it during planning. Every time.

Mistake 3: Treating All Team Members as Interchangeable

Your senior backend engineer and your junior frontend developer are not fungible resources. Capacity planning needs to account for skill sets, not just headcount. If the sprint has three backend stories and your backend engineer is on leave, your capacity for backend work is zero regardless of how many people are available.

Mistake 4: Not Accounting for Support and Maintenance

Production support, bug fixes, and maintenance work do not stop because you are in a sprint. Reserve a buffer. I typically set aside fifteen to twenty percent of capacity for unplanned work. If you do not need it, great, pull in the next backlog item. If you do, your sprint goal is not blown.

Mistake 5: Using Last Sprint's Velocity Without Context

If last sprint had no holidays, no sick days, and no production incidents, it is not a reliable baseline for a sprint with two holidays and a major release. Adjust.

Capacity planning is not glamorous, but getting it right is the difference between a team that delivers consistently and one that is perpetually overcommitted. It deserves your attention.