tezvyn:

Roadmap Capacity Planning: Ideal vs. Reality

AI-drafted, machine-checkedSource: Wikipedia: Capacity planningintermediate

Capacity planning isn't about your team's ideal output (design capacity), but their actual output (effective capacity) after accounting for meetings, bugs, and on-call. Use it to build realistic roadmaps.

WHY IT EXISTS: To solve the chronic problem of missed deadlines and over-promised roadmaps. Without a formal way to account for non-feature work, teams consistently underestimate how long projects will take, leading to a cycle of crunch, burnout, and broken trust with stakeholders.

THE MENTAL MODEL: Think of your team's capacity like a water pipe. Design capacity is the pipe's maximum possible flow if it were perfectly clean and straight. Effective capacity is the actual flow you get when you account for real-world constraints like bends, corrosion, and pressure drops. You plan your system based on the effective flow, not the theoretical maximum.

HOW IT WORKS: Start with your team's design capacity: the number of engineers multiplied by the hours in a given period. For a 5-person team in a two-week sprint, that's 5 engineers * 80 hours = 400 hours. This is your baseline. Next, track and subtract all the time spent on non-feature work: meetings, on-call rotations, urgent bug fixes, code reviews, interviews, and paid time off. The remainder is your effective capacity. If that 400-hour team spends 150 hours on these other tasks, their effective capacity for new work is 250 hours, not 400. This is often expressed as a percentage, like a 60% capacity for feature work.

WHEN TO USE IT: Use this when building quarterly or annual roadmaps to determine how many projects the team can realistically commit to. It's also vital for sprint planning to ensure the team isn't over-committed due to known interruptions like holidays or on-call handoffs. It grounds prioritization discussions in reality.

WHEN NOT TO USE IT: Do not use capacity planning as a tool for micromanaging individual performance or tracking every minute of an engineer's day. Its purpose is aggregate planning and forecasting for the team, not individual productivity measurement. Over-indexing on precise hour-tracking creates a culture of distrust.

ONE CANONICAL EXAMPLE: A PM wants to ship three features next quarter. The 6-engineer team has a design capacity of about 2880 hours (6 engineers * 12 weeks * 40 hours/week). Historical data shows the team spends 40% of its time on operational load. Their effective capacity is therefore 2880 * 0.60 = 1728 hours. The features are estimated at 1900 hours total. Based on effective capacity, the roadmap is already unrealistic. The PM must now de-scope a feature or move it to the next quarter, a decision made possible by realistic planning.

Read the original → en.wikipedia.org

Get five bites like this every day.

Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.