Handling outside teams intruding on your Sprint?

Does the Product Owner consider this work to be valuable, and does he or she order it on the Product Backlog accordingly?

The Scrum Guide says: "The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team."

Even outside of Scrum and agile methods, ad hoc requests, and especially urgent ad hoc requests, can be highly disruptive to teams. However, a key principle of Agility is regular and frequent collaboration throughout the project. Elements of Scrum provide the framework to enable this collaboration with outside stakeholders.

First, I would suggest that the Scrum Master work with the IT/Infrastructure team to help them understand the nature of Agility and Scrum. Understanding Agility and Scrum, along with effective ways to engage with the team can help to form a good working relationship between the Scrum Team(s) and the IT/Infrastructure team.

In practice, I would suggest a conversation about the lead time for these requests. I would start with proposing a lead time of 2x or 3x the team's Sprint length, to the extent possible. If the team is using 2 week Sprints, as an example, knowing 4-6 weeks in advance of a server decommissioning or upgrade would allow the team to plan and incorporate this into their work or raise any concerns regarding the schedule and sort it out. However, the team should also recognize that not all work can be planned in advance. Some updates and patches, especially for security issues and vulnerabilities, may need to be done quickly. The end goal should be to provide sufficient notice to enable planning as often as possible. The Product Owner is likely a good candidate to understand when the IT/Infrastructure team needs to do their work, its impact on the Product Backlog, and how the work would affect the team's ability to deliver to other stakeholders.

It could also be beneficial to invite a representative of the IT/Infrastructure team to the Sprint Review. This can give some additional visibility into how the team is using the infrastructure maintained by the team and the overall nature of the work the team is doing with respect to business goals and external stakeholder deliveries. This information can be used by the IT/Infrastructure team as an input to their planning of infrastructure operations activities.

I think Thomas and Ian have made some great points, but I'm going to be the one to say the simple thing that seems to be often avoided. 



Say no. Whether that's you as SM protecting the team, the PO as the owner of the product backlog, or the developers themselves as the owners of the sprint backlog. 



The problem is that these external teams are making you bear the brunt of their lack of planning and foresight, and so you can make that transparent by saying no, and seeing what happens next. 



Undoubtedly, some might suggest that any negative outcome is your teams fault, but it's your role as an SM from that point to help people understand the need for ongoing planning and collaboration, which they will now be much more likely to buy in to having actually felt the impact of ignoring it. 



That said, don't let the platform or product burn in order to do this. It's not about spite, it's about making the effects visible. So wait for something that won't end the world to come along, and put it into practice.  

If you can imagine this, I agree with all 3 of the previous answers.  As a Scrum Master, you are responsible for helping the entire organization understand and appreciate the Scrum framework.  That includes how for those not using the Scrum framework to work with those that are.  By helping others understand empirical process and decision making, it will help them to better appreciate how it helps.  In the case where teams are not using empiricism in their processes, they need to understand why others do.  While agility is about a company's/team's ability to adapt to change quickly, it does not eliminate the need for looking ahead to potential needs.  What your IT team is exhibiting is the inability to adequately refine their work.  If they were, they would be able to forecast the potential dependencies and provide your team with prior knowledge of the need for their involvement. 

@Micheal has a point that I like to make with this statement.  Sometimes, pain is a great way to learn that you are doing things wrong.  If IT expects you to drop everything for them, they need to learn that you have other work that is more important to the business than their decommissioning of a server.  They have to learn that your team works based upon prioritization of work based upon what delivers the most value to the stakeholders.  And if something that the IT group asks for is less valuable, it will be dealt with when it becomes the most valuable.  

But as others pointed out. You do not want to be the team that becomes known as uncooperative.  It is usually fairly easy to slip in some lower priority work if it is known about ahead of time and can be adequately scoped for level of effort.  Cooperate with them but don't bow to their demands as they are only 1 of your stakeholders. 

Thank you so much! I'm the Product Manager, btw, but have shared with our Scrum Master.  This information helps us a lot!