Bug Report Template for Engineering Teams

Anyone who discovers the bug. Support reps should file reports for customer-reported issues. QA engineers should file reports for defects found during testing. Engineers should file reports for issues found in code review or monitoring. The key is to provide a consistent template so every report contains the information engineering needs, regardless of who wrote it.

Reserve 15-25% of each sprint's capacity for unplanned work, including bugs. P0 bugs override everything and get fixed immediately. P1 bugs go into the current or next sprint. P2 and P3 bugs go into the backlog and compete with feature work during planning. Track the ratio of bug fixes to feature work over time. If bugs consistently consume more than 30% of capacity, that signals a quality problem that needs structural attention, not just faster fixing. The [Sprint Planning template](/templates/sprint-planning-template) shows how to build a buffer for unplanned work.

If the reporter cannot reproduce the bug, ask for more environment details and check server-side logs for the specific timestamp. If engineering cannot reproduce it after a reasonable investigation (2-4 hours for a P1, 1 hour for a P2-P3), mark it as "Cannot Reproduce" and set it aside. If a second report comes in with the same symptoms, reopen it. Intermittent bugs often have timing, concurrency, or environment-specific triggers that only become clear with multiple data points.

Both, and they mean different things. Severity describes how bad the bug is (how much damage it causes). Priority describes how soon it should be fixed (where it sits in the queue relative to other work). A cosmetic bug on your pricing page might be low severity but high priority because it affects conversion. A data corruption bug in an admin-only tool might be high severity but medium priority because it affects one person per month. This template uses severity for classification. Priority is determined during triage.

Bugs are a lagging indicator of process quality. To reduce them: invest in automated testing (unit, integration, and end-to-end), require code review before merge, run QA on a staging environment that matches production, and track regressions explicitly. The [Product Operations Handbook](/product-ops-guide) covers how to set up quality gates in your development workflow. Tracking which types of bugs recur most often (browser-specific, mobile, data edge cases, third-party integrations) helps focus preventive investment where it has the highest return.