PSM II – PSM and PSPO

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 Product Backlog is never complete and is always evolving. It is a living artifact. It does not get finalized in any of the Sprints.

The System’s architecture is decided throughout the project, as understanding emerges and the Scrum Team learns more about the project.

Scrum Values give direction to the Scrum Team with regard to their work, actions, and behavior. They also help define the work ethics the Scrum team should have. The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts. Different Scrum Values are:
1. Commitment: The Scrum Team members personally commit to achieving the Scrum Goals and to supporting each other.
2. Courage: The Scrum Team members have courage to do the right thing and work on tough problems.
3. Focus: Everyone focuses on the work of the Sprint and the best possible progress made toward the goals of the Scrum Team.
4. Openness (No Hiding): The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.
5. Respect: Scrum Team members respect each other to be capable, independent people. Scrum Team members are respected by the people with whom they work.

All Scrum Values are all impacted by lack of trust or transparency. Strength is not a value.

In the Short term, the productivity will decrease because the new teams will spend time to get up to speed with the Product. The old team will spend a lot of time communicating and training the new team.

Scrum is a lightweight framework that helps people, teams and organizations generate value by creating adaptive solutions for complex problems. The Scrum framework is purposefully incomplete and only defines the parts required to implement Scrum theory. Scrum wraps around existing practices or renders them unnecessary. Scrum brings transparency to the effectiveness (or ineffectiveness) of the current management, environment, and work techniques, so that improvements can be made.

In the real world, almost every sprint will have at least one or two sprint backlog items which won’t be completed. In such situations, Developers will work with the Product Owner to move it back to the Product Backlog. These items would typically (and not always) be moved to the Next Sprint Backlog from the Product Backlog, through the Product Backlog.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project. Sprints are limited to one calendar month or shorter. The length of a Sprint thus could be Weekly, Biweekly or Monthly. Sprint should be short enough to keep the risk acceptable to the Product Owner.

As a self-organized team, the scrum team (including the Developers) will decide for themselves how to best manage communication between team members. 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 re-planning the rest of the Sprint’s work. The Scrum Master will only act if requested or if he/she observes that there is a potential problem.

The Scrum Master serves the Product Owner by:
1) Helping the Product Owner find techniques for effective Product Goal definition and Product Backlog management.
2) Helping the Scrum Team understand the need for clear and concise Product Backlog items.
3) Helping establish empirical product planning for a complex environment
4) Facilitating stakeholder collaboration as requested or needed.

During the Sprint Review, the Scrum Team and Key Stakeholders (people outside the Scrum Team) collaborate to discuss and review:
1) What was achieved / accomplished in the current Sprint?
2) What has changed in their environment?

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.

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.

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

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 Daily Scrum is a 15-minute event for the Developers of the Scrum Team. Since it is a meeting is for the Developers, it is expected that the needed Developers would attend the Daily Scrum. The
Scrum Master ensures that Developers in the Scrum Team have the Daily scrum meeting however does not have to be present himself in the meeting. If people outside the Scrum Team are present in the Daily Scum, the Scrum Master ensures that they do not disrupt the meeting. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

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

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.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next.

Sprint Review is a meeting in which the stakeholders see what was done. They also collectively decide on what needs to be done in the next sprint. Everything which needs to be done flows through the Product backlog. Thus, the result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.

Remember not all the incomplete items get moved to the top of the Product Backlog or the next Sprint Backlog. While this might be common, the next sprint priorities might change, and the incomplete items might be considered at a later point in time.

This question tries to confuse the reader by mentioning the Scrum Leaders past experience which has nothing to do with how the team should be selected in Scrum.

Providing the proper guidelines will help promote self-organization, creativity, and problem solving. The decisions on who and how to work together in order to deliver Valuable increments is best decided by the Scrum team and team members involved with doing the work.

Sub-team formations (or hierarchies) in the Scrum Team is not allowed. Sub-Teams such as testing teams or an operation teams are not allowed to be formed in the Scrum Team.

Titles are not assigned to the developers within the Scrum Team members, regardless of the type of work they perform.
Scrum Team collectively decides on the Scrum Length.
Scrum Team delivers a “Done ${ }^{n}$ product every Sprint to ensure a potentially useful version of a working product is always available. However, it is up to the Product Owner to “Release” it.

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.

Product Backlog refinement is an ongoing process which is the act of adding detail, estimates, and order to items in the Product Backlog. The Scrum Team decides how and when refinement is done.

The Scrum framework is purposefully incomplete. It only defines the parts required to implement Scrum theory.

A great Product Owner has a focus on functionality and the non-functional aspects of the product. Hours or even story points are less important. The goal of the Product Owner is to maximize value for the customer. It’s the functionality that has value; therefore, this is the main focus for the Product Owner.
A great Product Owner has in depth (non-)functional product knowledge and understands the technical composition. For large products it might be difficult to understand all the details and scaling the Product Owner role might be an option. However, the Product Owner should always know the larger pieces of the puzzle and hereby make conscious, solid decisions.

Sprint Review is a meeting where Members external to the Scrum Team can actively participate to give feedback.

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. 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.
The Sprint Backlog is created during the Sprint Planning. The Sprint Backlog includes:

1) Items selected from the Product Backlog.
2) Tasks created by decomposing the selected
Product Backlog items (during refinement).

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 purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The entire Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. During the Sprint Review, the Scrum Team and Key
Stakeholders (people outside the Scrum Team) collaborate to discuss and review:
1) What was achieved / accomplished in the current Sprint?
2) What has changed in their environment?

Scrum Teams should be Cross-functional teams that they should all the competencies needed to accomplish the work without depending on others outside the team.
Scrum Teams should have all the skills necessary to create value each Sprint. Scrum Teams should also be self-managing, meaning they internally decide who does what, when, and how.

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) Ensuring that the Product Backlog is visible, transparent, and clear to all.

The Product Owner can delegate above to others however remains accountable for it.

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 Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint. “At least one impactful improvement must be added to the Sprint Backlog for the next Sprint.” – This is no longer mandator based on the latest Scrum Guide.