Software Bug Inflow and Triage Velocity Projection

Role: Staff Software Quality & Reliability Engineer specializing in defect lifecycle modeling.

Context

• Codebase repository and service tier: {{repository_name}}
• Historical defect discovery rate per sprint: {{historical_defect_rate}}
• Engineering triage team size and velocity: {{engineering_team_size}}
• Target release date: {{target_release_date}}
• Critical code changes and refactoring scope: {{code_change_volume}}

Task

Generate a defect inflow and resolution forecast analysis that models expected bug emergence, triage duration, and release stability readiness for {{repository_name}} before {{target_release_date}}.

Method

1. Calculate the defect injection probability per unit of code change based on {{code_change_volume}} and {{historical_defect_rate}}.
2. Estimate total incoming defect volume categorized by severity (P0/P1 vs P2/P3).
3. Compute maximum weekly bug resolution bandwidth using {{engineering_team_size}} capacity assumptions.
4. Simulate weekly open defect backlog curves from current day to {{target_release_date}}.
5. Determine the projected zero-P0/P1 convergence date under baseline velocity.
6. Model a degraded scenario where defect resolution takes 30% longer due to complex regressions.
7. Provide specific code testing recommendations to flatten the incoming defect curve.

Constraints

• MUST provide clear convergence dates rather than open-ended timeframes.
• MUST NOT treat all defect severities as having identical resolution effort.
• MUST explicitly evaluate if {{target_release_date}} is statistically achievable.
• Assumptions regarding developer hours dedicated to triage must remain constant across scenarios.

Output format

1. Release Readiness Verdict (Feasible / At Risk / Unfeasible with 2-sentence rationale)
2. Defect Inflow & Outflow Model (Weekly tabular projection: Week, Inflow, Resolved, Active Backlog)
3. Critical Path Severity Breakdown (P0/P1 vs P2/P3 burn-down)
4. Risk Mitigation Actions (3 actionable quality interventions)

Self-review

• Verify that resolution capacity mathematically balances against {{engineering_team_size}}.
• Ensure clear distinction between high-severity blockers and cosmetic defects.
• Check that the stabilization verdict directly answers feasibility for {{target_release_date}}.