Features vs Maintenance | 70/30 Capacity Allocation

Allocate 70-80% to features and 20-30% to maintenance using GitScrum's sprint planning. Labels track work types. Reports show allocation across categories for sustainable delivery.

5 min read

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