Unrelated deliverables within the Sprint: Sprint goal question

A question the Scrum Team should be able to answer in Sprint Planning is what is THE most valuable outcome we could achieve to get a step closer to the Product Goal. Sprint Goal is singular - it tells us what is important now, and what isn't as important.

Not every PBI selected for the Sprint Backlog has to align perfectly with the Sprint Goal. But if a PBI has to be dropped, it should come from functionality C. Or if someone working on functionality C needs to pitch in to help the team meet their Sprint Goal, then that should be expected. 

The Sprint Goal is the glue that binds the team together rather than just a group of people. This is what I've done in the past. Ask the Developers to have two separate teams focus on their own Sprint Backlogs/Sprint Goals. And each team would have their own focused Daily to inspect their progress towards the Sprint Goal and adapt their plan (the Sprint Backlog).

A Sprint Goal is "the single objective for the Sprint" that "provides flexibility in terms of the exact work needed to achieve it".

Sprint Goals around delivering specific functionality are not good Sprint Goals. If the commitment is made to deliver functionality, that is often overly restrictive on the work that needs to happen.

A good Sprint Goal is also a single objective. I like to describe it as a focusing tool. What happens if, due to unexpected and unforeseen events, the team simply cannot deliver functionality A, B, and C within the Sprint timebox? How does the team know what the singular most important thing to achieve is? The Sprint Goal answers this question, so when the unplanned happens, the team is able to make informed decisions about how to achieve the most value with the time and resources at their disposal.

The other three will work on functionality C which is not related to goal XYZ. However, this functionality is important and must be delivered within the next sprint as well.

You'd have stopped having a Scrum Team at that point, because the teamwork will have gone. People are now working on different things with different goals. That's the truth being exposed.

Perhaps they should self-organize into different teams to reflect that new reality. Each could then craft its own Sprint Backlog and Sprint Goal. They'll have to self-manage any integration dependencies.

If you're talking about a one-off piece of work that doesn't really justify a new team, and the one-offs keep happening, then perhaps the product is really a service. Sprint Goals might then relate to predictability and flow and to service level expectations, rather than to particular features.

Not every PBI selected for the Sprint Backlog has to align perfectly with the Sprint Goal. But if a PBI has to be dropped, it should come from functionality C. Or if someone working on functionality C needs to pitch in to help the team meet their Sprint Goal, then that should be expected.

I agree with the above comment from @Chris. If you set goals based on features then you will end up having multiple sprint goals (and I have worked with teams who do it this way). Prioritizing is the key so that the team is aware what is the most important thing to be delivered and the entire team irrespective to who is working on what will be available to support in fulfilling the most important tasks first.

Also I have worked in teams where in your scenario we would draft a sprint goal around A and B. In the sprint review item C will be called out as an additional task completed (due to bandwidth available) and if it is Done then it could also be included in the review. 

Perhaps they should self-organize into different teams to reflect that new reality. Each could then craft its own Sprint Backlog and Sprint Goal. They'll have to self-manage any integration dependencies.

@Ian In our scenario, we have a team of seven full-stack developers. During a particular sprint, we needed to split them into four sub-teams: two developers tackled sprint goal A, three focused on goal B, and one developer each took on goals C and D.

The third and fourth teams were unable to swarm because of their small size. However, we had to adopt this approach due to the simultaneous expected release date, which was crucial for establishing a strategic partnership—a significant move for a startup to gain market leverage.

But during Sprint Retrospective we're agreed to transfer the knowledge by rotating and pair-programming, is this ok?

 

Sprint Goals around delivering specific functionality are not good Sprint Goals. If the commitment is made to deliver functionality, that is often overly restrictive on the work that needs to happen.

I have similar thoughts right now, especially when thinking about SMART-Criteria and how they can provide enough flexibility in regard to the scope of work of the sprint:

A Sprint Goal is "the single objective for the Sprint" that "provides flexibility in terms of the exact work needed to achieve it".

If the Sprint Goal is too specific in terms of functionality, it could result in taking shortcuts in regard to quality to fulfill the functionality. 

Again, these are my thoughts in the moment: When it comes to Functionalities und User Value, I tend to somehow stress these in the Product Goal, keeping those SMART and clear on what we're going to complete in the next few sprints. 
With the Sprint Goals, I try to find ways to provide more flexibility, while providing safe orientation when it comes to priorities. 

The reason is that the Scrum Guide uses the words "User" oder "Customer" with the Product Goal, and uses "Stakeholders" with the Sprint Goal.