Questions for PSPO II exam

I've read blogs about the updates on the Scrum guide which states that it wouldn't be appropriate to intentionnaly create PBIs that do not align with the Product Goal. There could be some that are for maintenance or whatever but not for this. 

Would those PBIs align with the Product, and be of value to the Product Owner and the stakeholders he or she represents?

it includes the self organized part. Would you agree or would you only answer with self managed?

Self-organization isn't wrong, and so cannot be ruled out. However, I'd suggest that self-management is the best answer, for the reason you describe.

First, congratulations on passing the PSPO 1. 

If you remember from your studies, the product goal is created from the organisations vision for the product.  A product can have many product goals during its lifetime, but only one at a time.  The product goal is the scrum teams long-term future.  Each print goal should be aligned to the product goal, and is the scrum teams objective for that sprint. 

Thank you both.

Regarding the Product Goal, let me explain a bit further my thoughts.

You have one Product Goal, let's say that your goal was to drop your retention by 20%. Your KPIs are showing you that you managed to achieve that goal. You are within a Sprint.

Since the Sprint goal was to add a functionality helping for that, you might still do it as dropping your retention further might still help you.

But how do you prepare for the next Product Goal if you did not do it before? I mean, there is a lot of work in preparing the PBIs needed.

So in my opinion, I would have partly prepared it. Even if those PBIs did not align with the Product Goal (maybe), they would still align with the Product and your next PGs (to answer your question Ian).

Is my train of thoughts wrong here?

sorry not drop the retention but increase it

PBIs are created based upon stakeholder requirements for the product.  They are not created to meet a product goal.  The product goal is created based upon the org's vision for the product at that point in time.  The PO then orders the existing backlog items and perhaps creates new ones on his own or during refinement sessions with the developers.  During sprint planning, the scrum team agree on a sprint goal that is aligned with the current product goal.  The developers then select PBIs from the product backlog that relate to that sprint goal (usually these are the PBIs that are at the top of the list if the backlog has been well refined; however, they could select some from further down if say there are dependencies or it would product more business value due to their relation to one or more higher ordered PBIs). 

Joshua Partogi has just released a great VLOG on the product goal. 

https://www.scrum.org/resources/blog/vlog-how-create-scrum-product-goal

But how do you prepare for the next Product Goal if you did not do it before? I mean, there is a lot of work in preparing the PBIs needed.

Instead of preparing a future goal that might change radically due to lessons learned from pursuing the current one, why not expect and nurture emergence.

So in my opinion, I would have partly prepared it.

I'd suggest that emergence is something to be actively encouraged.

Thanks for sharing this.

Just had some trouble when reading Dave West blog about Product. There were some confusing comments for me.

This is the blog I'm talking about and if you search for "would not intentionnally find", you should find the part I'm talking about : https://www.scrum.org/resources/blog/scrum-guide-2020-update-introducin…

Anyway, I think I get the idea and it makes sense in my head which is what I needed. Get rid of confusion haha.

Thanks a lot guys and I'll watch the Vlog!