How to Handle urgent work in Scrum with Kanban
I often observe that Scrum Teams struggle with unplanned circumstances, leading to the common misconception that the framework lacks the necessary flexibility for actual workplaces. Urgent work is handled ad hoc outside of the standard workflow, with loss of transparency and unnecessary stress. A Kanban Board is then used as an alternative to throw in work items at any moment, without actually trying to limit the workload. Both Scrum and Kanban are actually designed to accomodate urgent items, while making the prioritization choices by the team explicit.
Here is how your Scrum Team can handle urgent items according to the Scrum Guide. I also explain what is recommended when Kanban is incorporated according the Kanban Guide by prokanban.org and the Kanban Guide for Scrum Teams.
Urgent items in Scrum
The Scrum Guide allows for the Sprint Backlog to be updated during the Sprint. The Sprint Goal is the actual commitment against which progress can be measured, not the Sprint Backlog. If an urgent work item is functional to the Sprint Goal, then the Developers are supposed to negotiate the scope of the Sprint Backlog with the Product Owner accordingly.
If the urgent work item is not functional to the Sprint Goal, then it might not be that urgent, as “urgency” implies that the item cannot be delayed. If the Scrum Team determines that the item is urgent despite the Sprint Goal, then the Sprint Goal might be invalid, e.g. due to the Sprint duration being too long. In such situations the Sprint Goal should not be changed, but in extreme cases the Product Owner can cancel the Sprint if the Sprint Goal turns out to be obsolete.
Consequently, a truly urgent work item should always be included in the Sprint Backlog and not be rejected.
Urgent items in Kanban
Handling (exceeded) work in progress Limits
One of Kanban Practices’ is the control of work in progress (WIP), usually implemented as WIP limits. When a Scrum Team using Kanban sets its WIP limits, it should stick to them. As the Sprint Backlog is part of the Definition of Workflow (DoW), adding urgent work items to the Sprint Backlog will affect the work in progress.
If adding the urgent item does not exceed the WIP limit, the team can prioritize it without affecting the workflow. If not, Kanban allows to exceed WIP limits as an exception to the standard workflow.
When to change WIP limits
In general the Definition of Workflow (including WIP limits) can be changed at any time during the Sprint. Still, for a Scrum Team such changes are recommended at the Sprint Retrospective, therefore WIP limits should not be changed during the Sprint when urgent work items arise.
By considering workflow changes just at the Sprint Retrospective (incl. changing WIP limits), the team can focus during the Sprint while allowing for regular inspection and adaptation. As the WIP limits can be exceptionally exceeded, urgent work items can still be prioritized within Scrum’s framework and according to Kanban’s strategy.
Conclusion
Your Scrum Team has options to handle urgent work items. First, consider whether the work item is truly urgent based on the Sprint Goal. If so, then it belongs to the Sprint Backlog through a negotiation between the Product Owner and the Developers.
When Kanban is used, WIP limits may be exceed, as long as the team agrees and acknowledges the exception to the workflow.
However you proceed, consider the chances of inspection and adaptation and ideally address them in the Sprint Retrospective. During the Sprint Retrospective you may also consider changing the WIP limits.
Originally published at https://lucaf.eu on January 5, 2025.
