Defining the sprint goal when working on different components

Last post 12:16 am January 14, 2021
by Thomas Owens
2 replies
Author
Messages
09:08 am January 13, 2021

Hi,

my team is new on Scrum working on one product, which contains two components. For some stories, working cross functional works perfect as we have to touch both stories. Then it is easy to define the sprint goal.

However, most of the stories only touch one component and as there the know how transfer is just starting, we add a separate stories for each component. So I try to get the know transfer done.

My problem is then, that the definition of a common sprint goal is getting difficult as the team focus on two "goals" - on the first and on the second component. Do you have any ideas? What do you think about to the idea to define the sprint goal for only the component, which is most important in the sprint?

Thanks for any input!

Martin  

10:15 pm January 13, 2021

So I try to get the know transfer done.

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

12:16 am January 14, 2021

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.