11 min read • Guide 128 of 877
Handling Urgent Requests Without Derailing Plans
Urgent requests threaten team focus and sprint commitments when every new ask gets treated as an emergency. Without a system to evaluate and handle interruptions, teams either reject legitimate urgent work (damaging stakeholder relationships) or accept everything (missing sprint goals). GitScrum's flexible workflows and visibility features help teams distinguish real emergencies from regular priority requests and handle both appropriately.
The Urgency Problem
Why Everything Seems Urgent
URGENCY INFLATION:
┌─────────────────────────────────────────────────────────────┐
│ THE "EVERYTHING IS URGENT" PATTERN │
├─────────────────────────────────────────────────────────────┤
│ │
│ TYPICAL WEEK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Monday: ││
│ │ Sales: "Customer needs this feature urgently" ││
│ │ CEO: "We need to fix the homepage by Wednesday" ││
│ │ ││
│ │ Tuesday: ││
│ │ Support: "Critical bug affecting 3 customers" ││
│ │ PM: "Investor demo moved up, need changes ASAP" ││
│ │ ││
│ │ Wednesday: ││
│ │ Sales: "Different customer threatening to cancel" ││
│ │ Marketing: "Campaign launch needs integration TODAY" ││
│ │ ││
│ │ Thursday: ││
│ │ CEO: "Actually, mobile is more important now" ││
│ │ Support: "Another critical bug" ││
│ │ ││
│ │ Friday: ││
│ │ Everyone: "Why didn't we finish the sprint work?" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ THE PROBLEM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ When everything is urgent: ││
│ │ • Nothing is prioritized ││
│ │ • Sprint goals become meaningless ││
│ │ • Team burns out from context switching ││
│ │ • Paradoxically, urgent things don't get done well ││
│ │ • Quality drops as everything becomes a rush job ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Urgency Classification
Defining True Emergencies
URGENCY MATRIX:
┌─────────────────────────────────────────────────────────────┐
│ CLASSIFYING INCOMING REQUESTS │
├─────────────────────────────────────────────────────────────┤
│ │
│ CLASSIFICATION CRITERIA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 🔴 EMERGENCY (Drop everything): ││
│ │ • Production system down ││
│ │ • Security breach active ││
│ │ • Data loss occurring ││
│ │ • Legal compliance deadline (actual, not perceived) ││
│ │ • Revenue-blocking bug for major customer ││
│ │ ││
│ │ Characteristics: ││
│ │ → Has measurable immediate impact ││
│ │ → Delay costs more than interruption ││
│ │ → Can be fixed in hours, not days ││
│ │ ││
│ │ 🟡 URGENT (This sprint, reprioritize): ││
│ │ • Bug affecting many customers (workaround exists) ││
│ │ • Deadline-driven request (real external deadline) ││
│ │ • Blocker for another team ││
│ │ • Customer escalation with retention risk ││
│ │ ││
│ │ Characteristics: ││
│ │ → Significant impact but not catastrophic ││
│ │ → Can wait hours/days but not sprint ││
│ │ → Requires scope trade-off ││
│ │ ││
│ │ 🟢 IMPORTANT (Next sprint): ││
│ │ • Feature request from sales ││
│ │ • "Nice to have" for upcoming deadline ││
│ │ • Improvement requests ││
│ │ • Stakeholder preference ││
│ │ ││
│ │ Characteristics: ││
│ │ → Valuable but not time-critical ││
│ │ → Requestor wants it now, not needs it now ││
│ │ → Can be planned properly ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Questions to Determine Urgency
URGENCY FILTERING:
┌─────────────────────────────────────────────────────────────┐
│ ASKING THE RIGHT QUESTIONS │
├─────────────────────────────────────────────────────────────┤
│ │
│ QUALIFYING QUESTIONS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. "What happens if we don't do this today?" ││
│ │ → If answer is vague, it's not an emergency ││
│ │ ││
│ │ 2. "What's the specific deadline and what creates it?" ││
│ │ → External deadline (contract): legitimate urgency ││
│ │ → Internal deadline (preference): can be negotiated ││
│ │ ││
│ │ 3. "How many users/customers are affected?" ││
│ │ → 1 customer: Evaluate importance of customer ││
│ │ → Many customers: Higher urgency ││
│ │ ││
│ │ 4. "Is there a workaround?" ││
│ │ → Yes: Not an emergency, urgent at most ││
│ │ → No: Higher urgency ││
│ │ ││
│ │ 5. "What's the revenue/cost impact per day of delay?" ││
│ │ → Forces concrete thinking about actual urgency ││
│ │ → "Big impact" without numbers = not quantified ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EXAMPLE CONVERSATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sales: "We need feature X urgently for customer Y" ││
│ │ ││
│ │ Team: "What happens if we can't deliver it this week?" ││
│ │ Sales: "They might go with a competitor" ││
│ │ Team: "When do they need to make a decision?" ││
│ │ Sales: "They said by end of month" ││
│ │ Team: "So we have 2 weeks, not 2 days?" ││
│ │ Sales: "Well, yes, but earlier would be better" ││
│ │ ││
│ │ Result: IMPORTANT, not URGENT. Schedule for next sprint.││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
GitScrum Configuration
Handling Urgent Work
WORKFLOW FOR URGENT REQUESTS:
┌─────────────────────────────────────────────────────────────┐
│ MANAGING INTERRUPTIONS IN GITSCRUM │
├─────────────────────────────────────────────────────────────┤
│ │
│ URGENT REQUEST WORKFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. CREATE TASK WITH LABEL ││
│ │ ││
│ │ Title: "[URGENT] Production login failing" ││
│ │ Labels: urgent, production, bug ││
│ │ Priority: Critical ││
│ │ ││
│ │ 2. ADD TO SPRINT (if mid-sprint) ││
│ │ ││
│ │ Move to current sprint ││
│ │ Track as interruption ││
│ │ ││
│ │ 3. DOCUMENT DISPLACEMENT ││
│ │ ││
│ │ Comment on displaced task: ││
│ │ "Moved to next sprint due to urgent: [link to issue]"││
│ │ ││
│ │ 4. TRACK TIME SEPARATELY ││
│ │ ││
│ │ Use time tracking for urgent work ││
│ │ Enables measuring interruption cost ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LABEL SYSTEM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ urgent/emergency - Drop everything (red) ││
│ │ urgent/this-sprint - Needs to fit in sprint (orange) ││
│ │ urgent/next-sprint - Important, can wait (yellow) ││
│ │ urgent/declined - Requested urgent, not urgent ││
│ │ ││
│ │ Track "urgent/declined" to identify requestors who ││
│ │ frequently overstate urgency ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Capacity Buffer
PLANNING FOR INTERRUPTIONS:
┌─────────────────────────────────────────────────────────────┐
│ INTERRUPT CAPACITY │
├─────────────────────────────────────────────────────────────┤
│ │
│ BUFFER CAPACITY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sprint planning approach: ││
│ │ ││
│ │ Total team capacity: 160 hours (8 people × 20h sprint) ││
│ │ ││
│ │ Reserved for planned work: 128 hours (80%) ││
│ │ Reserved for interrupts: 32 hours (20%) ││
│ │ ││
│ │ Sprint commitment sized to 80%, not 100% ││
│ │ ││
│ │ If no interrupts occur: ││
│ │ → Pull stretch goals or next sprint items ││
│ │ ││
│ │ If interrupts exceed buffer: ││
│ │ → Trade off planned items explicitly ││
│ │ → Document for retrospective ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TRACKING INTERRUPT TIME: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Time tracking labels: ││
│ │ ││
│ │ time/planned - Planned sprint work ││
│ │ time/interrupt - Urgent interruptions ││
│ │ time/support - Support escalations ││
│ │ time/meetings - Meetings and ceremonies ││
│ │ ││
│ │ Dashboard view: ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ Sprint Time Breakdown: │ ││
│ │ │ │ ││
│ │ │ Planned work: ████████████████████░░░ 72% │ ││
│ │ │ Interrupts: ██████░░░░░░░░░░░░░░░░░ 18% │ ││
│ │ │ Support: ██░░░░░░░░░░░░░░░░░░░░░ 6% │ ││
│ │ │ Meetings: █░░░░░░░░░░░░░░░░░░░░░░ 4% │ ││
│ │ │ │ ││
│ │ │ Interrupt trend: ↗ 5% higher than average │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ Use this data to adjust planning and identify patterns ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Communication Framework
Responding to Urgent Requests
HANDLING REQUESTS DIPLOMATICALLY:
┌─────────────────────────────────────────────────────────────┐
│ RESPONSE TEMPLATES │
├─────────────────────────────────────────────────────────────┤
│ │
│ FOR GENUINE EMERGENCIES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Understood. We're reprioritizing now. Sarah will ││
│ │ pick this up immediately. We'll have to defer [X] ││
│ │ to next sprint to make room. I'll update you in ││
│ │ 2 hours with progress." ││
│ │ ││
│ │ Key elements: ││
│ │ • Acknowledge urgency ││
│ │ • State who's on it ││
│ │ • Name the trade-off explicitly ││
│ │ • Set expectation for update ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FOR URGENT BUT NOT EMERGENCY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "I understand this is important. Let me check our ││
│ │ sprint commitments. We can either: ││
│ │ ││
│ │ A) Fit this in by moving [X] to next sprint ││
│ │ B) Start this Monday as first item next sprint ││
│ │ ││
│ │ Which works better for your timeline?" ││
│ │ ││
│ │ Key elements: ││
│ │ • Validate the request ││
│ │ • Offer options with trade-offs visible ││
│ │ • Give requester agency in decision ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FOR NOT ACTUALLY URGENT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Thanks for bringing this up. Based on the timeline ││
│ │ (end of month decision), we can plan this properly ││
│ │ for next sprint starting Monday. This gives us time ││
│ │ to do it well rather than rush and risk quality. ││
│ │ ││
│ │ I've added it to the backlog and we'll prioritize ││
│ │ in Thursday's planning session." ││
│ │ ││
│ │ Key elements: ││
│ │ • Use their own timeline against false urgency ││
│ │ • Frame delay as quality benefit ││
│ │ • Provide visibility into when it will be addressed ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
On-Call Rotation
Dedicated Interrupt Handler
INTERRUPT DUTY:
┌─────────────────────────────────────────────────────────────┐
│ SHIELD THE TEAM │
├─────────────────────────────────────────────────────────────┤
│ │
│ ROTATION SYSTEM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Weekly rotation: ││
│ │ ││
│ │ Week 1: Sarah - interrupt handler ││
│ │ Week 2: Mike - interrupt handler ││
│ │ Week 3: Alex - interrupt handler ││
│ │ Week 4: Lisa - interrupt handler ││
│ │ ││
│ │ Interrupt handler responsibilities: ││
│ │ • First responder for support escalations ││
│ │ • Triage incoming urgent requests ││
│ │ • Handle small fixes that come up ││
│ │ • Shield rest of team from interrupts ││
│ │ ││
│ │ Planning adjustment: ││
│ │ • Interrupt handler gets 50% less planned work ││
│ │ • Rest of team can focus without interruption ││
│ │ • One person context-switches instead of everyone ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ESCALATION PATH: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Level 1: Interrupt handler evaluates ││
│ │ ↓ ││
│ │ Level 2: If beyond handler, escalate to tech lead ││
│ │ ↓ ││
│ │ Level 3: If beyond tech lead, all-hands emergency ││
│ │ ││
│ │ Most "urgents" resolved at Level 1 ││
│ │ Occasional real emergencies reach Level 2-3 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘