sprint goal when team is working on multiple unrelated items

What valuable product increment is the team intending to deliver, and learn from, by the end of the Sprint?

Hi Ian ,

Apart from UI related product increment there is no other increment as other 3 stories are related to either analysis(of the problem, code etc) or code refactoring. 

Has the team had a need to collaborate during the Sprint, rather than to work as separate individuals? Has there been a joint focus on learning something for example, or on solving a common problem?

Great points by Ian. Looking at the Scrum values, is there anything triggering you?

Has the team had a need to collaborate during the Sprint, rather than to work as separate individuals? Has there been a joint focus on learning something for example, or on solving a common problem?

Ours need is such that we have to start all stories simultaneously. So, we cannot assign multiple development team members for one story. To collaborate they have to work on the same item. Even in our scenario, they do collaborate to the extent possible. For example, the most experienced developers helps them with their knowledge and guidance. However, two junior developers (who are working on analysis stories) cannot collaborate with each other as both are analyzing different code. 

However, my question is when each team member in your team is working on different items just like in our case, creating sprint goal is impossible? How about compound sprint goal as I mentioned in first post ??

However, my question is when each team member in your team is working on different items just like in our case, creating sprint goal is impossible? How about compound sprint goal as I mentioned in first post ??

You can have a compound Sprint Goal as long as it makes the selection of work coherent, and gives the team a common sense of purpose and a reason to work together.

If unrelated items can be prioritized for example, then a coherence is effectively introduced around which the team might collaborate. The items become functionally related. The team will action them in a certain order so that value is maximized.

In the situation you describe, where developers work in silos and have no reason to collaborate in such a way, you don't really have a Sprint Goal, or a team which could satisfy one.

One developer in our team is working on code refactoring

2nd developer is working on Analysis of abc

3rd developer is working on analysis of xyz

4th developer (UI) is working on complex UI requirements

Vishal, what is the business reason (value) behind doing any of this work?   Why does it need to be done?

My advice is to focus on the why, and not to create a Sprint Goal that simply recaps the tasks the Development Team members are working on.

You can have a compound Sprint Goal as long as it makes the selection of work coherent, and gives the team a common sense of purpose and a reason to work together.

If unrelated items can be prioritized for example, then a coherence is effectively introduced around which the team might collaborate. The items become functionally related. The team will action them in a certain order so that value is maximized.

In the situation you describe, where developers work in silos and have no reason to collaborate in such a way, you don't really have a Sprint Goal, or a team which could satisfy one.

Thanks Ian. This clarifies my doubt.

Vishal, what is the business reason (value) behind doing any of this work?   Why does it need to be done?

My advice is to focus on the why, and not to create a Sprint Goal that simply recaps the tasks the Development Team members are working on.

Timothy, the business reason (value) will be provided in next sprint when actual development will be done. But to deliver that value these activities are required.

the business reason (value) will be provided in next sprint when actual development will be done. But to deliver that value these activities are required.

Vishal, this represents an incorrect understanding of Scrum.   Dedicating sprints to specific "phases" of value delivery (i.e. - Analysis, Development) is just replicating traditional waterfall phases, and is not Scrum.

Per Scrum Guide:

"The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created... Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment."

So the question to you is, what can be done within a sprint that actually delivers something (however small) to the end-user that they can validate and provide feedback on?   This would involve any analysis, development, testing, and any other criteria you may have to recognize an item as complete and potentially releasable to production (meeting DoD).