Sprint Goal with Unrelated Objectives

Hello!

You have listed three products, which would typically be addressed in three product backlogs, three Scrum Teams, etc. The convergence of these into one, while possible, has challenges including the multi-focus one that you have identified.

That being said, I don't read the Scrum Guide as prohibiting this, as long as the Scrum Team crafts the Sprint Goal, understands it, and had a plan that they continually adapt in order to meet it.

However, there is a cost to focusing on many disparate items. When I have seen Sprint Goals as you describe, the Development Team is less productive as they are not able to focus on a cohesive goal - individually or as a team. Sometimes, part of the team chooses to focus on one part of the Sprint Goal while another part is focused on another, which can lead to lack of helping each other out to complete the whole Sprint Goal.

A few ways I have worked with teams to handle this:
- Find a goal that binds them all together. Might not be possible, but it's worth a try.
- Pick the most important part and make it the Sprint Goal. This can lead to discussions about why the rest of the Sprint work isn't focused on that Goal, which is exactly the point of pushing in this direction...try to get to one focus.
- Craft the Sprint Goal with three points, and carefully observe...you are VERY likely to see the Development Team able to deliver less effectively. Retrospect and adapt to improve.

Hope that helps!
Mark

> How does a team craft a sprint goal when the
> product owner gives unrelated objectives?
> For example; enhance the UI in one product,
> fix bugs in another and improve performance
> in a third.

Why is the PO representing 3 different products to the same team? How are the products related?

The three products are related to the success of the overall project. A typically project consist of multiple products interacting to provide value to the business. In the beginning we started with a single sprint goal. As we progressed PBIs were created to enhance/fix existing features while new PBIs we created to move the project forward.

Is focusing on a single goal more important than the priority of the backlog?

More importantly how do you get the Scrum team to focus on a single goal?

If three products articulate into a single Product Backlog, this implies a larger encompassing product and not merely a project.

Where there are three discrete products there must be three Product Backlogs, regardless of how those products interact. No Development Team should work on more than one product in any one Sprint and their Sprint Goal should focus on that product.

Each Development Team's Sprint Backlog should therefore be drawn from only one Product Backlog. However, integration work with other products should be taken into account during Sprint Planning, if such work is required for the increment to be release-ready.

If there is only one Development Team available to service all three products, they may work on each, in rotation, in successive Sprints. Sprint lengths may be shortened to facilitate a timely release cycle.

I have a similar issue with a stack of several web apps to maintain, with not enough items in each for one "2-pizza" sized team.
The organization has create one team of 6 people to maintains 4 products.
It comes with a lot of difficulties to order the Sprint Backlog, but it seems better than 4 "teams" of 1 or 2 people without any swarming.

Now, they have 3 weeks sprints, sometimes with a focus on only 1 product, sometimes not.
As Ian suggest, I'll try to make them try shorter and more focused sprint.

If would have to craft a Sprint Goal from the three objectives you describe: " enhance the UI in one product, fix bugs in another and improve performance in a third", given the fact that these are three product that are closely related and together deliver value for the business ("A typically project consist of multiple products interacting to provide value to the business"), I would go for the common abstraction of where the three objectives are about the same again.
In this case something like "Improve the user experience." I would like it more smarter than that since this is not really an objective that inspires productivity and creativity.
Your specific contextual situation might make it more easy for you to craft an aspirational Sprint Goal from an abstracted common goal per product.

Impediments are often revealed when organizations either support an unfocused approach to software development, or refuse to acknowledge their own capacity limitations.

There is the common Agile/Lean saying - "Stop starting, and start finishing". Healthier organizations understand that progress is measured by what is completed, and not what is started.

There is plenty of empirical evidence available which proves that it will take much longer to complete A, B, and C when multitasking (trying to work on all three at the same time) as opposed to focusing on 1 item (A), completing it, then focusing on item B, completing it, etc.

The advantage of a sprint goal is to create focus both within the team and within the business around a single area of value. There really isn't any benefit in creating a sprint goal if the business insists on offering disjointed work to a team.

Organizations that burden a single team with supporting several projects/products (and Product Owners?) also creates a lack of focus and many "challenges" around prioritization of work. Symptomatic of an organization failing to understand their capacity, and trying to start or maintain several projects/products more than they are truly able to support.

Thank you for all of your replies.

In our case we have more products than Scrum Teams. Some of the products are closely related and could be managed by one Scrum Team. This would solve our problem of having multiple development teams working on the same product. I am starting to see how Scrum/Agile forces a company to think differently about their approach to development.
What happens when product X needs one feature for Team A and another feature for Team B. The product owner of X decides to work on A first than B. Won't this create an obstacle for team B? Is it possible that the company is doing to many things at once with not enough resources?

Timothy,
I couldn't agree with you more that teams need to focus on a single goal at a time, in fact I tried to make a case for that this week. Can you recommend articles to help me support my claim?

Matthew,

The internet is filled with studies and articles on the inefficiencies of multi-tasking. Just google it (inefficiencies, multitasking).

The science comes down to this. There is a real cost to context-switching. Studies show that for each additional item/task that you try to juggle, you are spending 20% of your overall capacity simply switching from one item to the other (Where did I leave off? Let me get back up to speed, etc.).

If you're juggling three items, you're spending 40% of your time in context-switching, and not directly working on the item.

Now, extrapolate that to an organizational level, where people are being asked to work on two or more items at a time, and the loss in productivity is staggering.