Sprint goal clarification

Are the team able to work on a coherent endeavor during that Sprint, such as providing improved search functionality for the Product? Or will they be working on two separate initiatives (one for HR and one for Finance) whereby collaboration is impaired and teamwork is weakened?

In a case where I have a priority defined from stakeholders and there is team capacity in a Sprint to do both Search HR and Finance functionality. In that case can we do that.

Thanks,

Pradeepkumar

It's not about whether you have the capacity (well, not just about that anyway). It's whether there's a unifying sprint goal to be found. The team should have one goal and one goal only during the sprint.

If a Development Team feels it has the capacity to complete two Sprint Goals in one Sprint, surely there are two questions to be asked:

1. Is Sprint too long and can the Sprint be shorter?
2. Is the Development Team too big and can the team be broken into two teams?

If there are two Sprint Goals in one Sprint, at least one of those goals is being delayed in terms of being potentially releasable.  

For example, why not have a one year sprint with 24 Sprint Goals?

Looking at our backlog, it's often hard to get to one sprintgoal (2w sprints).

Items are often 1-2 days work, where focussing on only one area will let us build less valuable things, even though we might be somewhat more productive in terms of estimated effort.

One way to get to one sprint goal is making it less specific, which sometimes solves this issue, but I like specific goals better.

We could reduce our sprint length, but the consistent cycle of 2 weeks feels pretty good for our team.

We could specify the most important goal as the sprint goal, knowing we will probably spend time on other things as well.

This is something that makes sense to me in theory, but is hard in practice. Any thoughts on this?

We could specify the most important goal as the sprint goal, knowing we will probably spend time on other things as well.

That might be best, assuming that it would yield the greatest value to the Product Owner, and Development Team members are able to commit to it.

In Scrum, team members are expected to commit to the goals of the team. Those commitments must be realistic. If non-product work is also being done, and makes a commitment to a certain product outcome unrealistic, then that outcome should not form part of any goal.

That might be best, assuming that it would yield the greatest value to the Product Owner, and Development Team members are able to commit to it.

Let's say that it does and let's assume we have now 2 parts (both product work) for where we could formulate a sprint goal had they been in separate sprints.

Is there harm in formulating it (as they will likely be both developed in this sprint) as: sprintgoal is A and secondary (B)? As long as its clear that A is more important than B (I think this is important for guidance/focus reasons)

There are no secondary Sprint Goals in Scrum precisely in order to avoid the risk of divided focus. However, a team may have other goals in addition to Sprint Goals. Scrum does not forbid them.

An example, more or less along the lines you describe, might be for a team to agree to certain so-called "stretch goals". They could commit to achieving a stretch goal only if time and resources prove to be available during the Sprint. If the associated scope is budgeted for in the Sprint Backlog then it would provide contingency, and may increase team member's confidence in being able to commit to the Sprint Goal at all. The term "stretch goal" is unfortunate because it can be seen to imply that a team is not truly committed unless it is somehow pressured, but it is commonly used.

Clear, I was not familiar with the term stretch goal, but it makes sense in my example.

I would agree that it provides more clarity than stating multiple items in order in a sprint goal.