5 min read • Guide 51 of 877
Balancing Feature Development with Maintenance
Every development team faces the tension between shipping new features and maintaining existing systems. Too much focus on features leads to mounting technical debt; too much maintenance means falling behind competitors. GitScrum helps teams find the right balance.
The Balance Challenge
| All Features | All Maintenance |
|---|---|
| Fast initial progress | Clean codebase |
| Growing tech debt | No new value delivered |
| Slower over time | Stakeholder frustration |
| More incidents | May lose market position |
| Developer frustration | Developer boredom |
Capacity Allocation Strategy
Recommended Splits
ALLOCATION MODELS
═════════════════
HEALTHY SYSTEM (Low debt, few incidents):
├── Features: 80%
├── Maintenance: 10%
├── Tech Debt: 5%
└── Innovation: 5%
MODERATE DEBT:
├── Features: 70%
├── Maintenance: 15%
└── Tech Debt: 15%
HIGH DEBT / MANY INCIDENTS:
├── Features: 50%
├── Maintenance: 25%
└── Tech Debt: 25%
CRISIS MODE:
├── Features: 20% (critical only)
├── Maintenance: 40%
└── Tech Debt: 40%
Sprint Capacity Planning
SPRINT 12 CAPACITY (40 points)
══════════════════════════════
FEATURES (70% = 28 points)
──────────────────────────
#123 User authentication 8 pts
#124 Dashboard widgets 8 pts
#125 API endpoints 6 pts
#126 Mobile navigation 6 pts
MAINTENANCE (15% = 6 points)
────────────────────────────
#127 Upgrade dependencies 3 pts
#128 Fix flaky tests 3 pts
TECH DEBT (15% = 6 points)
──────────────────────────
#129 Refactor auth module 4 pts
#130 Add monitoring 2 pts
Labeling for Visibility
Work Type Labels
LABEL CONFIGURATION
═══════════════════
WORK TYPE:
├── type:feature (green) - New functionality
├── type:maintenance (blue) - Keep systems running
├── type:tech-debt (orange) - Code quality improvements
├── type:bug (red) - Defect fixes
└── type:innovation (purple) - Research, spikes
PRIORITY:
├── priority:critical - Do first
├── priority:high - This sprint
├── priority:medium - This quarter
└── priority:low - When possible
Tracking Allocation
SPRINT ALLOCATION REPORT
════════════════════════
Sprint 11 (Completed)
─────────────────────
Feature: 32 pts (76%) ████████████████░░░░
Maintenance: 5 pts (12%) ██░░░░░░░░░░░░░░░░░░
Tech Debt: 5 pts (12%) ██░░░░░░░░░░░░░░░░░░
Sprint 12 (Current)
───────────────────
Feature: 28 pts (70%) ██████████████░░░░░░
Maintenance: 6 pts (15%) ███░░░░░░░░░░░░░░░░░
Tech Debt: 6 pts (15%) ███░░░░░░░░░░░░░░░░░
Trend: ↑ Increasing maintenance allocation (healthy)
Making Maintenance Visible
Business Value of Maintenance
MAINTENANCE VALUE TRACKING
══════════════════════════
DEPENDENCY UPGRADE (Sprint 12)
──────────────────────────────
Work: Upgrade Node.js 18 → 20
Time: 3 points
Value:
├── Security patches included
├── 15% performance improvement
├── LTS support until 2025
└── Unblocks new library features
Risk if Skipped:
├── Known vulnerability CVE-2024-xxxx
├── Falling behind ecosystem
└── Harder upgrade later
FLAKY TEST FIX (Sprint 12)
──────────────────────────
Work: Fix 5 intermittent test failures
Time: 3 points
Value:
├── CI pipeline reliability
├── Faster feedback loops
├── Developer confidence in tests
└── Reduced false positive investigations
Risk if Skipped:
├── Ignoring real failures
├── Slower CI (more retries)
└── Developer frustration
Protecting Maintenance Time
Sprint Planning Rituals
PROTECTED ALLOCATION PROCESS
════════════════════════════
BEFORE SPRINT PLANNING:
───────────────────────
1. Calculate total capacity
2. Reserve maintenance % FIRST
3. Remaining goes to features
4. Maintenance is non-negotiable
EXAMPLE:
────────
Total: 40 points
Reserved: 8 points maintenance (20%)
Available for features: 32 points
Stakeholder request: 36 points of features
Response: "We can do 32 points of features.
8 points reserved for system health."
Rotation Approaches
MAINTENANCE ROTATION
════════════════════
OPTION 1: Dedicated Sprint
──────────────────────────
Every 4th sprint: 50% maintenance focus
Pros: Deep work, significant improvements
Cons: Feature velocity dip visible
OPTION 2: Per-Sprint Allocation
───────────────────────────────
Every sprint: 20% maintenance
Pros: Consistent progress, smooth velocity
Cons: May not tackle large items
OPTION 3: Maintenance Friday
────────────────────────────
Every Friday: Maintenance only
Pros: Predictable, easy to protect
Cons: Fragmented week
OPTION 4: Rotation Assignment
─────────────────────────────
One person per sprint: maintenance duty
Pros: Deep focus, clear ownership
Cons: Context switching for individual
Metrics for Balance
Health Indicators
SYSTEM HEALTH DASHBOARD
═══════════════════════
INCIDENTS:
├── This month: 3 (target: <5) ✓
├── Last month: 7
└── Trend: Improving ↓
MEAN TIME TO RECOVERY:
├── This month: 45 min (target: <60) ✓
└── Last month: 72 min
DEPLOYMENT FREQUENCY:
├── This week: 8 (target: >5) ✓
└── Lead time: 2 hours ✓
DEPENDENCY AGE:
├── Up to date: 85%
├── Minor behind: 10%
└── Major behind: 5% ⚠️
TECH DEBT RATIO:
├── Debt tasks: 23
├── Total tasks: 156
└── Ratio: 15% (healthy)
Best Practices
For Sustainable Balance
- Reserve capacity explicitly — Don't squeeze maintenance in
- Track allocation — What gets measured gets done
- Connect to outcomes — Show maintenance prevents incidents
- Rotate fairly — Share maintenance across team
- Celebrate improvements — Acknowledge system health work
Anti-Patterns
AVOID THESE:
✗ "We'll do maintenance later"
✗ Maintenance only after incidents
✗ Hidden maintenance (calling it features)
✗ Same person always does maintenance
✗ No tracking of maintenance allocation
✗ 100% feature sprints