Creation of a Sprint Goal if a team has multiple areas of focus

Hi Conor,

The purpose of the sprint goal is to create a clear direction for a sprint. It helps to make sure everybody has the same part of the product on his mind (both scrum team and stakeholders) so improves collaboration, but also helps the developers in deciding on what has the highest priority to work on among others

If you have multiple sprint goals you will lose these benefits, so if at al possible I would recommend trying to get the PO to formulate a single clear goal for each sprint.

What I usually propose if a teams maintains multiple products is to choose one that has the priority each sprint. You can create a goal for that product and let the developer determine the work needed to get to that goal as usual.

In order to minimize the idle time for some projects you can shorten the sprints or maybe you can allocate a part of the dev teams time to "maintenance work" so small but urgent matters can always be dealt with quickly.

Of course another option could be to just split up the team if you have enough developers and let each govern their own product. Probably other people have more ideas, in the end I would recommend discussing some options you like with the team and let them decide what they think would work best.

I have a couple of questions since you state that the team is responsible for a "platform" that is comprised of multiple "products".  Is there truly multiple products in the platform? Or is the platform a product of it's own.  The Scrum Guide provides this definition of a Product in the section that describes the Product Backlog:

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

If your organization feels that all of the components of the platform are so intertwined that one team should be responsible for all of the work, then maybe for the purpose of the Scrum framework, your "platform" is a product. Even if you each component can be installed and used without the others, to the organization, the platform is the value that is delivered to the stakeholders.

If you take that approach, then the Scrum Guide starts to shine new light on your situation.  In that same section of the Scrum Guide, this is stated.

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

Getting a good Product Goal can help the team and stakeholders to better understand the work that will be done by the Scrum Team.

Now, considering that your "platform" is the Scrum Product, crafting a Sprint Goal becomes a different experience.  Instead of seeing work done in a Sprint as enhancing ComponentA, ComponentC, and ComponentF, you can instead craft Sprint Goals that explains why the changes to those 3 components are valuable to the stakeholders. 

In the Scrum Guide section that explains Sprint Planning, the Sprint Goal is described as 

The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

For example, consider that the platform is Inventory Management. You might have what you call an Inventory Catalog, Shipping/Receiving, and Inventory Replenishment products. Each could be sold individually but the real value is having all of them to work together.  For a given Sprint, you could pull items from the Product Backlog that creates enhancements across all 3 products or that focus specifically on a single one.  The Sprint Goal that you craft will explain why and what work that is contained in the Sprint Backlog is most important to the stakeholders and needs to be completed in the Sprint.  There is no where in the Scrum Guide that states all of the items in the Sprint Backlog is required in order to achieve the Sprint Goal. Only that the Sprint Goal communicates why the Sprint is valuable to the stakeholders and that there is work included in the Sprint Backlog to support the Sprint Goal. 

The Scrum Guide defines a framework using some specific terminology.  However, those terms do not have to equate to terminology used by your organization.  For example, the individual that fulfills the responsibilities and accountabilities of the Scrum Product Owner does not have to have a tile of Product Owner.  Same goes for Scrum Master and Developers.  It is quite common for someone that fulfills the role of Developer will have titles like Software Engineer, UX Designer, Quality Assurance Engineer.  

Don't get to obsessed with making the terms used in the Scrum Guide equal to the terms used by your organization.  Read the Scrum Guide in the context that is provided and then equate the information to how your organization operates.

In the event that a Scrum Team is responsible for the running of a platform which is comprised of multiple Products how best to go about the creation of a single Sprint Goal?

That running of a platform sounds like it might be a service to me. Assuming it is a complex one and worth applying Scrum at all, what risks and uncertainties might there be around predictability and flow? A useful Sprint Goal could be the meeting of a certain Service Level Expectation, for example.