Scrum Master serving PO from 2020 Scrum Guide - some example please from the real world...?

Thanks :) 

1. Helping find techniques for effective Product Goal definition and Product Backlog management;

( The SM can refer to share Velocity they have to date to help order items that have been sufficiently refined or reorder I guess.. Product Goal seems a lofty one however for an SM don't you think? )

I don't think your example really fits here. Theoretically, you can use velocity this way, it doesn't make much sense. The biggest problem is that it relies on a completed and fixed Product Backlog, instead of an emergent Product Backlog. For real-world applications, velocity has little use outside of Sprint Planning and really shouldn't be used anywhere else.

This service can take a lot of forms. I would generally think that a Product Owner would have enough of a background in the various aspects of product management to be able to craft a Product Goal. A Product Goal isn't that different than a vision and scope. In my experience, one thing that Product Owners sometimes struggle with is saying no to stakeholders. A Scrum Master could be in a position to help the Product Owner learn effective ways to manage the competing needs of stakeholders, including figuring out who to say no to and how to deliver that message.

Product Backlog management is a lower level and is more about how to order and refine the Product Backlog. There are a number of techniques that can be used to figure out which Product Backlog Items are the most valuable for the team to do, so the Scrum Master could be aware of these techniques and help the Product Owner choose one. For refinement, the Scrum Master can make sure the team is spending enough time, has a sufficient amount of the Product Backlog refined, and that the time spent in refinement activities is useful.

2. Helping the Scrum Team understand the need for clear and concise Product Backlog items;

( Seems like serving the Scrum Team and yeah indirectly the PO but seems out of place here? )

I don't think the Product Owner is out of place here. The Product Owner is primarily responsible for the Product Backlog but may delegate that work to others. If the Product Owner is doing all (or even most) of the work associated with managing the Product Backlog, then this is coaching toward the Product Owner. However, if the Product Owner is delegating this work, it would be delegated to other members of the Scrum Team and the Scrum Master would then coach them on why and how to create clear, concise Product Backlog Items.

One of the things that I spend time on here is the need for making sure that the Product Backlog Items are expressed in a way that stakeholders can understand. The Product Backlog is visible to people outside the Scrum Team. These people should be able to look at the Product Backlog and understand what each item means and help assess its value to them to have informed conversations with the Product Owner about why the ordering of the Product Backlog is what it is and to make changes, if necessary. It's much easier to write Product Backlog Items for the team than for customers, especially if the Product Owner isn't writing them.

3. Helping establish empirical product planning for a complex environment; and,

( What does this like like in brief plain English...? )

Empirical product planning includes things like release planning and roadmapping. Traditional techniques for long-term planning don't tend to work in an agile environment. The traditional techniques are often based on a fixed scope or fixed set of requirements. However, agile environments tend to have emergent requirements and teams that are always trying to improve their delivery. This makes it hard to make long-term forecasts or projections.

The Scrum Master can know about techniques to work with stakeholders to communicate the value of empirical product planning and how it can be used to let the stakeholders do the work that they need to do. This may require working with the stakeholders to help them understand how to change their way of working to take advantage of agility in the product development organization.

4. Facilitating stakeholder collaboration as requested or needed.

( Assume this would just be: meeting setup - helping get the right people to the table with a decent agenda and expectation/outcome understood that moves things forward)

This is more than "meeting setup". It includes helping to identify who the right stakeholders are, making sure that they are present, making sure that they are knowledgable and prepared to work with the Product Owner (or the broader Scrum Team), and that they understand the purpose and intent of all of the Scrum events. Sometimes, this can also include working to eliminate meetings that are better suited to happen as part of the existing Scrum events.

1. Helping find techniques for effective Product Goal definition and Product Backlog management;

( The SM can refer to share Velocity they have to date to help order items that have been sufficiently refined or reorder I guess.. Product Goal seems a lofty one however for an SM don't you think? )

A Scrum Master serves a Product Owner in these activities by helping them understand the empirical nature of the Product Backlog.  Many times a Product Goal or Vision statements are created for a future state that is years in the future.  Because of the way the world economy changes today, a long term goal could be 6 months into the future.  This is especially true if you operate in emerging markets or are heavily technology centric.  Scrum Masters serve Product Owners by helping them to be realistic in their goals based upon the real world conditions that are being encountered.  Help them learn how to adapt quickly without invalidating a lot of work in the past.  



It also is a service to the Product Owner to just be a sounding board or second opinion.  Product direction is not an easy thing and having someone that can be counted on to be available to discuss and debate is invaluable. 

Product Backlog management doesn't mean helping them decide which is the highest priority. It can mean helping them to learn ways of making the Product Backlog visible to parties outside of the Scrum Team.  Helping to pave the way to share it with internal and external stakeholders.  Helping to make the content understandable by technical and non-technical individuals. Helping the Product Owner to understand how to inform stakeholders and the Scrum Team why one item is ranked higher than others. This is especially important in the case where a technical debt item is ranked higher than a new feature.  The stakeholders might not understand the importance or need to draw down the technical debt over providing them a feature that they have asked for on numerous occasions. And Product Owners can sometimes struggle with how to explain this.  Scrum Masters can help. 

2. Helping the Scrum Team understand the need for clear and concise Product Backlog items;

( Seems like serving the Scrum Team and yeah indirectly the PO but seems out of place here? )

This is similar to the above and in some ways ties directly into the first statement.  "Clear and concise" applies to everyone that views the Product Backlog items.  They need to be able to clearly convey the opportunity in ways that make it obvious to anyone.  There is a tendency for Developers to write in techno-speak.  "Optimize the database query" doesn't mean much to an end user that wants to have the application respond quicker but in reality they are wanting the same result.  Scrum Masters can help guide/educate the Scrum Team members on how to communicate to all parties (Improve the performance of the Budget maintenance page by optimizing the database queries used to retrieve the budget line items). 

3. Helping establish empirical product planning for a complex environment; and,

( What does this like like in brief plain English...? )

Stop planning items and committing to the stakeholders that they will be delivered in the next 6 sprints and start forecasting for what could be important to deliver in the next 6 sprints based upon the knowledge you have right now.  Then constantly reassess as new information is discovered. A Sprint should be planned immediately after the previous one is finished using the information known at that time.  That is the intention of the Scrum Events. If a Product Owner continuously wants to plan out multiple Sprints at a time, that is breaking the empirical model. 

Notice I said "stop planning" and "start forecasting".  Planning and forecasting are different.  A plan sets specific events/goals that will be accomplished if you do things in a specific order.  A forecast sets out what could happen but will be adapted as new information comes to play.  There is a reason that you have never heard of a weather plan.  We have no control over the elements that make up weather events.  So we use historical data to forecast what could happen in the future.  Product development is not much different. We don't have full control of the elements in play.  For example, we don't know what kind of legislation could be enacted that will change the marketplace we operate in.  Another example...Covid-19.   So forecasting the product plan/direction based on what historical information we have now and be prepared to inspect then adapt that forecast as new information comes in.  Just like weather forecasts, the closer the event the better accuracy you will have in the forecast. 

4. Facilitating stakeholder collaboration as requested or needed.

( Assume this would just be: meeting setup - helping get the right people to the table with a decent agenda and expectation/outcome understood that moves things forward)

There is more than just scheduling a meeting and the "requested or needed" can come from either direction.  Also bear in mind that almost every dictionary definition of the word facilitate will include words similar to "to make easier" but none will say "do something for someone else".  Facilitating helps people to do the work that they need to be doing.  Facilitate tools that can be available for use.  Facilitate by identifying work holidays in the locale where stakeholders are located (especially important in global economy).  There are a lot things that can be done to make things easier that do not involve you actually doing the work.  

Product Goal seems a lofty one however for an SM don't you think? 

Do you think the Scrum Master should dissociate themselves from such ambition, or help teams to achieve it?

seems out of place here?

Why? Why would it be out of place for a Scrum Master to reinforce the need for clarity?

What does this like like in brief plain English...?

It means ensuring that plans are based on available evidence when more is unknown about a situation than is known.

helping get the right people to the table with a decent agenda and expectation/outcome understood that moves things forward

It might mean getting them together without an agenda at all. A bounded environment like a time-box may be provided instead, in which people would be encouraged to find their own creative solution through collaboration and emergence.