Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

As a self-managed team, they will decide for themselves how to best manage communication between team members. The Scrum Master will only take action if requested or if he/she observes that there is a potential problem.

Note: The Daily Scrum is an internal meeting to the Developers. Therefore, the Product Owner and the Scrum Master may ATTEND the Daily Scrum as silent observers but they cannot actively PARTICIPATE in the Daily Scrum.

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.

In the scrum framework, there is no such thing as a Proxy Product Owner.

What is a Sprint Review?

A Sprint Review is a Scrum Event that occurs at the end of each Sprint. The purpose of the Sprint Review is to inspect and demonstrate the work that was completed during the Sprint and to get feedback from stakeholders. The Scrum Team presents the work they have built during the Sprint to stakeholders. This event provides an opportunity for the stakeholders to see the progress being made, provide feedback, and help the Product Owner adjust the Product Backlog if necessary. The Sprint Review is a collaborative and transparent process that helps the Scrum Team to continually improve their work and deliver the best possible product.

To minimize waste, it is important for the Product Owner to regularly review the Product Backlog and remove items that have not been addressed for a long time. Keeping such items in the backlog can lead to unnecessary work and contribute to waste. By removing them, the Product Owner can focus on more relevant and valuable items.

Fully describing every Product Backlog item upfront, especially those that may not be implemented, can lead to waste. By only providing a detailed description when it seems likely that an item will be implemented in the near future, the Product Owner can avoid spending unnecessary time and effort on items that may change or become irrelevant.

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The fundamental unit of Scrum is a small team of people, a Scrum Team.

Be careful, the 2017 version of the Scrum Guide is now obsolete. Please refer to the 2020 version.

"The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems."

"The Scrum Team is responsible for all product-related activities".

"The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint".

- The Scrum Guide (TM) of 2020.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

In theory, there is no "final version of the product" because a product can always be optimized. The Product Backlog exists as long as the product exists.

As a market expert, the Product Owner has a total authority on how to order the Product Backlog.

He or she can come up with an urgency (due to a market change...) that doesn't seem to increase the overall value of team's work. Still, the entire organization must respect his or her decisions.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Product Owner's primary concern is the flow of value reflected in the ordering of the Product Backlog.

The Scrum Master serves the Product Owner in several ways, including:

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

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

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

● Facilitating stakeholder collaboration as requested or needed.