Escalation
Avi Siegel
•
5 min read
What is escalation?
Escalation is a process used on Agile teams where work items are elevated in priority and brought into the current sprint outside of the normal Sprint Planning process. This typically occurs when urgent issues arise that simply cannot wait until the next sprint to be addressed.
While escalation should be used sparingly to maintain team productivity and sprint integrity, it’s an essential mechanism for handling truly critical issues that require immediate attention.
What is the goal of escalating a specific task?
The primary goals of escalation are to:
Quickly address urgent issues that pose significant risk or impact to the business
Maintain customer satisfaction by quickly resolving critical problems
Allow the team to respond to genuine emergencies through a formal framework that prevents the practice from becoming overly prevalent and more broadly disrupting the entire sprint process
What is involved in the escalation process?
When an issue arises that may require escalation, several steps should be taken to ensure the process is handled appropriately and doesn’t unnecessarily disrupt the team’s ongoing sprint work.
Evaluate urgency
Carefully assess whether the issue truly warrants immediate attention. Consider such factors as:
Churn & revenue: If the issue isn’t resolved quickly, will customers churn? How many? How much MRR or ARR does that churn represent?
User type: Does the issue impact end-users vs. internal users? Free vs. paying customers? Users specifically being onboarded? Offboarded?
Number of affected users: How many users are experiencing the issue right now? How many users will likely experience the issue in the immediate future?
Impact: What does the issue prevent users from doing? How important is that for their workflow? How important is that for their business?
Workarounds: Is it possible for users to work around the issue? Is it obvious how they could do so? Is it easy to do so, or unreasonable and thus unrealistic to expect of users?
Security concerns: Is private customer data exposed? Is that exposure actively being taken advantage of?
Regulatory compliance: Is the issue preventing you from abiding by PII regulations? HIPAA? GDPR?
Long-term ramifications: How much more difficult would it be to address the issue later vs. now? What additional issues will arise if the problem remains unaddressed for too long?
Escalate issue (if applicable)
If an issue is deemed urgent enough to escalate it into the current sprint, move forward with the escalation process.
Move the task into the current sprint within your task management software of choice
Discuss the issue with the team
Assign the work to the appropriate person
Track the completion of the escalated work
Communicate progress and resolution to any relevant stakeholders
Document & communicate
Regardless of whether an issue results in escalation or not, ensure that all decisions are documented and communicated. This will ensure that everyone is aware of the current state of affairs, expectations are managed, and information is recorded for future reference.
Document the reason for escalation (or lack thereof)
Inform all relevant stakeholders about the change in priorities (or lack thereof)
Record progress and completion of the work (whether it was resolved during an escalation or during normal sprint work)
Who is responsible for escalations?
There are two main parts of the escalation process - deciding whether to escalate, and executing work against the escalation. As far as the escalation decision is concerned, that should be left to a small group of key team members to ensure quick decision-making while maintaining appropriate oversight and adequately balancing options. The work to address an issue itself, of course, is handled by individual members of the team.
The following individuals should be involved:
Product manager (PM): Continuously monitors for potential escalations via the triage process, and evaluates business impact and prioritization of escalation that arise
Engineering manager (EM): Assesses technical implications and context, as well as (rough) effort estimation and resource availability
Engineering team: Addresses the issue at hand and keeps the rest of the team apprised of status and progress
How should the team prepare for escalations?
While escalations are by nature unexpected and thus unplanned, teams can still prepare for them in several ways.
Product manager
The PM should:
Establish clear criteria for what constitutes an escalation-worthy issue - note that this may be done through collaboration with other team members, and in the case of larger Product teams may be owned more by Product team leadership or Product Ops
Maintain strong relationships with stakeholders to properly gauge urgency
Track escalation patterns to identify systemic issues (and weigh the option of prioritizing deeper solutions to resolve underlying problems, when necessary)
Engineer manager
The EM should:
Understand team capacity and current sprint commitments to know where there is wiggle room if an escalation were to occur
Maintain familiarity with different engineers’ differing skill sets, so as to innately understand which engineers would be most effective at handling a given escalation
Monitor team morale and burnout, especially during periods of frequent escalation (and work with the PM to address recurring problems when possible)
Engineering team
Engineers should:
Document their current work sufficiently so others can pick it up if necessary (this holds true in the case of escalations, but also in cases of other circumstances such as unexpected out-of-office time)
Keep technical debt manageable to reduce the likelihood of emergencies (although note that this is truly an ongoing conversation with the broader team of the tradeoffs between code quality and speed of delivery)
Be prepared (and willing) to context switch when truly urgent issues arise
Best practices for escalations
Deeply consider the need for escalation. Every escalation disrupts the team’s flow and impacts productivity. Reserve escalations for truly urgent issues.
Formalize the escalation process. Create a formal document that outlines criteria, procedures, and communication channels. This helps maintain consistency, manage expectations, and reduce confusion during high-pressure situations.
Learn from patterns. Regular escalations in a particular area of the product may be indicative of underlying problems that should be addressed. A bigger lift in the short term can easily pay for itself in the long term. Weigh the options accordingly.
Document everything. Keep clear records of what was escalated, why, and the impact on prior sprint commitments. Similarly, record reasons when it is decided not to escalate a given issue.
Review deeper causes in retrospect. The moment in time when an escalation occurs is not the time to argue why it occurred (beyond technical reasons of course). Reserve this conversation either for the next Retrospective ceremony, or (for bigger issues like downtime) for specific retrospectives tied to the issue at hand. When you do have this conversation, identify improvement opportunities so that deeper issues can be prioritized against the broader roadmap.