Sprint Goal Clarity

A Sprint Goal makes the selection of work coherent. It represents an opportunity to mitigate a significant risk or uncertainty each Sprint which makes the selection of work more than the sum of its parts. It gives the Developers a reason to work together, and provides advantage when developing a complex product in which more is unknown than is known.

What you're describing sounds like a missed opportunity to do the above, and to thereby innovate. What isn't clear is whether or not innovation is a pain point. Is there a clear need to innovate in your situation and to implement the Scrum framework?

Your Sprint Goal does not have to unify all of the work that the team is doing over the course of the Sprint. I find it helpful to think of the Sprint Goal is a focusing tool. The team can use the Sprint Goal to stay focused on the most important outcome to enable before the end of the Sprint.

For example, if the most important thing to do is "make checkout easier" (although I'd expect a bit more specificity), then that becomes your Sprint Goal. If the team needs to make decisions about which pieces of work to do, then part of the decision is made for them. Completing any Product Backlog Items that "make checkout easier" would be more important than completing any Product Backlog Item that does not "make checkout easier". The Developers have some freedom and flexibility in the work that they do if they learn that "make checkout easier" requires more work than anticipated or if there is an unexpected/unanticipated reduction in capacity.

Sometimes rethinking the overall approach to the given product development is needed in order to benefit from Scrum Goals/Value oriented approach. 



The stage in which the given product is in the product life cycle has an impact. If you are at the beginning of the journey and there is a lot of unrealized value, there are many ways possible to increase the product value through proper Sprint Goals setting. If the product is close to its journey and we are delivering improvements here and there on the customer request, the Sprint Goal becomes as simple as "keep the customers stick to the product"

What is the Product Owner's view on this? What is the answer when you ask "Why are we doing this Sprint, what Value will be generated"?

Per Scrum Guide: "The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders"

To me what you described sounds a lot like when developers work on something by themselves and pick items that they want to work on instead of a team working together to produce an usable increment of valuable product change. 

The purpose of the Sprint Goal is to help the Developers focus on the most important part of the Sprint. I agree with @Thomas that the Sprint Goal does not have to relate to everything in the Sprint Backlog but it should relate to the majority of the items selected for the Sprint.  Merriam-Webster provides this definition for the word goal: "the end toward which effort is directed". The Cambridge Dictionary provides this: "a purpose, or something that you want to achieve". While you might say that what you want to achieve is to finish all the items in the Sprint Backlog, the purpose of the Sprint Goal is to identify what is most important to achieve so that it is easier to determine anything that will distract from that.  Some work may be done that does not relate to the Sprint Goal but that should be minimal.

In amongst those different pieces of work, there has to be a number 1 priority.

Imagine that this was the last Sprint for the product and you could complete only one value producing objective. What would it be? That should be the Sprint Goal.

That could involve 1 backlog item or many, but it is the must have objective and focus for the Sprint.

Developers could still pull in other backlog items if they determine they have capacity to do so, but those are secondary to the Sprint Goal and should not detract from the Sprint Goal. 

You dont overcome it by finger slip. The whole purpose of Scrum is to create environment where teams inspect themselves and improve important aspects of their work.

Your situation is simple: sprint goal was not set properly at the planning. Which is not a drama or some unrepairable failure. Team, PO and developers at the first place should try to change the scope of work and definition of done so Sprint goal would be met by the end of the sprint, and at least one increment of value would be born, then ise retrospective to adress this.

Or if its not possible and you are certain that team cant achieve Sprint goal , let PO cancel this Sprint. The new one starts immedeately, and you can set better Sprint goal at the Sprint planning...