Defining the sprint goal when working on different components

So I try to get the know transfer done.

Has the team considered Sprint Goals for achieving that knowledge transfer?

The Scrum Guide says this about the Sprint Goal:

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

I tend to think about the Sprint Goal as a guide toward what value the Scrum Team should deliver in the Sprint to one or more external stakeholders. It helps guide the team when selecting Product Backlog Items at Sprint Planning. It helps the team focus their planning at the Daily Scrum and throughout their daily work. The team can inspect and determine if it has been achieved at the Sprint Review. Although there may be unrelated work in the Sprint Backlog, when the unexpected comes up, the team can look toward the Sprint Goal to figure out what is most important to the stakeholders and maximize the value of their work, without needing to consult with the Product Owner or the stakeholders directly.

My initial idea would be that the idea of defining the Sprint Goal related to the most important work in the Sprint, even if that's one component, would be a good idea. Achieving this Sprint Goal could be completing just one of the Product Backlog Items selected for the Sprint.

However, Ian Mitchell's idea about making knowledge transfer the goal of the Sprint is allowed for. Prior to the November 2020 revision of the Scrum Guide, the Sprint Goal was an objective that was met "through the implementation of the Product Backlog". This was removed in the 2020 revision, making it simply an objective for the Developers to achieve.

There's even an opportunity to combine these two approaches. Since the team wishes to cross-train each other across the product, the goal could involve a combination of the most important work and cross-training at least one member of the team on the component where this most important work lives. Since the Sprint Review is designed to inspect the product as well as "individuals, interactions, processes, tools, and their Definition of Done", both the work itself and the newly developed knowledge of individuals and how their interactions in cross-training adds value for the team and the stakeholders.

Thanks for the input. We already had an initial knowledge transfer already as a first steps. As the two components uses another programming language, this is for me an ongoing topic and I would not set the knowledge transfer as a permanent sprint goal.

Maybe, it is more that I struggle a bit the the word sprint goal. As it is formulated as singular the team cannot define the one and only sprint goal. We look at the planning to the backlog and select the most valuable items, but in a second step, when coming to the sprint goal, there is rarly a common ground for one sprint goal. So we have then more sprint goals.

Is this a misinterpretation of the sprint goal in the Scrum guide on my part, that there has to be only one sprint goal?

there is rarly a common ground for one sprint goal

Without that, is there a common ground for your Team to Sprint at all? What makes their effort coherent, so they work on shared rather than separate initiatives?

A Sprint Goal can be any such coherence, including knowledge transfer.

If there can only one thing happen during your sprint, what should it be? That is most likely your Sprint Goal.

IMHO the problem is that Sprint Goal is treated as something that must include everything and that is wishful thinking - there is a whole bunch of work and activities that won't connect to that - support, maintenance, bugs or security issues discovered on production, to name a few.

It might be helpful to check those parts of Scrum Guide (2020):

"The Scrum Team commits to achieving its goals and to supporting each other."

ST commits not only to the goal(s).

"Their primary focus is on the work of the Sprint to make the best possible progress toward these goals."

usage of the word primary may be a clue that there are other things that requires our focus, but primarily we should focus on the work of the Sprint.

"The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives."

Sprint Goal is here to guide the team to make better decisions day by day, to encourage them to focus primarily on work needed for the Sprint Goal. In your context it may be something like that (one Developer could say on Daily):

"I would not start working on this component (PBI), as this is not helpful for us to meet the Sprint Goal, it won't move us forward, and it creates more work in progress that will drain our focus, so as I have lack of domain knowledge, I can focus on gaining it or on pairing with someone else with coding or testing. Either way In my opinion it is the best action that I can take to help the team and gain more domain knowledge in the long run. Do you have any other proposition?"

Maybe I just misinterpreted the guide as I interpreted the guide to have only one sprint goal

(The Sprint Goal is the single objective for the Sprint)

but as I get from you answers that is also valid to have several goals. Is this correct?

IMO in the context of Sprint, you have only one Sprint Goal, however, that does not mean that you can not have other things to do - you can and they may even be important, but you should strive to pay primary focus at the Sprint Goal.

Like almost everything, it is a very context heavy topic that depends on your unique situation so various tactics can be applied by the team in order to be effective, in general in my opinion it boils down to things like:

• Asking for help
• Offering help
• Going out of the way

Imagine a PC war or strategy game, during the course of the game you have a series of missions, each having each own primary goal with a set of objectives to accomplish, however, there are often side-objectives that if not fulfilled will not impacts achievement of the main goal. When the game unfolds you make decisions with the primary goal in mind and sometimes "make sacrifices".

I hope that it is a good metaphor, but I try also to base on your example:

Imagine that you have a goal in mind like "Increase stability of X on the Android platform". That is what you would like to take as the Sprint Goal. When you go through Sprint Planning with that goal in mind it results in selecting "stories" (PBIs) that touches mostly one component (based on your example). You also forecast some other "stories" disjointed from the Sprint Goal that touches this second component that you mentioned - and that is perfectly fine. These not related things are just side-objectives at best. Knowing and having a single Sprint Goal the team will be able to make a tough decision to drop extras if it will be necessary.

Hope this help :)

Imagine a PC war or strategy game, during the course of the game you have a series of missions, each having each own primary goal with a set of objectives to accomplish, however, there are often side-objectives that if not fulfilled will not impacts achievement of the main goal. When the game unfolds you make decisions with the primary goal in mind and sometimes "make sacrifices".

great sample (as I like strategy games :) ) and finally I think, I get the node out of my brain. The primary goal with a set of objectives is in detail the same as the "goals" for the sprint.