Tips on setting a Sprint Goal

Just a thought, maybe this exact situation is manifestation of this sentence from the Scrum Guide?

Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.

If I understand you correctly, you are seeking a way how to accomodate your situation in the concept of the Sprint Goal. Isn't that approach only reinforce current setup that clearly limits your ability to focus on the Product?

I believe, that if you try to remain strict in what your product is, and define truly Product Goal and Sprint Goal that reflects what make particural Sprint valuable, then you either will accept your context limitations, or change something to be closer to "the ideal" (whatever that is).

I would argue that now you have transparency over relative efficacy of your current environment - Is this situation sustainable and desired approach in the long run? If not, what can you do to actually change it?

In poland there is a sayin' that roughly translates to: "There is a lot that needs to be changed, so that everything can stay the same", so I would rather avoid seeking how to reflect distractions in the Sprint Goal 😉

In my experience, it's very normal to have work that is not directly related to the Product Goal or the Sprint Goal within a Sprint. Even if you have work in a variety of different areas or supporting different stakeholder objectives, there's still value in having a good Sprint Goal. The primary advantage is that of a focusing tool to ensure that the team keeps their eye on the singular most important thing to enable or deliver over the course of the Sprint.

I'd start by recognizing that the Sprint Goal doesn't need to encompass or include all the Product Backlog Items selected for the Sprint. The Sprint Goal only needs to define the objective that the stakeholders are expecting to see by the conclusion of the Sprint and to review at the Sprint Review. When the unexpected happens - it takes more work than originally thought to complete Product Backlog Items, there is unplanned work, or there is an unplanned reduction in capacity - the team can rethink their work and their plan in terms of maximizing their ability to achieve the Sprint Goal.

A good question for the team to ask at Sprint Planning is: "If everything goes wrong during this Sprint, what is the one most important objective to be able to show to our key stakeholders at Sprint Review?" The answer to that question is a good step toward formulating your Sprint Goal.

To tag on to @Thomas' idea, another question you could ask is "What completed work would we and the stakeholders agree makes this Sprint successful?".   Ask that question before you start pulling Product Backlog items into the Sprint Backlog.  Come up with a goal that supports the product increment that is to be delivered to the stakeholders at the end of the Sprint.  Then pull enough items from the Product Backlog into the Sprint Backlog to support that goal.  If there are other items that also need to be done but don't support the Sprint Goal, it is up to the Developers to decide if they can also do that work.  At that point, negotiation with the Product Manager (as the stakeholders' representative) ensue. 

I have only seen a Sprint Backlog where everything in it supports the Sprint Goal a few times.  Consider that the Developers have every intention to complete everything that they pull into the Sprint Backlog.  But that doesn't mean the goal is to complete everything.  It is to complete something that delivers a Product increment of value to the stakeholders. 

@Piotr makes a great point.  I often say "Don't try to force the process to satisfy the situation.  Let the situation force the process to satisfy the need."  You will get better results in the long run.   

Some practical aspects of Sprint Goal creation that have helped my teams in the past:

• It is important for Sprint Goals to be direction-oriented and not destination-oriented.   When we include the ‘what’ (i.e. – milestones, deliverables) in our Sprint Goals, we tie ourselves to specific outcomes and reduce our ability to adjust our work mid-sprint (agility).
  
  
  
  Think in terms of taking a road trip from NY to LA.   We can painstakingly map out a specific route, risking that such efforts are likely wasteful and the route we end up taking will vary significantly from what we mapped out (traffic, accidents, construction, etc), or we can be comfortable with simply heading ‘west’, knowing that direction will get us closer to LA

• Begin Sprint Goal statements with an action verb that represents the value being delivered, like ‘Add’, or ‘Reduce’, or ‘Improve’, or ‘Eliminate’.   Avoid statements like “Continue…”, or “Begin…”, as they don’t support either value or delivery

• To me, use of the word ‘and’ in a Sprint Goal statement is a red flag and shouldn’t be allowed.   It contradicts the Scrum value of ‘focus’, facilitates context switching between goals, and promotes confusion and waste around what is most important.   Overall, it represents an inability on the part of the Product Owner and/or organization to prioritize

• Think in terms of elevator statements.   Present the scenario that team members find themselves in an elevator with their CEO, who turns to them and asks “So, what are you working on?”.   What is one sentence that can summarize the most valuable aspect of what the team will be delivering at the end of the sprint?

A hot topic in my team is how to set Sprint Goals

It doesn't sound very hot. You never mentioned commitment even once, and that's what a Sprint Goal is. So, regardless of whatever work might be at hand, what commitment are the Developers realistically prepared to make?