How do I (as a Product Owner) handle "urgent requests" (usually from people with high political power) in Scrum?
This is one of the most common questions I receive from participants attending Professional Scrum Product Owner (PSPO) courses.
Before I share how to handle "urgent requests," let's revisit the fundamentals of Scrum. In Scrum, there are two types of backlogs: the Product Backlog and the Sprint Backlog. The Sprint Backlog contains the work the Developers have forecasted for the Sprint, and the Developers are accountable for managing it. All of the work that the developers are not working on in the current Sprint is stored in the Product Backlog, the Product Owner is accountable for managing it.
Please note that the 'urgent requests' I am referring to here are not defects or show-stopping production incidents. In some cases, an 'urgent request' often refers to what someone in the organization considers a great idea that needs to be implemented by the developers immediately within the current Sprint. However, keep in mind that not every 'urgent request' should be added to the Sprint Backlog. What may seems to be 'urgent' can often wait and be stored in the Product Backlog for future consideration.
As a Product Owner, if you want to slip in an "urgent request" into the Sprint Backlog, you must consult the Developers, as they own the Sprint Backlog and are accountable for it. Involve them in a discussion and seek their feedback instead of unilaterally slipping in the "urgent request" into the Sprint Backlog. As a Product Owner you need to know that introducing an "urgent request" into the Sprint Backlog without consulting the developers first can be disruptive. It may break the Developers' morale and erode their trust in the system and even in the Product Owner. If it becomes the norm, it may even cause apathy in the future.
The first step the Product Owner needs to take is to assess whether the request aligns with the current Sprint Goal. However, based on my experience, most 'urgent requests' are unrelated to the Sprint Goal. They often come from individuals who are detached from the Scrum Team's way of working. In many cases, those people are not even aware of what a 'Sprint Goal' is, and sometimes, they don’t bother to learn about it.
If the request does not align with the Sprint Goal, I use a tool called the Financial Impact vs. Reputational Impact Matrix. As a Product Owner, I want the impact or potential damage to the company to be visualized in two dimensions so that I do not make decisions based on a single factor. The main purpose of this tool is to quantify the urgency of those "urgent requests." As a Product Owner, we do not want our team to work based on opinions or, even worse, political power; we want them to work based on facts or quantifiable data.
Many Scrum Teams order their Product Backlog based on value, often using potential revenue or cost savings as value attributes. Unlike potential revenue or cost savings, which are expressed in positive terms, financial impact and reputational impact are typically considered in negative terms. If the impact is not negative or cannot be quantified, as a Product Owner, I would not consider the request urgent. Instead, it can be deferred and stored in the Product Backlog for further discussion at a later time. Such items should not be added to the current Sprint Backlog.
I do acknowledge that some Scrum practitioners argue that once Sprint Planning has concluded, no further changes should be made to the Sprint Backlog by individuals outside the team. However, if an 'urgent request' could harm the company both financially and reputationally, and this impact can be quantified, I believe it would be unprofessional to rigidly adhere to theoretical principles. In such cases, Scrum values take precedence over strict adherence to theory, specifically, the value 'respect.
The financial impact should be measurable in monetary terms. When an 'urgent request' is presented, the Product Owner should ask the requester, 'How much money will we lose if we don’t address this "urgent request" now?' Often, this figure is known upfront. For example, if the "urgent request" is not addressed in the current Sprint, the company might lose $100,000 every minute until it is resolved. A real-world example is the CrowdStrike-related IT outages that occurred in 2024, where the financial impact on CrowdStrike customers was quantifiable in monetary terms. In such a scenario, it cannot wait for the next Sprint. In some cases, the financial impact also includes compounding interest, which further increases the financial impact until the "urgent request" is addressed.
Unlike financial impact, reputation impact refers to the potential damage to the company's reputation if the request is not addressed starting from the current Sprint. This could include a loss of trust from partners or customers, or even the loss of a license to operate from the government. While reputation impact can often be measured in monetary terms, it is sometimes hypothetical or intangible. Some reputation impacts are also only visible in the long term and not immediately, like what happened to Boeing due to the flawed design of their MCAS system or like what happened to Volkswagen due to DieselGate. From my experience, this is what makes quantifying reputational impact quite tricky. As a Product Owner, do your best to work with the requestor to quantify the reputation impact before bringing this "urgent request" to the developers.
Take note that what constitutes "high" or "low" impact varies by company. For some companies, a financial or reputation impact of $100,000 might be considered high, while for others, it might be low. There is no absolute or definitive number for what constitutes "high" or "low." Work together with people in the company to identify the threshold for low and high impact.
If an 'urgent request' has both a high financial impact and a high reputational impact (2), I would include it in the Sprint Backlog (after a discussion with the developers of course). Requests with a high financial impact but low reputational impact (1), or a high reputational impact but low financial impact (4), may either be stored in the Product Backlog or added to the current Sprint Backlog. The Product Owner and Developers should analyze these requests together before deciding whether it should be placed in the Product Backlog or the Sprint Backlog. In most cases, requests with low financial impact and low reputational impact (3) can wait and should be stored in the Product Backlog.
When an 'urgent request' is added to the Sprint Backlog, both the Product Owner and Developers must work together to manage expectations. The Product Owner should also communicate with the stakeholders, even before the Sprint Review, as some items initially planned for the Sprint may not be completed as a result. During the Sprint Review, the Product Owner should be able to explain to the stakeholders why the 'urgent request' was included in the Sprint and why some of the initially planned items were not completed.
So, that’s the mechanism I use to handle 'urgent requests' as a Product Owner. Let me know how this approach works for you or if you encounter any challenges. Remember, just because someone in the company claims something is 'urgent' doesn’t necessarily mean it truly is. Work together with the Developers and embody the Scrum value "respect". And as a Product Owner, always make decisions based on facts and data, not opinions and political power.