Handle Urgent Requests | Buffer Capacity
Manage unplanned work with buffer capacity, interrupt lanes, and escalation policies. GitScrum helps teams respond to emergencies without breaking sprints.
10 min read
Every sprint faces unexpected urgent requests that threaten planned work. GitScrum provides interrupt handling mechanisms including buffer capacity planning, dedicated interrupt lanes, and escalation workflows that let teams respond to emergencies without completely derailing sprint commitments.
The Interruption Problem
Unmanaged urgencies destroy productivity:
- Sprint failure — Cannot complete planned work
- Context switching — Developers lose flow constantly
- Estimation breakdown — Plans become meaningless
- Team burnout — Constant firefighting exhausts teams
- False urgencies — Everything becomes "urgent"
- No predictability — Stakeholders lose trust in delivery
GitScrum Interrupt Handling Solution
Build systems that absorb unexpected work:
Key Features
| Feature | Interrupt Use |
|---|---|
| Buffer capacity | Reserve sprint capacity for unknowns |
| Interrupt lanes | Dedicated board columns for urgent work |
| WIP limits | Prevent overload during interrupts |
| Labels/priorities | Clear urgency classification |
| Automations | Route urgent work appropriately |
Buffer Capacity Planning
Sprint Capacity Structure
Sprint Capacity Planning:
Total Available Capacity: 100 story points
Allocation:
├── Committed Sprint Work: 75 pts (75%)
│ └── Planned features and improvements
├── Buffer for Interrupts: 15 pts (15%)
│ └── Expected urgent requests, bugs, support
└── Slack/Learning: 10 pts (10%)
└── Tech debt, exploration, training
Sprint Planning Guidance:
"Don't commit more than 75 points.
Reserve 15 points for expected interrupts.
If interrupts exceed buffer, drop lowest
priority committed items."
Buffer Sizing by Team History
Interrupt Analysis: Last 6 Sprints
Sprint │ Interrupts │ Points │ % of Capacity
──────────┼────────────┼────────┼──────────────
Sprint 18 │ 4 items │ 12 pts │ 12%
Sprint 17 │ 7 items │ 18 pts │ 18% ← Major incident
Sprint 16 │ 3 items │ 8 pts │ 8%
Sprint 15 │ 5 items │ 14 pts │ 14%
Sprint 14 │ 4 items │ 11 pts │ 11%
Sprint 13 │ 3 items │ 9 pts │ 9%
Average: 12 pts per sprint (12%)
Recommended buffer: 15 pts (provides margin)
Adjust if:
├── High interrupt sprint → Increase buffer
├── Low interrupt sprint → Keep buffer, use for debt
└── Consistent pattern → Consider permanent allocation
Interrupt Lane on Board
Board Configuration
Kanban Board with Interrupt Lane:
┌─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐
│ Backlog │ INTERRUPT │ In Progress │ Review │ Done │
│ │ 🔴 │ │ │ │
├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤
│ Sprint work │ URGENT: Fix │ Feature A │ Feature B │ Feature C │
│ planned │ payment bug │ (planned) │ (planned) │ (planned) │
│ │ │ │ │ │
│ Feature D │ │ INTERRUPT: │ │ INTERRUPT: │
│ Feature E │ │ Security │ │ Hotfix │
│ │ │ patch │ │ deployed │
└─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘
WIP Limit: 2 (Interrupt column)
Rule: Interrupt work gets dedicated developer
Visualization: Different color/label
Interrupt Classification
Urgency Classification System:
🔴 P0 - Critical (< 1 hour response)
├── Production down
├── Security breach active
├── Data loss occurring
├── Payment system broken
└── Action: All hands, drop everything
🟠 P1 - High (< 4 hours response)
├── Major feature broken for many users
├── Significant revenue impact
├── Important client escalation
└── Action: Designated interrupt handler
🟡 P2 - Medium (within sprint)
├── Feature broken for some users
├── Workaround exists
├── Client request with deadline
└── Action: Add to sprint if buffer allows
🟢 P3 - Low (next sprint)
├── Minor issues
├── Nice-to-have requests
├── General improvements
└── Action: Backlog for prioritization
Interrupt Handler Role
Rotating Interrupt Duty
Weekly Interrupt Rotation:
Week 1: @alice (primary), @bob (backup)
Week 2: @bob (primary), @carol (backup)
Week 3: @carol (primary), @dave (backup)
Week 4: @dave (primary), @alice (backup)
Interrupt Handler Responsibilities:
├── Monitor #support-engineering channel
├── Triage incoming urgent requests
├── Handle P0/P1 immediately
├── Shield rest of team from interrupts
├── Document interrupt patterns
└── Sprint capacity: 50% (planned work)
Benefits:
├── One person context switches (not whole team)
├── Fair rotation of interrupt burden
├── Protected time for focused work
└── Clear ownership of urgent issues
Handler Sprint Allocation
Interrupt Handler Week:
@alice Sprint 19 Allocation:
├── Sprint committed work: 0 pts
│ └── Not assigned planned work
├── Interrupt capacity: 50% (~20 hrs)
│ └── Handle all urgent requests
├── Support/documentation: 30% (~12 hrs)
│ └── Write runbooks, improve docs
└── Flexible: 20% (~8 hrs)
└── Tech debt, learning, help team
If no interrupts occur:
├── Work on tech debt backlog
├── Improve monitoring/alerting
├── Write documentation
└── Pair with team on complex work
Escalation Policies
Clear Escalation Path
Escalation Matrix:
Issue comes in via:
├── Slack #support → Triaged by support team
├── PagerDuty → Goes to on-call engineer
├── Client email → Account manager evaluates
└── Internal request → Requester creates ticket
Escalation Flow:
1. Support creates ticket with urgency assessment
2. Interrupt handler reviews within SLA:
├── P0: Immediately (< 15 min)
├── P1: < 1 hour
├── P2: < 4 hours
└── P3: Next business day
3. Handler confirms or adjusts priority
4. Handler assigns or adds to sprint
5. Resolution tracked in ticket
Auto-Escalation Rules:
├── P0 unacknowledged > 15 min → Page backup
├── P1 unacknowledged > 1 hr → Page backup + manager
└── Any issue open > SLA → Notify manager
Stakeholder Communication
Interrupt Request Template:
When requesting urgent work:
Subject: [URGENT P1] Payment failing for enterprise accounts
What's happening:
Enterprise customers seeing payment errors since 2pm
Impact:
- ~50 affected customers
- $20K potential revenue at risk
- 3 customer complaints received
Workaround:
Manual payment processing available (slow)
Requested action:
Fix payment integration within 4 hours
Requested by: @sarah (Account Manager)
Approving manager: @mike (VP Sales)
---
Response from Engineering:
Acknowledged: 2:15pm by @alice
Current status: Investigating
ETA: Diagnosis within 30 min, fix within 2 hrs
Updates: Every 30 minutes in #incident-payment
Managing Sprint Impact
When Buffer Exceeds
Buffer Exceeded Protocol:
Situation: 20 pts of interrupts, 15 pts buffer
Options:
1. Extend sprint work → Risk burnout, quality issues
2. Drop lowest priority items → Maintain sustainability
3. Request additional help → If available
4. Negotiate scope → Reduce interrupt scope if possible
Decision Framework:
├── Can we reduce interrupt scope? → Try first
├── Is overtime sustainable (rare)? → Short term only
├── What can we drop? → Discuss with PO
└── Do we need help? → Escalate to management
Communication to Stakeholders:
"We received 33% more urgent requests than planned.
To maintain quality, we're deferring Feature E to
next sprint. All urgent items will be resolved."
Sprint Adjustments
Mid-Sprint Adjustment Meeting:
When: Buffer exceeded by 50%+
Who: Scrum Master, Product Owner, Team Lead
Agenda:
1. Review interrupt volume and impact
2. Assess remaining sprint capacity
3. Decide what to defer
4. Communicate to stakeholders
5. Document for retrospective
Example Decision:
Sprint 19 Mid-Course Correction:
├── Original commitment: 75 pts
├── Interrupts received: 22 pts (over 15 pt buffer)
├── Adjusted capacity: 75 - 7 = 68 pts
├── Deferred: Feature E (8 pts) → Sprint 20
└── New commitment: 67 pts (achievable)
Stakeholder notification sent ✓
Preventing False Urgencies
Urgency Validation
Before Accepting P0/P1:
Validation Checklist:
□ Is production actually impacted?
□ How many users affected?
□ What's the business impact ($)?
□ Is there a workaround?
□ Can it wait until tomorrow?
□ Who approved the priority?
Red Flags (likely not urgent):
├── "The client is upset" (without production impact)
├── "We promised this feature" (not urgent, poor planning)
├── "It's been broken for weeks" (not suddenly urgent)
├── "I need it for a demo" (personal urgency, not business)
└── No manager approval on priority
Response:
"I understand this is important. Based on our
criteria, this is a P2 (Medium). It will be
addressed within this sprint. If you believe
it's truly P0/P1, please get VP approval."
Tracking Urgency Patterns
Monthly Interrupt Report:
Total Interrupts: 24
By Priority:
├── P0 Critical: 2 (8%)
├── P1 High: 6 (25%)
├── P2 Medium: 10 (42%)
└── P3 Low: 6 (25%) ← Shouldn't be interrupts
By Source:
├── Customer reports: 10 (42%)
├── Internal requests: 8 (33%)
├── Monitoring alerts: 4 (17%)
└── Sales escalations: 2 (8%)
By Category:
├── Bugs: 12 (50%)
├── Feature requests: 6 (25%)
├── Support questions: 4 (17%)
└── Security: 2 (8%)
Insights:
├── 25% of "urgent" requests were not urgent
├── 50% are bugs → Need better QA
├── Same system caused 4 incidents → Needs refactor
Actions:
├── Tighten P3 acceptance criteria
├── Invest in payment system stability
└── Add monitoring for top incident categories
Team Standup Integration
Interrupt Status in Standup
Daily Standup with Interrupts:
@alice (Interrupt Handler):
"Handling: 2 active interrupts
- P1 Payment bug: 60% done, ETA 2pm
- P2 Export issue: Queued, starting after P1
Buffer used: 8/15 points
Buffer status: Healthy ✓"
@bob:
"Feature A: On track, no blockers
Not taking interrupts this week"
@carol:
"Feature B: In review
Heads up: May need help if more P1s come in"
Scrum Master notes:
├── Buffer healthy, sprint on track
├── Watch payment bug progress
└── Carol flagged as backup if needed
Interrupt Retrospective
Sprint Retrospective: Interrupt Analysis
What Happened:
├── 4 P1 interrupts (above average)
├── 1 P0 incident (production outage)
├── Buffer exceeded by 5 points
├── Deferred 1 feature to next sprint
What Went Well:
├── Interrupt handler role protected team
├── P0 resolved in 45 minutes
├── Clear escalation worked
└── Stakeholders understood deferral
What to Improve:
├── 2 P1s were actually P2 (over-escalated)
├── No runbook for payment issues → Create one
├── Monitoring didn't catch issue early → Improve
└── Buffer was too small → Increase to 18 pts
Action Items:
├── [ ] Create payment system runbook
├── [ ] Add monitoring for payment gateway
├── [ ] Review urgency criteria with sales
└── [ ] Increase buffer to 18 pts next sprint