Sprint goal should be optional#28

I suggest to make the sprint goal optional, so that you can use it when it actually adds value to your sprint - often the sprints which are complex.
It should be a guidance for you in complex situations. You still have the product goal so you could skip the sprint goal because each sprint will still be a stepping stone towards your product goal.

I have seen a lot of teams trying to create good sprint goals for sprints where the sprint backlog wasn’t complex, but rather complicated or simple.

Most often the sprint goal became artifical during the sprint and it slowed them down because they “needed” to inspect and eventually adapt to it each day.

The Scrum Guide is quiet in areas that are highly situational. The fact you are not doing complex work is not a situation it should cater to (at least by design).

Scrum is meant for complex work, if you are doing simple or complicated work, then that may affect the whole framework’s effectiveness.

By trying to cater to all kinds of environments, we’d be watering down the power of Scrum in complex environments. That’s why I’d be against making it optional.

Also, the Sprint Goal relates to every single Scrum event at the moment, plus it is the only reason for canceling a Sprint. Making it optional would be transforming the complete framework to cater to two domains it’s not most effective in. This is not a simple change of making it optional.

That being said, if it doesn’t serve your context well, do not use it. But then you bump into the immutability rule (which should be removed).

Nope 😠👎

Many teams are work-order teams where their backlog is just given to them and they simply have to execute it. Trying to fit a goal into random piecies of work is horrible and I see people getting zero value for goals.

But Scrum, is revealing that goals are not working. Most people want to change the rules so it is okay. However, good scrum teams will make transparent that goals are not work, then inspect why and try figure out how to do this better.

Typicall (not always), the issue is how the Product Owner manages value. The PO often lacks establishing a product goal and a series of smaller milestone goals to reach the product goal. This is not hard to do. The PO needs the discipline to work goal based and outcomes based. This makes their world a lot easier to manage. Sadly most fall into the trap of defining the features and not letting the team do that, then they micromanage that.

PO - Create product goals and outcomes.
PO - Estabilish (with others) many interim goals as a release plan and product strategy. This is not defining features, but the desired outcomes and goals.
Scrum Team - In near term refinement, Explore and expand the goals into features. If goals too big, work on greating more interim goals that encourage feedback.
Scrum Team - Sprint planning, detailed conversation of feature.

This journey takes time to master with many challenges. Initially many teams stuggle with this. But it is about constantly figuring out how to do it better and to improve flow.

If you don’t have sprint goals you probably are not using the right methodology either. No need to force a round peg in a square hole so change to one that fit your actual work.

Scrum only work for certain types of work after all and also only certain types of teams.

@Brett I think many teams and SMs can relate to the work-order situation you mention, where it can be highly challenging with setting up a goal for a sprint.

One real-life example is when teams are in an organization using SAFe. The PO is an order-taker, projecting these orders to the team. Yes, there are PI objectives, however (as we in the room here know), they are not equal to a Product Goal. It tends to result in the sprint backlog items being a list of various stuff that are imortant to deliver to accomplish PI objectives. And setting up a sprint goal for this list of various things can be daunting.

Even so, how challenging this might be, I find it important having a goal leading the work in the sprint, regardless if the team is in a SAFe or non-SAFe context.

To distill; the sprint goal is needed.