01
Urgency describes pressure
Urgency records the stakeholder’s time constraint and why it exists. A launch, campaign or executive commitment can make a small issue urgent without changing its technical nature.
Acknowledging urgency matters. Letting it silently redefine impact or effort creates bad commitments.
02
SLA describes business impact
SLA classification asks whether core functionality, a key page or a key integration is prevented or severely impaired. A workable alternative can reduce the response class even when the issue remains important.
This gives incident coverage a stable rule instead of making it depend on who asks most forcefully.
03
Complexity describes engineering uncertainty
Complexity captures systems involved, familiarity, blast radius and failure modes. A trivial code change can take time when repeated widely. A complex change can still be non-urgent.
Keeping complexity separate improves assignment, review depth and QA planning.
04
Make the delivery call last
Only after the three signals are visible should the team choose response time, owner, scope and release path. Borderline calls should state the neighbouring classification and the argument for it.
Triage becomes a decision record rather than a label attached to a task.