PSM II – PSM and PSPO

Different Teams working on the same Product can:

• Have different Sprint Lengths.
• Have different Scrum Masters.
• Have only one Product Owner.
• Have a shared Definition of Done.

1) Product Goals are like milestones on the Product roadmap. At any point in time, the next Product Goal is a single point to focus on for the Scrum teams. Product Goals are what the Scrum teams should work towards. For instance, if you put all your current work-in-progress on a Kanban board or look at all the items in a Sprint Backlog, they need to be all towards the next Product Goal. Getting teams to focus on the Product Goals keeps them focused on the product. This creates shared purpose.
2) A Product Backlog can have Product Backlog items which could tie to more than one Product Goals.
3) There can be only one “active / current” Product Goal at a time. This is the one Product Goal; the entire Scrum team focuses on.
4) During Sprint Planning, while considering Product Backlog items for a Sprint, the team should select the items which belong to that one “active” Product Goal.
5) During Sprint Review, the progress made towards the “active” Product Goal should be discussed.
6) If multiple teams are working, they should all work on the same “active” Product Goal.
7) During refinement, new Product Backlog items which tie to a different Product Goal could evolve. They should be placed in the Product Backlog.
8) As the Scrum Guide states, the Scrum team must fulfill (or abandon) one objective before taking on the next.

The Product Owner is also accountable for effective Product Backlog management, which includes:
1) Developing and explicitly communicating the Product Goal.
2) Creating and Clearly expressing Product Backlog items.
3) Ordering the items in the Product Backlog to best achieve goals and missions.
4) Optimizing the value of the work for the Developers to performs.
5) Ensuring that the Product Backlog is visible, transparent, and clear to all.

The Product Owner and / or the Scrum Master should promote transparency by sharing the Product Backlog and ensuring all the stakeholders have the needed access to it. The Scrum Master and the Product Owner should always be open to discussing the impediments and forecast with the concerned parties.

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. Remember 10 is just a Guideline. A Scrum Team can be 11 people if needed but it should stay small enough to stay nimble.

A Scrum Team is a cohesive unit of professionals focused on one objective at a time, the Product Goal. The Scrum Team consists of the following accountabilities (previously known as roles):
1) One Product Owner.
2) Developers.
3) One Scrum Master.
No Project Managers or Functional Managers exist within the Scrum Team.

The Daily Scrum is not the only time Developers can adjust their plan. They often meet throughout the day for more detailed discussions about adapting or replanning the rest of the Sprint’s work.

During Sprint Planning the entire Scrum Team crafts the Sprint Goal.

The Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the entire Scrum Team must create a Definition of Done appropriate for the product.

The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk.

Transparency enables inspection. Inspection without transparency is misleading and wasteful.

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard, so observers share a common understanding of what is being seen.

During Sprint Planning, the whole Scrum Team collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

Scrum Master ensures that the meeting takes place but does not have to be present in the meeting. The Scrum Master serves the Scrum Team in several ways, including:

• Coaching the team members in selfmanagement and cross-functionality.
• Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done.
• Causing the removal of impediments to the Scrum Team’s progress.
• Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

Important decisions are made based on the state of the Sprint backlog, Product backlog and the Product Increment. Thus, these three artifacts should be extremely transparent. Artifacts having low transparency can lead to decisions that diminish value and increase risk.

A meeting / event called the Sprint Review is typically held at the end of the Sprint to:
1) Inspect the Increment.
2) Adapt the Product Backlog.
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.
The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Sprint Planning occurs after the Sprint Review and prior to the next Sprint Planning.

The term “potentially releasable” no longer used to describe the Increment. The Scrum Team should work on and deliver a product increment which usable and valuable at the end of every Sprint.

The Scrum guide states, “Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work.” The guide also states, “Their primary focus is on the work of the Sprint to make the best possible progress toward these goals.”
Technical skills and domain knowledge are nice to haves, however not mandatory.

The number of items selected from the Product Backlog for the Sprint is solely up to the Developers. Based on the discussions with the product owner, the Developers can best assess what can be accomplished over the upcoming Sprint.
Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts

The Sprint Backlog is created during the beginning of the Sprint. The Sprint Backlog captures all the work which the developers identify as necessary, to meet the Sprint Goal.
The Sprint Backlog is a plan by and for the Developers. The Sprint Backlog is made up of:
1) The Sprint Goal.
2) The Product Backlog items selected for the Sprint.
3) The actionable plan for delivering them are together as an increment and realizing the Sprint Goal.
Each task in the Sprint backlog could be assigned to one developer or a pair of developers, but the ownership is still shared across all the Developers in the Scrum Team. Developers can assign or distribute the work as needed. (Self-managing)

In the Sprint Retrospective:
1) The Scrum team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.
2) The Scrum Team discusses:

• What went well during the Sprint.
• The problems they encountered.
• How those problems were (or were not) solved.

The Scrum team identifies and orders the major items that went well along with the potential improvements.

During the Sprint:

• No changes are made that would endanger the Sprint Goal.
• Quality should not decrease.
• Scope may be clarified and re-negotiated between the Product Owner and Developers as more is learned.

The Product Backlog items should not be postpone the testing as it would compromise on the quality.

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

Artifact commitments are part of the existing artifacts and as such whoever is accountable for that artifact is accountable for that commitment. Product Goal is created by the Product Owner working with the Scrum Team. The Sprint Goal is created by the Scrum Team. And, the Definition of Done is created by the Scrum Team.

The entire Scrum Team is:
1) Responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research, development, documentation and anything else that might be required.
2) Accountable for creating a valuable, useful Increment every Sprint.

The Scrum Master is accountable for the Scrum Team’s effectiveness.

Developers in the Scrum Team self-organizes and selfmanage to undertake the work in the Sprint Backlog, during Sprint Planning and as needed throughout the Sprint. They coordinate with the Product Owner as needed.

The purpose of the Daily Scrum is:
1) To inspect progress made by the developers toward the Sprint Goal
2) Adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint.
If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers

The Product Owner is accountable for the development and communication of the Product Goal; however, they would work with the Scrum Team and stakeholders to make sure that it is clear and easy to understand.

The Product Owner should ensure that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.

In Scrum, the source of all requirements and changes is the Product Backlog.