Product Goals shouldn't only be fulfilled or abandoned#1

In the Scrum Guide, the following is written:

“They must fulfill (or abandon) one objective before taking on the next.”

What if you’re working on a valuable Product Objective, and based on what you learn you rework the objective to be even more valuable.

You didn’t fulfill it, you also didn’t abandon it. You merely changed it.

I believe the phrasing is vague, and may be interpreted as that reworking a Product Goal is not acceptable.

I think I get whay you mean, however reworking is simply an instance of abandoning and taking on the next.

What do you expect to gain by adding an explicit mention of this?

I get that it is crude - in an app we would very much have explicit edit funxtionality and not just add or delete, right? I believe this is because the guide’s aim is to be minimally descriptive.

Also that ‘changing a goal’ should be handled with care since they are aspirational and for instance creative bookkeeping to ‘achieve’ the goal should be discouraged.

Nb this is all my interpretation, and why i actually like the way ot os described.

I believe it aids clarity. You do not have to completely abandon a Product Goal. It can be misinterpreted.

I agree with the creative bookkeeping part. I believe the fact we do complex work means goals can also evolve as we learn and discover more. And in that case it is not creative bookkeeping.

If people will want to do creative bookkeeping, however you phrase it won’t stop them and I believe they will do it anyway.

Product goals miss the mark in my book. The better the team is the smaller bets it can make. And ideally loops are short and there aren’t many being worked on at the same time but WIP is most likely not 1. Having the team work one objective at a time leaves 0 room for exploring multiple options. Especially since objective is not the same as outcome

@Jasenko Ramljak: that is a different perspective that I agree with. You should raise it as a separate one, as this is specifically related to the wording.

IMO since there only is a single Sprint Goal per Sprint, why do we need to force a single Product Goal? Especially since multiple teams are working on same Product Backlog. It is too rigid.

@Maarten If there are multiple teams working on the same backlog each team could focus on a different Product Goal.

It reads its a single (product) objective for the Scrum Team, not a single objective for the Product. That’s why I think multiple teams can work towards different Product Goals simultaneously.

I think that one team working on different strategic goals really kicks the spirit out of Scrum, which gains its power from its shared focus and commitment.

@Jasenko Ramljak Product Goals are strategic goals. That does not mean WIP is 1. A Scrum Team can work on multiple product backlog items which each result in their own outcomes. Not all of these Product Backlog Items also have to relate to the strategic Product Goal.

You’re right @Sjoerd Nijland . I read how it’s phrased and your interpretation seems correct. Sprint Goal is from perspective of Sprint, Product Goal from perspective of Scrum Team.

I still don’t see it. Can you give an example of a product goal?

I think it’s the matter of interpretation. E.g. in my understanding, I can transform the product goal, making it different, while the previous version will be “abandoned”, as I would not refer to it anymore. I can also “put it on hold” till better time comes, by temporary “abandoning” it. I don’t see a problem in “abandon”.

If a once off thing, suck it up and move on. However if this is occuring regularly, use Scrum to reveal the impact it has on planning, cadence and delivery. Use Scrum to find about better ways of doing things.

All this is doing is making visible a possible impediment. Leverage the framework to improve and “find better ways of doing things”. Perhaps look at your strategy and planning and ask “Can we do this better?” or “How can we keep our WIP low so we can improve throughput”

Changing the rule, will likely destroy the opportunity to make planning issues transparent.

In my view, Scrum is doing its job as it is causing the problem to be transparent. The art is now to recognise it, inspect and really understand what is going on.

@Brett : others have commented that abandoning is what you should do when you rework.

If that is a viable option, then transparency is not at odds here.

If you are saying that is not a viable option, then what is more important, more transparency on a less valuable objective OR less transparency on the old objective and more transparency on a more valuable objective.

If your point is, that people will set the bar lower to meet the objective by making rework an option. What if it is far more difficult than expected? Why wouldn’t you be allowed to set the bar lower? You’re making decision based on what is known.

@Maarten Dalmijn. Let’s not loose common sense and doing what is right for the business. Like I said, if it happens rarely then suck it up as do what is right for the product and business.

However if a common recurring problem, inspect the impact it has. E.g. if every piece of work is more difficult than expected and this happens every sprint; this is an indication of not learning and finding better ways. It’s like working with someone the never delivers and is refusing to learn.

Rules will not help here, sorry. We have to go to principles of taking ownership of getting done and managing expectations. The impact is great if it persists as commiment lowers. I have seen this play out far too often and EVERY time it is zombie Scrum.

Again, anyone expecting every sprint to be perfect is missing the point. It’s about looking what is happening at trying to do it better. That is the point.

@Brett:

I agree that if it is recurring you are probably doing something wrong.

However, the way it is phrased seems to disallow it.

The question to ask:

How do we capture your concern, yet also leave the door open for other cases that can and will happen?

@Maarten Dalmijn , when I teach, mentor or coach people I help them not get hung up on those things like this. Plans don’t always go to plan and Scrum fully embraces it by controlling the risk in sprints. It creates points that transparency, inspection and adaptation on it happens.

Scrum is basically setting the ideal state where people have strong, purposeful goals. The essense is trying to get everyone on the same page with the same focus. Learning to reach that is the journey and why Scrum exists. Scrum in my view is doing the right thing and this is just word symantics that will not change the behaviour.

I see goals being abandoned, changing, things not going to plan as life. I see Scrum creating the necessary points of inspection to deal with these real life things that happen.

(good conversation btw)

Two main important piece. 1) if the goal is not completed before the sprint concludes, all work items go back into the product backlog. This is a possible interpretation of abandon. 2) multiple sprint goals should not occur at once. This causes resource contention and impedes the team as a collective to inspect and adapt as a unit. This is actually a technique POs can do to squeeze more out of teams, or worse if multiple POs (I know not scrum, neither are two goals in progress in tandem) use to push for more midsprint. 3) two product goals at once mean one product goal by definition risks the other, which is not allowed.

Maybe there is a better phrasing.

I believe you are conflating Sprint Goals and Product Goals.