Why Does Scrum Recommend Defining the Sprint Goal Before Selecting PBIs?
According to the Scrum Guide 2020, can you explain why it's recommended to choose the Sprint Goal first and then select the Product Backlog Items (PBIs)? I find this difficult to understand because, in my view, it’s easier to define the Sprint Goal based on the PBIs. In the context of my project, PBIs are mostly related to developing features, making improvements, or fixing bugs. My PBIs are not very detailed at first, as the developers are responsible for refining them technically once they begin working on them.
For example, let’s say the Product Goal is to make the tool more user-friendly. To support that, I might create a PBI like ‘Modify the file import screen to make it easier for users.’ So, for me, it’s challenging to define the Sprint Goal without first reviewing the PBIs. What do you think?
You have it backwards. The Sprint Goal does not support the contents of the Sprint Backlog. The contents of the Sprint Backlog support the Product Goal. To use your example.
In order to make a tool more user-friendly, there are a number of things that can be done. You could provide an ability to increase font size for people that are sight impaired. You could provide the ability to change the font. You could provide the ability to use a different language. You could make items easier to find. There are many things. But if none of these needs already exist in the Product Backlog, why would you do them? The Product Backlog contains all work needed to improve the Product. A Sprint is a timeboxed period of effort by the Developers to do work that is represented in the Product Backlog. The Sprint Goal helps the Sprint Team focus on the work that is important for the Sprint. The Sprint Goal helps the Developers to choose work that supports the next goal for the Product. However, no where in the Scrum Guide does it state that the Sprint Backlog contains only work that supports the Sprint Goal. It might be necessary to include some work, such as technical debt, in a Sprint in order to make it possible to accomplish other work that is in the Product Backlog. That work could be pulled into the current Sprint by the Developers so that they can address other work in later Sprints. But that work may not satisfy the goal of making the tool more user-friendly. And if there is a risk to completing the work that supports the Sprint Goal, the technical debt work can be put back into the Product Backlog.
You seem to assume that all the work in a Sprint Backlog has to be associated to a single effort. That is not necessarily the case. By creating a Sprint Goal first, the Developers are allowed to pick work that supports it and if there is available capacity, they can fill it with other work.
BTW, your example of making a tool more user-friendly could be extremely large in effort and could be setting the Developers up for failure. It would depend on the tool.
According to the Scrum Guide 2020, can you explain why it's recommended to choose the Sprint Goal first and then select the Product Backlog Items (PBIs)?
It doesn't say that. It doesn't make any such recommendation at all. The Scrum Guide does say that Sprint Planning addresses three topics, but they are not necessarily performed in any sort of sequence.
I have worked with teams that draft a sprint goal after selecting PBIs for the sprint based on the product goal. Like @Daniel mentions, there will be tasks in the sprint backlog which may not be directly related to the sprint goal (some ad-hoc items which need to be prioritized). The purpose of having a sprint goal is to bring about a focus for the team, something against which you can track your progress during the daily scrum and the team can decide on what tasks to do and not to do.
An interesting question. At first glance, teams usually select items from the top of a prioritized product backlog. Always working on the highest priority items is a key principle of Scrum.
However, hypothetically speaking (without confirming the Scrum Guide first), selecting the Sprint Goal first can give the team direction on which items to choose. It can be helpful to first decide what the team aims to accomplish and then pick the appropriate backlog items. Put another way, at the start of planning use several criteria to select the items, for example: the goal (what do we want to achieve), the priority (as determined in the backlog), the size (what can fit into the sprint), technical availability, and potentially more.