two sprint goals in a one sprint

What purpose did the Sprint serve, in this case? What made the selection of work coherent, and gave the team a reason to work together within that timebox?

I think of the Sprint Goal as a way for the team to maintain focus and commitment on something. If you have two, not only do you have a singular focus and a commitment to something, but it becomes harder for the Development Team to self-organize and make decisions on what to do without going to the Product Owner to help make the decision on which goal is more important or valuable.

While it is obvious why it is good to have a (single) Sprint goal, there can be valid reasons for serving multiple business goals in one Sprint. You (the scrum master or the product owner) are in the position to assess the validity of the scenario. If it is just a result of the lack of planning, you have just identified an improvement potential. However, if the reasons are valid, it is better to serve your customers (which is an agile principle) than your textbooks (fundamentalism is not an agile principle).

Thank you for your comments.

The reason why we took 2 sprint goals was a situation that the sprint goal from a previous sprint wasn't achieved.

The Product Owner took this sprint goal again to the ongoing sprint. He also added one more sprint goal because it had business value. The team agreed that the scope is achievable.

It is one of the rock-paper-scissors situations when you have to choose which is the least problematic.

- Sprints should have the same length. Change is not excluded, however, planning 2 short sprints for the sake of 2 goals is unorthodox. Splitting the team just for this Sprint to deliver 2 goals, is even more so.

- A Sprint should have a coherent Goal. However, telling the product owner how to reorder the backlog and forget about importance and urgency is an outright violation of the PO's authority over the product.

- Having 2 goals in 1 Sprint is suboptimal. It bears the risk of facing decreased efficiency and performance and a less well-considered outcome.

In the long run, all options are on the table (especially working with the PO to better achieve coherent Sprint Backlogs), however, for 1 single occasion, I believe most of us would simply go with the third option.

Hi All,

I have one DEV Team (4 developers) that are always working in several products at the same time (3, for example). So, we will have one PB for each product, but in the sprint with PBI of 3 products, it will be necessary 3 sprint goals, one for each product? If not, it will be impossible to find a single sprint goal that fits all.

Am I right? What is your experience?

Thank you very much again!

If not, it will be impossible to find a single sprint goal that fits all.

That's right. Scrum is very good at exposing organizational impediments quickly so they can then be dealt with. In your situation, there's an issue with the amount and type of work in progress, and the consequences of this regarding team focus and commitment. You might cover up the problem by breaking the Scrum Framework but the underlying problem would remain.

Thanks Ian, I can't split a DEV Team of only 4 developers, so I think we will start this way: 

1. In the planning meeting we will check the different PBs of all the products.

2. We will decide a sprint goal for each product

3. We will create the sprint backlog with some PBIs of every product according to every sprint goal.

At this time, I have no way of creating a sprint with PBI of only one product, and maybe always will be this way.

Let's see what happen... ;)

1. In the planning meeting we will check the different PBs of all the products.

2. We will decide a sprint goal for each product

3. We will create the sprint backlog with some PBIs of every product according to every sprint goal.

By doing this you're covering up the problem(s) and impacting focus and commitment, as mentioned by Ian. This translates into loss of productivity every Sprint. If you were to quantify the cost over a year, I am sure it would be significant. 

What I have seen work better is to run shorter Sprints (1 week) and have the Product Owner choose 1 Product Backlog per Sprint, so you have only 1 Sprint Goal. 

I can't split a DEV Team of only 4 developers

What do the developers think about that? Would it be possible for 2 cross-functional Scrum Teams aligned with products?

The other option is to look into Kanban and limit WIP.  Focus on one cohesive set of PBIs of a product, get that done, and shift to the next product. As the saying goes, "stop starting and start finishing".

Chris Belknap : Thanks for your suggestion!

"What I have seen work better is to run shorter Sprints (1 week) and have the Product Owner choose 1 Product Backlog per Sprint, so you have only 1 Sprint Goal. "

"The other option is to look into Kanban and limit WIP.  Focus on one cohesive set of PBIs of a product, get that done, and shift to the next product. As the saying goes, "stop starting and start finishing".

I can't do this because some developers will have no work in that sprint.

"Would it be possible for 2 cross-functional Scrum Teams aligned with products?"

The problem is that at the same time I will have 4 developers working in 4 products, so I have 4 teams of 1 developer (or maximum 2 developers working in the same product).

We will work to change this, but it requires time, transferring knowledge ... We will hire one more developer shortly and we will probably need another one in the future.

Now they don't use Scrum, they have a unique Backlog for all products and they have a meeting every Monday to check what they are doing and what they will do during the week.

We had (and still have) a similar situation and I also asked some time ago about the (one and only) sprint goal. 

Getting the one and only sprint goal in one sentence is still impossible and will stay nearly impossible. Instead of that, we check the most valuable topics and craft the main objectives for the sprint goal.

Nevertheless, we did a lot of knowledge sessions by pair programming/look over the shoulder/learning days to get a better understanding of the other products. Otherwise planning/refinement is a kind of waste as most of the team cannot contribute.

Martin Jungmair thanks for your comment about your experience.

Yes, we will need to have some knowledge sessions.

"I can't do this because some developers will have no work in that sprint". <-- This is your impediment to overcome. Stop focusing on "resource utilization" and keeping everyone busy. The main catch is that too often only a few people throw as much work at others as they can think of, disregarding the idea that they may do not have the whole picture to make such decisions.

IMHO the sooner you accept that in the complex environment you will never have the luxury to sustainably and effectively have the same amount of work for everyone at any moment, the quicker you will reach a sustainable pace. Simply lay out rules of the game with everyone involved, what tactics or rules do you trigger when you say "I have no work for myself" - a clue is that taking the next work from the Product Backlog is the last thing to even consider. Before that happens there are plenty of things to consider, that too often are not addressed as "business as usual" kills any possibility to do other things, like i.e. improving our software delivery pipelines, or paying some tech debt. Having a slack time is in fact opportunity, not a problem to it fight back with a "resource utilization" mindset.

Piotr Górajek thanks for your comment 

Hello

I have similar problem. Not only my team works on different products but also team members hold different knowledge and skills, not everyone can work on each product, there are silos, we are working to break them but for now I do not see an option to have one sprint goal. Any thoughts to this? Tamara

Not only my team works on different products but also team members hold different knowledge and skills, not everyone can work on each product

That statement alone indicates that you are not using Scrum.  Scrum advocates a single team per product with people fulfilling the roles of Product Owner, Scrum Master and Developers for that single product.  

It might make sense to look at your product definitions and arrange teams along those lines.  It is not uncommon for a single individual to fulfill Scrum Master with multiple Scrum Teams. I have also seen a single individual fulfill the role for multiple related products but it was not ideal. Developers typically work on a single product so that domain knowledge can be acquired.  This will allow you to benefit from the "silos".  

What I suggested above is a next step to getting better.  It is not the full solution.  You most likely will need to incrementally change to a long term solution.  You may find that your current products aren't actually products. Some of them might be components of products.  Do not go into this with any preset expectations.  Inspect everything, adapt accordingly and then start over again.

I have similar problem. Not only my team works on different products but also team members hold different knowledge and skills, not everyone can work on each product, there are silos, we are working to break them but for now I do not see an option to have one sprint goal. Any thoughts to this? Tamara

From what you describe, are you sure you have a team at all?

Ian, that is very good point. No, I think this is group of people working on different products as IT service and I have few ideas how to change that, break silos, make clarity around product/service team, what they really are etc. but it will take time. I can also go to the team and management and tell them you are not a team lets break it :) I was wondering do you guys have any idea what I actually should do?

I was also thinking "Multiple Increments may be created within a Sprint" why then  we cannot have more than one goal

I was also thinking "Multiple Increments may be created within a Sprint" why then  we cannot have more than one goal

 

How could you describe impact on your ability to maintain focus in scenario where you are creating multiple increments that satisfies one goal vs scenario where you are trying to satisfy two or more goals?

I was wondering do you guys have any idea what I actually should do?

I think the first thing you should do is to find out who wants Scrum to be implemented in this company, and why. What outcomes are they expecting?

We have a similar situation, but we have 4 cross functional teams (Front End, Back End, Design, Quality Assurance / per team) and they have more than one client they work on. Sometimes multiple in one sprint. So there is always more than 1 sprint goal at a time each sprint.

At current from a business stand point, we cannot only have 1 client per team. I would assume the ideal situation is that each team only focuses on one client per sprint, if that is the case?

I know focus is the biggest impediment that we are working on with this current set up.

Thanks!!!

At current from a business stand point, we cannot only have 1 client per team. I would assume the ideal situation is that each team only focuses on one client per sprint, if that is the case?

It would be better if they focused on one product per Sprint, regardless of how many clients there are.

Would there be a Done increment at least once per month for each product, or would it take longer than that?

Though there will be different ask from different clients, I believe all changes are requested for single product/service ?. A killer feature developed for 1 client now may be needed by some other client later or may be not. So to limit the risk of cost and effort it is really important to 'Order' which increment to that product can add more value in future and not to take all 'Orders' from all clients otherwise we end up having more than a sprint goal(like) in a sprint. 

At current from a business stand point, we cannot only have 1 client per team

So before even passing the challenge to the team to define a sprint goal, business has to define what a product is and its product goal.