Balance Features vs Bug Fixes | Sprint Allocation Guide
Allocate sprint capacity between features and bugs using GitScrum's prioritization workflows. Labels, automation rules, and dashboards ensure bugs don't derail your roadmap.
13 min read
Every development team faces the tension between building new features and fixing existing bugs. GitScrum's board configuration, label system, and sprint planning tools help teams find the right balance by making bug work visible, establishing allocation policies, and creating processes that prevent bugs from being perpetually deprioritized while still delivering customer value through new capabilities.
Understanding the Tension
The Balance Problem
COMPETING PRIORITIES:
┌─────────────────────────────────────────────────────────────┐
│ WHY BALANCE IS HARD │
├─────────────────────────────────────────────────────────────┤
│ │
│ FEATURE PRESSURE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Roadmap commitments to stakeholders ││
│ │ • Competitive pressure to ship ││
│ │ • New features = visible progress ││
│ │ • Revenue tied to feature delivery ││
│ │ • More "exciting" work for team ││
│ │ ││
│ │ Result: Bugs get pushed to "later" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BUG PRESSURE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Customer complaints and churn ││
│ │ • Support ticket volume ││
│ │ • Technical debt slowing development ││
│ │ • Team morale (working on broken product) ││
│ │ • Security and compliance risks ││
│ │ ││
│ │ Result: "Bug bankruptcy" if ignored too long ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ THE DEATH SPIRAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Skip bugs → Ship features → ││
│ │ More bugs appear → Skip bugs → ││
│ │ Ship features faster (pressure) → ││
│ │ Even more bugs → Product destabilizes → ││
│ │ Features can't ship (everything breaks) → ││
│ │ Emergency bug sprint → Team burns out ││
│ │ ││
│ │ Breaking the cycle requires intentional allocation ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Healthy Balance Indicators
MEASURING YOUR BALANCE:
┌─────────────────────────────────────────────────────────────┐
│ HEALTH SIGNALS │
├─────────────────────────────────────────────────────────────┤
│ │
│ HEALTHY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ Bug count stable or decreasing ││
│ │ ✅ Critical bugs resolved within SLA ││
│ │ ✅ Features ship without major regressions ││
│ │ ✅ Team confident in product stability ││
│ │ ✅ Support ticket volume manageable ││
│ │ ✅ Bugs distributed across sprints (not batched) ││
│ │ ││
│ │ Typical allocation: 70% features, 20% bugs, 10% tech ││
│ │ debt ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ UNHEALTHY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ⚠️ Bug backlog growing every sprint ││
│ │ ⚠️ "Old" bugs (3+ months) accumulating ││
│ │ ⚠️ Critical bugs take weeks to fix ││
│ │ ⚠️ Features blocked by existing bugs ││
│ │ ⚠️ Team dreading bug triage ││
│ │ ⚠️ Customer complaints increasing ││
│ │ ││
│ │ Warning: Need to rebalance allocation ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CRISIS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🚨 "Bug bankruptcy" - too many to count ││
│ │ 🚨 Features can't ship due to regressions ││
│ │ 🚨 Major customers threatening to leave ││
│ │ 🚨 Team afraid to touch code ││
│ │ ││
│ │ Emergency: Need dedicated bug sprint(s) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Allocation Strategies
Percentage Allocation
FIXED ALLOCATION APPROACH:
┌─────────────────────────────────────────────────────────────┐
│ SPRINT CAPACITY SPLIT │
├─────────────────────────────────────────────────────────────┤
│ │
│ MODEL: 70/20/10 │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sprint Capacity: 80 story points ││
│ │ ││
│ │ ┌─────────────────────────────────────────────────┐ ││
│ │ │ FEATURES │ 56 pts │ ││
│ │ │ (Roadmap items, new capabilities) │ 70% │ ││
│ │ ├───────────────────────────────────────┼────────┤ ││
│ │ │ BUGS │ 16 pts │ ││
│ │ │ (Defects, regressions, quality) │ 20% │ ││
│ │ ├───────────────────────────────────────┼────────┤ ││
│ │ │ TECH DEBT │ 8 pts │ ││
│ │ │ (Refactoring, tooling, upgrades) │ 10% │ ││
│ │ └───────────────────────────────────────┴────────┘ ││
│ │ ││
│ │ IN GITSCRUM: ││
│ │ • Use labels: type/feature, type/bug, type/tech-debt ││
│ │ • Filter by labels to verify allocation ││
│ │ • Track in sprint analytics ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ADJUSTING BASED ON STATE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ State │ Features │ Bugs │ Tech Debt ││
│ │ ───────────────┼──────────┼──────┼─────────── ││
│ │ Healthy │ 70% │ 20% │ 10% ││
│ │ Bug backlog │ 60% │ 30% │ 10% ││
│ │ Stabilization │ 50% │ 40% │ 10% ││
│ │ Crisis │ 30% │ 60% │ 10% ││
│ │ Post-crisis │ 80% │ 15% │ 5% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Bug Days/Rotation
DEDICATED BUG TIME:
┌─────────────────────────────────────────────────────────────┐
│ ROTATION APPROACHES │
├─────────────────────────────────────────────────────────────┤
│ │
│ OPTION 1: BUG DAY │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Every Friday: Bug fix day ││
│ │ ││
│ │ Rules: ││
│ │ • Whole team works on bugs ││
│ │ • No feature work allowed ││
│ │ • Triage in morning, fix all day ││
│ │ • Celebrate fixes at end of day ││
│ │ ││
│ │ Benefits: ││
│ │ • Predictable bug time ││
│ │ • No context switching during week ││
│ │ • Team ritual builds culture ││
│ │ ││
│ │ Drawbacks: ││
│ │ • Critical bugs wait until Friday ││
│ │ • One day might not be enough ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OPTION 2: BUG ROTATION │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Each sprint: One developer on bug duty ││
│ │ ││
│ │ Rules: ││
│ │ • Rotates each sprint ││
│ │ • Bug duty = only bugs, no features ││
│ │ • Handle critical bugs immediately ││
│ │ • Work through prioritized backlog ││
│ │ ││
│ │ Benefits: ││
│ │ • Fast response to critical bugs ││
│ │ • Dedicated focus (no split attention) ││
│ │ • Everyone learns all areas of code ││
│ │ ││
│ │ Drawbacks: ││
│ │ • Feature velocity reduced by 1 person ││
│ │ • Can feel like punishment ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OPTION 3: BUG SPRINT │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Every 4th sprint: Bug-only sprint ││
│ │ ││
│ │ Rules: ││
│ │ • Entire sprint dedicated to quality ││
│ │ • Bugs, tech debt, testing improvements ││
│ │ • No new features ││
│ │ ││
│ │ Best for: Teams with significant accumulated debt ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Bug Prioritization
Severity and Priority
BUG CLASSIFICATION:
┌─────────────────────────────────────────────────────────────┐
│ SEVERITY VS PRIORITY │
├─────────────────────────────────────────────────────────────┤
│ │
│ SEVERITY (Impact of bug): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ S1 - CRITICAL: ││
│ │ • Data loss or corruption ││
│ │ • Security vulnerability ││
│ │ • Complete feature broken ││
│ │ • No workaround possible ││
│ │ ││
│ │ S2 - HIGH: ││
│ │ • Major feature significantly degraded ││
│ │ • Workaround exists but painful ││
│ │ • Affects many users ││
│ │ ││
│ │ S3 - MEDIUM: ││
│ │ • Feature works but with issues ││
│ │ • Easy workaround available ││
│ │ • Affects some users ││
│ │ ││
│ │ S4 - LOW: ││
│ │ • Cosmetic issues ││
│ │ • Edge cases ││
│ │ • Minimal user impact ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRIORITY (When to fix): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ P1: Fix immediately (drop everything) ││
│ │ P2: Fix this sprint ││
│ │ P3: Fix soon (next 2-3 sprints) ││
│ │ P4: Fix eventually (backlog) ││
│ │ ││
│ │ Priority considers: ││
│ │ • Severity ││
│ │ • Number of users affected ││
│ │ • Customer tier (enterprise vs free) ││
│ │ • Workaround availability ││
│ │ • Effort to fix ││
│ │ • Related work in progress ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SEVERITY → PRIORITY MAPPING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ │ Many Users │ Some Users │ Few Users ││
│ │ ────────┼────────────┼────────────┼─────────── ││
│ │ S1 Crit │ P1 │ P1 │ P2 ││
│ │ S2 High │ P1 │ P2 │ P2 ││
│ │ S3 Med │ P2 │ P3 │ P3 ││
│ │ S4 Low │ P3 │ P4 │ P4 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
SLA Approach
SERVICE LEVEL AGREEMENTS:
┌─────────────────────────────────────────────────────────────┐
│ BUG RESOLUTION SLAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ DEFINE RESPONSE AND RESOLUTION TIMES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Priority │ Acknowledge │ Fix Started │ Resolved ││
│ │ ─────────┼─────────────┼─────────────┼───────── ││
│ │ P1 │ 1 hour │ 4 hours │ 24 hours ││
│ │ P2 │ 4 hours │ 1 day │ 1 week ││
│ │ P3 │ 1 day │ 1 week │ 1 month ││
│ │ P4 │ 1 week │ Backlog │ When capacity ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TRACKING IN GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Add custom field: "Bug Priority" (P1-P4) ││
│ │ 2. Add custom field: "Reported Date" ││
│ │ 3. Create saved filters: ││
│ │ • "P1 Bugs" - immediate attention ││
│ │ • "SLA At Risk" - approaching deadline ││
│ │ • "SLA Breached" - past deadline ││
│ │ ││
│ │ 4. Review daily in standup: ││
│ │ "Any P1/P2 bugs? Any at SLA risk?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SLA BREACH ESCALATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ At 50% of SLA time: Yellow flag, PM notified ││
│ │ At 80% of SLA time: Orange flag, Lead involved ││
│ │ At 100% (breach): Red flag, leadership escalation ││
│ │ ││
│ │ Breaches require post-mortem: Why did this slip? ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Sprint Planning
Bug Selection
PLANNING FOR BUGS:
┌─────────────────────────────────────────────────────────────┐
│ SPRINT PLANNING APPROACH │
├─────────────────────────────────────────────────────────────┤
│ │
│ BEFORE PLANNING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Triage bug backlog ││
│ │ • Update priorities ││
│ │ • Close duplicates/invalid ││
│ │ • Add effort estimates ││
│ │ ││
│ │ 2. Calculate bug budget ││
│ │ • Total capacity × bug percentage ││
│ │ • Example: 80 points × 20% = 16 points for bugs ││
│ │ ││
│ │ 3. Pre-select candidates ││
│ │ • P1/P2 bugs (required) ││
│ │ • Oldest P3 bugs ││
│ │ • Bugs related to sprint features ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DURING PLANNING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Start with required bugs (P1/P2) ││
│ │ • Non-negotiable, must fit ││
│ │ • If too many, escalate capacity problem ││
│ │ ││
│ │ 2. Fill remaining bug budget ││
│ │ • Pick from P3 candidates ││
│ │ • Consider: age, customer impact, related work ││
│ │ ││
│ │ 3. Plan features with remaining capacity ││
│ │ ││
│ │ 4. Check balance ││
│ │ • Does allocation match target percentages? ││
│ │ • Adjust if needed ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BUG BUNDLING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Group related bugs for efficiency: ││
│ │ ││
│ │ "Payment bugs bundle" (3 bugs, same area): ││
│ │ • Fix all while context is loaded ││
│ │ • Test together ││
│ │ • Deploy together ││
│ │ ││
│ │ "Feature X bugs" (bugs in area being changed): ││
│ │ • Fix while already modifying code ││
│ │ • Prevents double context switching ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Board Configuration
VISUALIZING BALANCE:
┌─────────────────────────────────────────────────────────────┐
│ BOARD SETUP FOR VISIBILITY │
├─────────────────────────────────────────────────────────────┤
│ │
│ OPTION 1: SWIMLANES BY TYPE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ┌─────────┬─────────┬─────────┬─────────┐ ││
│ │ │ To Do │ In Prog│ Review │ Done │ ││
│ │ ├─────────┼─────────┼─────────┼─────────┤ ││
│ │ │ FEATURES ││
│ │ │ [card] │ [card] │ [card] │ [card] │ ││
│ │ │ [card] │ │ │ [card] │ ││
│ │ ├─────────┼─────────┼─────────┼─────────┤ ││
│ │ │ BUGS ││
│ │ │ [card] │ [card] │ │ [card] │ ││
│ │ │ [card] │ │ │ │ ││
│ │ ├─────────┼─────────┼─────────┼─────────┤ ││
│ │ │ TECH DEBT ││
│ │ │ [card] │ │ │ [card] │ ││
│ │ └─────────┴─────────┴─────────┴─────────┘ ││
│ │ ││
│ │ Visual: See balance at a glance ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OPTION 2: COLOR-CODED LABELS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Label colors: ││
│ │ 🟣 Feature (purple) ││
│ │ 🔴 Bug (red) ││
│ │ 🟡 Tech Debt (yellow) ││
│ │ ││
│ │ Quick scan shows color distribution on board ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OPTION 3: SEPARATE BUG BOARD │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Bug Triage Board: ││
│ │ [Inbox] → [Prioritized] → [Ready] → [In Sprint] ││
│ │ ││
│ │ Feature Board: ││
│ │ [Backlog] → [Sprint] → [In Progress] → [Done] ││
│ │ ││
│ │ Cards move from Bug Board to Feature Board when ││
│ │ added to sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Prevention
Quality Gates
PREVENTING BUGS:
┌─────────────────────────────────────────────────────────────┐
│ QUALITY PRACTICES │
├─────────────────────────────────────────────────────────────┤
│ │
│ BEFORE MERGE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ☐ Code review (required) ││
│ │ ☐ Automated tests pass ││
│ │ ☐ Manual testing for UI changes ││
│ │ ☐ Test on staging environment ││
│ │ ││
│ │ Rule: No merge until all boxes checked ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEFINITION OF DONE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Feature isn't "done" until: ││
│ │ ☐ Tests written (unit + integration) ││
│ │ ☐ Documentation updated ││
│ │ ☐ Error handling implemented ││
│ │ ☐ Edge cases considered ││
│ │ ☐ Monitoring/logging added ││
│ │ ││
│ │ In GitScrum: Add DoD checklist to task template ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ REGRESSION PREVENTION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ For every bug fixed: ││
│ │ • Write test that would have caught it ││
│ │ • Add to regression test suite ││
│ │ • Link test to bug task ││
│ │ ││
│ │ "A bug fixed without a test is a bug waiting to return" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘