Planning Capacity for Production Work

Production work includes incident response, support, emergent bug fixes, and operational overhead. These activities consume engineering capacity. In our experience, neglecting to plan for this work leads to inaccurate capacity estimates and delayed project delivery. Successful planning integrates a dedicated allocation for these operational demands.

Why Production Work Gets Left Out of Plans

Production systems require ongoing attention. Incidents occur unpredictably. User support often escalates to engineering for investigation. Maintenance tasks, security patches, and operational scaling also consume time. These demands often compete directly with planned feature development.

Organizations frequently optimize for feature velocity. This incentivizes underestimating production-related work during planning phases. Teams commit to roadmaps assuming full feature development capacity. Production needs then interrupt these plans. This creates a hidden cost. It leads to technical debt accumulation from uncontrolled velocity and missed deadlines. Engineers operating within this model experience frequent context switching. Reliability erosion can also be a consequence.

How to Measure Production Work Before Planning

1. Quantify Historical Production Work. Gather data on time spent on production-related tasks.
2. Categorize Work Types. Classify production work into buckets. Examples include incident response, bug fixes, support escalations and maintenance.
3. Measure Time per Category. Use project management tools or time tracking to determine hours spent per category. Include on-call shifts.
4. Calculate Average Allocation. Determine the average percentage of engineering time dedicated to production work over several planning cycles (e.g., 3-6 months).
5. Identify Trends. Look for increases or decreases in production work over time. Relate changes to system complexity or team size.
6. Assess Operational Burden Sources. Identify specific services or components generating the most operational noise.
7. Estimate Future Demand. Project future production work based on historical data and anticipated system changes. Consider new services, increased traffic, or team growth.

A Practical Example With a Payment Team

Here is an illustrative example we use to show the pattern. A SaaS company’s Payment team consistently missed sprint commitments. Their roadmap focused solely on new feature development. Engineers reported frequent interruptions for production issues. The Director of Engineering initiated an investigation.

Over two quarters, every engineer tracked their time spent on non-feature work. This included P0/P1 incident response, customer support escalations, and urgent bug fixes. Data revealed that the Payment team collectively spent 25-30% of their available engineering hours on these activities. Some weeks, this figure exceeded 50% for individual engineers.

The investigation identified the root cause, an aging microservice handling subscription renewals. This service had frequent database connection issues and intermittent third-party API failures. These issues directly drove the high incident count. Customer support consistently escalated billing inquiries. The team had no dedicated capacity for its remediation.

During the next capacity planning cycle, the team allocated 25% of their total engineering capacity specifically for production work. This buffer covered anticipated incidents and support. Additionally, they dedicated 15% to a targeted refactor of the problematic subscription renewal service. This refactor was treated as a feature, with specific goals of reducing incident volume. This change made the roadmap more realistic. Incident volume decreased following the refactor, leading to improved predictability.

Preventing Recurrence With a Production Buffer

Implement a dedicated “production buffer” in all capacity planning models. This should be a percentage of total engineering capacity. Use historical data to inform this percentage. Regularly review and adjust this buffer. Implement an explicit operational roadmap alongside feature roadmaps. Prioritize efforts to reduce the root causes of production work. This includes improving system observability, automating routine tasks, and addressing technical debt. Ensure on-call rotations are adequately staffed and compensated. Document runbooks and incident response procedures to reduce resolution time. Proactively dedicate capacity to operational improvements.

What Teams Usually Do Instead

Teams often plan capacity solely around new feature delivery. They assume production work is negligible or will be handled “on the side.” This leads to an underestimation bias in project timelines. When incidents occur, they interrupt planned work. This causes context switching and slows feature development. Engineers then feel pressure to rush fixes. This introduces new bugs and creates a cycle of reactive work. Some teams try to address this by simply increasing individual engineer workload, leading to burnout. Others attempt to “catch up” by deferring maintenance or critical upgrades, which compounds future operational load. This approach provides short-term perceived velocity at the expense of long-term predictability and system health. A realistic product engineering plan names this capacity instead of hiding it.

Key Takeaways for Capacity Planning

• Allocate explicit capacity for production work.
• Quantify historical time spent on operational tasks.
• Integrate production buffers into all planning.
• Prioritize remediation of high-impact operational issues.
• Avoid assuming production work is zero-sum.

For the sprint-level view, read why production work breaks sprint plans, or talk to Better Software about planning your engineering capacity.

Frequently Asked Questions

How Do I Account for Production Work in Capacity Planning?

We add a dedicated allocation, a production buffer expressed as a percentage of total engineering capacity, to every planning model. We base the percentage on historical data, review it regularly and keep an explicit operational roadmap alongside the feature roadmap.

What Counts as Production Work?

In our view it includes incident response, user support escalations, emergent bug fixes, maintenance tasks, security patches, operational scaling and on-call shifts. These demands compete directly with planned feature development and consume capacity that plans often assume is free.

How Do I Measure Historical Production Work?

We gather data on time spent on production-related tasks, classify it into buckets such as incident response, bug fixes, support and maintenance, and measure hours per category including on-call shifts. Then we average the allocation over several planning cycles, for example three to six months, and look for trends.

Why Do Teams Underestimate Production Work?

Organizations often optimize for feature velocity, which in our experience encourages underestimating production-related work. Teams commit to roadmaps assuming full feature capacity, then incidents interrupt the plan, which creates hidden cost, context switching and missed deadlines.

How Can I Reduce the Amount of Production Work?

We prioritize the root causes behind it. That means improving observability, automating routine tasks, addressing technical debt, staffing on-call rotations properly and documenting runbooks so incidents resolve faster. We also dedicate capacity to operational improvements instead of treating them as spare time.