Please enlighten me regarding "Sprint Goal"

> While reviewing Scrum Guide, I got stucked at comprehending
> what is a Sprint Goal and how is defined.

The Product Owner is responsible for ordering the Product Backlog, and for negotiating the highest ranking items into the next Sprint Backlog with the rest of the team. At the end of the Sprint, the increment that is delivered should be potentially releasable.

This means that the Product Owner should only agree to a Sprint Backlog if it would result in a increment of value that is suitable for release. In other words, there would have to be something that binds the selected Sprint Backlog items together into a sensible aggregation of releasable work. The Scrum Guide refers to that binding as a "coherence". If you understand what makes an increment coherent, you'll have an idea of what the Sprint Goal should be.

> Once the Scrum Team selects and forecasts the Product Backlog Items,
> do they just define a business/abstract goal for this Sprint?

They could indeed do that, if it binds the selected items together into the "coherence" the guide refers to, and if the resulting increment would be sensible and valuable enough to release.

> What should be the resulting Sprint Goal? Maybe provide "X", "Y", "Z"
> functionality? Or more abstract such as "Enhance Aplication's features"?

Not to provide "X", "Y", or "Z" functionality, because that would lack the all-important coherence. On the other hand, enhancing an application's features is almost certainly too abstract, because it says nothing about the value that is unique and specific to the envisaged release. A business goal that was a bit more concrete, such as "enhance order querying features", or even "enhance the application's features for potential release to customer X" would perhaps be more viable.

Thanks Ian.

In my example I had imagined the customer / Product Owner to request several unrelated enhancements to the application, as such, slightly "incoherent".
Given that, what should be the Scrum Goal when the PO just wants to rise overall productivity?
Maybe the goal should be "Raise the productivity in 'A', 'B', 'C' tasks"?

> ...what should be the Scrum Goal when the PO just wants to rise overall productivity? 

That's a good question, though unfortunately I can't say there's a clear answer. Strictly speaking, a PO who only wants to increase overall productivity isn't doing their job properly. They should be willing and keen to agree clear sprint goals of business value, and which mitigate clear areas of business risk. Improving productivity is arguably more of the Development Team's concern.

If business risk is low, and there are genuinely no clear sprint goals to be had, then there is no point in batching work into sprints. You might as well run a Lean Kanban operation whereby each discrete piece of ticketed work is expedited as quickly as possible. You can then focus on improving value throughput and cycle times. This is typical of how non-project BAU work is often conducted.

In practice though, there are very few genuine cases of negligible business risk, even in an operational BAU context. Usually a failure to articulate clear sprint goals is a training issue, and has more to do with weak product ownership than the nature of the problem domain.

Thanks for your input.

It was my mistake to apply pure Scrum in Business As Usual context, since Scrum was designed for complex system / projects.

Thanks again for your valuable clarification.
Regards