High Priority Items in the Backlog not related to the Sprint Goal

There's nothing that says that all selected Product Backlog Items need to directly relate to the Sprint Goal. In fact, the Sprint Goal should inform the selection of the Product Backlog Items and the prioritization of the work so that, by the end of the Sprint timebox, the Sprint Goal has been achieved.

In the case of something being more important than the Sprint Goal at the time of the Sprint Planning, I would question if the Sprint Goal was correct to begin with. Perhaps the Sprint Goal should be focused around the most important work, with supporting work brought in to support the capacity of the team.

Remember the purpose of the Sprint Goal is to allow the Development Team to focus on the most important objective to deliver value to stakeholders at the end of the timebox. It's not necessarily a summary of the Product Backlog Items selected for the Sprint, or even a subset of the Product Backlog Items.

"Most of the high priority items should be aligned with achieving the sprint goal. But it's quite often the case that some high priority items are unrelated to the goal and that's ok."

However, he never mentions what happens in this case:

It’s possible for a team to define “priority” in such a way that this might be true. The Scrum Guide says:

“The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.”

Thomas and Ian, thank you for your comments!

@Ian: Ok, it's clear that there should always be included a "Kaizen" that derives from the retrospective. However, it is not a work item from the product backlog but as stated it is created in the retrospective. Therefore, a Kaizen is a process improvement, but is not part of the increment. However, I refer to PBIs that are not process improvements but nevertheless not related to the sprint goal.

@Thomas: Sorry, the concept of the sprint goal still is a little bit blurry for me. Let's make an example. The mentioned PBIs might be not too realistic with regard to size, however, it's just an example:

Here is the Backlog of an online shop:

1. Implement payment functionality with visa card

2. Implement payment function with PayPal

3. Improve search functionality: items can be searched now by color

4. Implement payment function with American Express

The team now selects the first 4 PBIs from the product backlog. The sprint goal is named "Implement payment functionality", because after this sprint you will be able to pay with Visa, Amex and PayPal. PBIs 1, 2, and 4 relate to the sprint goal, PBI 3 does not. Would that be an ok-sprint-goal? 

It could be a good Sprint Goal, if the team have the policies and practices to support it.

Let’s assume all 4 items are considered to be “high priority”. What should the team understand this to mean, given that only 3 items articulate to the Sprint Goal, and must receive appropriate focus and commitment so the Goal is met? What would the team’s policies and practices then be, with regard to how prioritization of the 4 items ought to be handled?

@Thomas: Sorry, the concept of the sprint goal still is a little bit blurry for me. Let's make an example. The mentioned PBIs might be not too realistic with regard to size, however, it's just an example:

Here is the Backlog of an online shop:

1. Implement payment functionality with visa card

2. Implement payment function with PayPal

3. Improve search functionality: items can be searched now by color

4. Implement payment function with American Express

The team now selects the first 4 PBIs from the product backlog. The sprint goal is named "Implement payment functionality", because after this sprint you will be able to pay with Visa, Amex and PayPal. PBIs 1, 2, and 4 relate to the sprint goal, PBI 3 does not. Would that be an ok-sprint-goal? 

During Sprint Planning, the Development Team believed that they could complete all 4 items with a reasonable level of confidence. However. during the course of the Sprint, something happened and they could no longer complete all four items. It could be anything from underestimating the work for one or more of the items to a reduction in capacity or anything else. The team knows that they cannot complete all four goals.

Ideally, the Sprint Goal will help to maintain focus. Of course, the Product Owner can also help to make tradeoff decisions. But what if a decision needs to be made and the Product Owner isn't available? The Sprint Goal's purpose is to guide the Development Team on why it is building the increment. If the Sprint Goal is to "implement payment functionality", I would expect the Development Team to focus on 4 over 2 - it's clear that the desired state at the end of the Sprint timebox is more payment functionality.

I think that it's important to remember that the point of the Sprint is not to implement Product Backlog Items. It's to deliver value. There may be lots of important things, but you can't always get to all of them. Sometimes, a cohesive delivery of backlog items of different priority makes more sense than just pulling the most important items because it adds the most product value within your timebox and lets you learn or sets you up for success with other items.

Thank you so much to both of you for your explanations!