The Scrum Guide lists as one of the responsibilities of the PO:
"Clearly expressing Product Backlog items"

And then adds:
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

In my experience one of the biggest problems with the PO role is that POs tend to become backlog managers, mainly writing User Stories.

Customer contact and prioritization/ordering of PBIs isn't done properly.

In most cases it turned out to be a good idea to involve the team in creating User Stories or even delegate it to the team. Then the PO can focus on his main responsibility of maximizing the value of the product by prioritization/ordering of PBIs.

This thinking could be addressed by moving "expressing PBIs" to the team. With the option that the PO could also be a team member at the same time it would still be possible that the PO person writes User Stories (than as a team member).

That may my suggestion doesn't change the possible division of labour between PO and team but sets another tone.

"The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints."

I think this counts things from previous increments multiple times.

If sprint 1 has value 5, the increment has value 5. Then if sprint 2 has value 4, then the increment has value 4+5=9. Then if sprint 3 has value 6, the increment has value 5+9+6=20. We've counted the value from sprint 1 twice.

I think a better wording would be "The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the Product Backlog items completed during all previous Sprints."

Scrum Guide says: The Scrum Master is a servant-leader for the Scrum Team.

Proposed change: The Scrum Master is a servant-leader for the Scrum Team and the whole organisation.

Rationale: for the Scrum Team to be able to deliver and work effectively, the Scrum Master can not just serve the Scrum Team in isolation. The Scrum Master needs to spend his time serving others outside of the Scrum Team too. Changing this will also make many Scrum Masters who is only focused serving the Scrum Team to think that others outside of the Scrum Team need to be served too so that the whole organisation can be agile.

The Scrum Guide already mentioned some of Scrum Master's service to the organisation he belongs. So it makes sense to change the Scrum Master is not only a servant leader of the Scrum Team.

Suggestion: add one more section "Scrum Master service to the Scrum Team"

There are some items in "Scrum Master service to the Product Owner" that should belong in "Scrum Master service to the Scrum Team".

- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- Understanding and practicing agility; and,
- Facilitating Scrum events as requested or needed.
Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;

It does not make sense to put these items under "Scrum Master service to the Product Owner" because the content is not only about serving the Product Owner as one individual but both the Product Owner dan the Development Team.

In dysfunctional teams, a strong emphasis is placed on the daily stand-up, because it is a window through which management can micromanage. There is a tendency to plan to full capacity, with no slack, a tendency to apply pressure to the team to deliver, and hence a tendency for the team to fall behind. In many teams, to "save time", the retrospective is held infrequently or dropped, or has no useful outcome because problems are able to go unchecked and grow, becoming harder to get traction on solving.

If scrum were to advocate making retrospectives smaller, and more frequent, it can encourage actionable outcomes and a mindset of improvement. Perhaps the question "what can we do better today" or "what can we improve today" should even be added to the daily stand-up, to help teams to think about and act on these things.

Equally, feature level retrospectives should be a tool that is available to teams, where once a feature is delivered the team can feed back learnings (good and bad) without waiting for a sprint end. Why defer the opportunity to improve?

In the section on the Product Backlog, it says that the Product Backlog "lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases". It also says that Product Backlog Items (which are presumed to be the only content of the Product Backlog) "have the attributes of a description, order, estimate, and value". The section on the Sprint Backlog says "the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal".

The November 2017 updated modified this paragraph of the Sprint Backlog section of the guide: "The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting."

This seems to be conflating different things that makes the relationship between Product Backlog Items, the Product Backlog, and the Sprint Backlog more confusing.

A Sprint is defined by a few things: the timebox, the Sprint Goal, and the Sprint Backlog.

Instead of putting the continuous improvement item into the Sprint Backlog, it should be part of the Sprint Goal. I'd also like to see the plan for delivering the Increment and realizing the Sprint Goal as a separate item.

The Sprint Goal and Sprint Backlog can be created in either order. Personally, I've had success with defining a goal and then defining a Sprint Backlog that aligns with that goal. I've also had success defining a Sprint Backlog based on capacity and using the Sprint Goal to align the team with what is most important to achieve at the end of the Sprint. I'd like to see the continuous improvement item added to the Sprint Goal.

I'd then like to see a Sprint Plan that considers the Sprint Backlog (which only consists of some kind of product-centric work) and the Sprint Goal (which encompasses the value to be delivered, to stakeholders via the product as well as the team and/or organization via continuous improvement).

I believe that having a separate Sprint Plan can also focus the discussion of the Daily Scrum event. If the plan aligns with the goal as a separate entity, it becomes easier to discuss variations against plan that are affecting the achievement of the goal.

In an ideal world, a team owns it dependencies. As a larger organization adopts Scrum and leverages across a complex product / services environment where many products are leveraging 10's to 100's of services, describe pattern(s) for how teams can effectively organize to ensure their service can scale to meet the need of its users. We have some complex services that require many Scrum teams to deliver the service. Complicating matters, there are many products consuming this service and the service teams delivering the service are always a bottleneck. We've tried various patterns and have one that works now, but took us a long time to get there. Would be great to define best practice.