All elements of the Scrum framework play a role in enabling empirical process control. Sprint Goal is a commitment that reinforces empiricism, however, it remains a part of Scrum which often is being neglected or causes challenges to many Scrum Teams.
Recently I've come across a blog post questioning the necessity of using Sprint Goals as there may be situations where the Sprint Goal doesn't bring value. According to the author, it depends on the context where the team operates, so the Scrum team may decide to jettison the Sprint Goal as it doesn't help. The case illustrating this type of situation described a Scrum team working on the Sprint Backlog of an incohesive set of PBIs: a part of the project for one client, enhancements, fixing bugs for another client etc. Indeed, it's not a mystery why the team struggles to come up with a meaningful Sprint Goal. But does it support the idea that the Sprint Goal doesn't serve its purpose or it's a symptom of something else?
First of all, what's the impact of dropping the Sprint Goal? The team considers the Sprint Backlog as the objective denying a complex nature of knowledge work, so either we're successful when delivering the entire Sprint Backlog or we fail. Experience says it wouldn't be possible to deliver everything we've planned, so how can we decide on what should be in focus - an enhancement, a bug fix or a new feature? Going with this notion reduces the purpose of Scrum to a work management approach where the work is broken down into small pieces to get better visibility of its execution.
The Sprint Goal enables focus on value for the customers and end-users beyond the immediate output, it drives outcomes so the value is maximised.
What options does a Scrum team have to reap the benefits of Scrum? Here are some questions for reflection to explore the team's context.
[1] What is the optimum length of Sprint in your context?
One of the possible reasons why teams have Sprint Backlogs encompassing PBIs pulling them into different directions is that the Sprint length is too long. In this case, the team pulls PBIs to fill up the capacity available which leads to a laundry list of items having some clusters of disconnected (and different) values.
Reducing the Sprint length will create a focus for the team and enable the team to gain useful feedback earlier.
[2] Do you (really) have a Product?
A perception that Scrum is a team-forming framework causes an interesting phenomenon when organisations 'Scrumify' their structure without paying attention to what the purpose of those teams is. As the Scrum guide points out to the PRODUCT Backlog and the PRODUCT Owner it is a reasonable starting point to ask "What are the product boundaries? Who are the stakeholders and users?" before forming the team. Otherwise one might end up in a situation when the team is not actually a team, it's a group of individuals collected together without clear purpose and identity.
Establish product definition and its vision allows making informed decisions on including or excluding work from the Product Backlog.
[3] Does your Product Backlog ordered for value or it's a queue of requests?
Another reason why teams encounter complications to formulate the Sprint Goal is that their Product Backlogs are not organised or managed to enable value delivery. The Product Backlog of such teams rather looks like a to-do list replenished by the stakeholders, customers, users.
Product Owners maximise value. It doesn't mean they are order-takers. Embracing a visionary or entrepreneurial stance help Product Owners truly own their product making decisions on what is valuable and what is not.
These three reasons why teams struggle to formulate the Sprint Goal are not an exhaustive list. As rules of Scrum provide "safety guardrails" to the teams to be successful in the world of complexity, one should be aware that Scrum doesn't solve problems but points to them so they can be addressed.