Production Bug Fix Sprint — @bug-fix-sprint

Every product carries a list of known production defects that never quite make a sprint: real bugs, reported and reproducible, deprioritized against features until they define the product's reputation. The Production Bug Fix Sprint takes a bounded batch off that list — triaged and agreed up front, investigated to root cause, fixed properly, and released — without pulling your team off the roadmap.

The discipline follows how Scrums.com approaches quality work generally: fixes land with regression tests, so the same defect cannot return silently, and the sprint is defined by the agreed defect list rather than open-ended firefighting. The finish state is that list closed — each item fixed and verified in production, or explicitly returned with findings where investigation changed the picture.

Defect Triage & Reproduction

The candidate list triaged with you — severity, user impact, reproducibility — and locked as sprint scope, with reproduction cases established before fixing starts.

Root-Cause Fixes

Fixes at the cause rather than the symptom, matching your codebase conventions, with each change reviewed and traceable to its defect.

Regression Test Coverage

An automated test per fix that reproduces the original defect and locks it out — growing your suite where it has demonstrably been thin.

Release & Verification

Fixes released through your pipeline in agreed batches, verified in production, and reported item by item against the sprint list.

1. Scope — Triage the backlog together, fix the sprint's defect list, and agree access, environments, and release rules.
2. Build — Reproduce, fix, and test each defect, releasing in batches with your team's review.
3. Handover — Final verification report per defect, the new regression tests documented, and patterns worth fixing structurally flagged.

The Production Bug Fix Sprint is a menu item on the Scrums.com delivery catalog, available at every plan tier. Add it to your plan backlog and your delivery team schedules it like any other item — scoped, tracked, and reported through the SEOP. See Delivery Plan Tiers.

How many defects fit in a sprint?

Depends entirely on their depth — triage sizes each candidate before the list is locked, so scope is an agreement, not a guess. Bounded scope is what makes the finish state checkable.

What if a bug is deeper than it looked?

Investigation findings are surfaced immediately: the item is either re-scoped by agreement or returned with a documented root cause and recommendation — commonly pointing at the Technical Debt Reduction Sprint when the cause is structural.

What about the bugs that keep coming?

A recurring stream signals a stability problem, not a backlog problem. Ongoing coverage under response SLAs is Platform Maintenance from the menu; a genuinely failing application is the Critical Application Rescue.