PSM II – PSM and PSPO

Scrum Artifacts are:

• Product Backlog.
• Sprint Backlog.
• Increments.

Remember. Scrum Teams are cross-functional teams having all the skills (as a team) needed to create a Product Increment.
Scrum Teams are Self-managing which means they internally decide who does what, when, and how.
Self-managing teams:
1) Manage their own work.
2) Decide how to achieve goals.
3) Grow as a team.
4) Continuously improve.
5) Manage stakeholders.
6) Help other teams and co-workers to grow, improve and thrive.
7) Constantly collaborate with other teams, pinpoint improvements and learn fast, making them more motivated and productive.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the
Increment.
If a Product Backlog item does not meet the Definition of Done, it returns to the Product Backlog for future consideration.
All members of a Scrum Team must have a shared understanding of what it means for work to be complete, to ensure transparency.

The Product Owner is responsible for managing the Product Backlog maximizing the value of the Product. He can add remove items as needed from the Product Backlog. The Product Owner is 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 increment should be usable and valuable at the end of every Sprint, but it does not have to be “released” by the Product Owner.

Multiple Scrum Teams can work on the same product. Developers in each team would typically maintain their own Sprint Backlog and pull work from the Product Backlog during Sprint Planning. This has to be in agreement with the Product Owner.

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.

It is the responsibility of the Developers to work with the other Scrum Teams members as needed to make sure that their Sprint work is aligned to create an integrated Increment.

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.

The Daily Scrum is a 15 -minute time-boxed event for the Developers. The Daily Scrum is held every day of the Sprint at the same place and same time to maintain consistency.
Remember, it’s not just the Daily Scrum Meeting. All Scrum events should be held at the same time and place to reduce complexity.

The Scrum Guide no longer states this as a rule. There may be times when a Scrum Team decides not to plan any actionable improvements in a Sprint. The intention behind this change is to no longer prescribe this practice, and instead, let the Scrum Team decide. However, remember that inspection without adaptation is pointless.

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.

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum is founded on:
1) Empirical process control theory, or Empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.
2) Lean Thinking: Lean thinking reduces waste and focuses on the essentials.

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.

Documenting all the requirements at the same time is not preferred or advised. Instead the Product Owner should focus more on the items which are going to be picked up in the sprint. He / she may continue to elaborate on the rest of the items as he / she find the time.

The Sprint Goal is the single objective for the Sprint. Every increment created under the guidance of the Sprint Goal is a concrete steppingstone toward the Product Goal. Thus, all the Sprint Goals should be all aligned.

It is the responsibility of the Developers to work with the other Scrum Teams members as needed to make sure that their Sprint work is aligned to create an integrated Increment.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

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.

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?

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

An Increment is the sum of all the Product Backlog items completed during the Sprint plus the value of the increments of all previous Sprints.
An Increment is a concrete steppingstone toward the Product Goal.
Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.
In order to provide value, the Increment must be usable.
An Increment may be delivered to stakeholders prior to the end of the Sprint.

During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting an improved definition of “Done”, if appropriate and not in conflict with product or organizational standards. Typically, it is advised to wait for the Sprint retrospective to improve the terms of quality in the Definition of “Done” for the product, however it’s not mandatory and can be changed right away.

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.

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.

The Product Owner is accountable for managing the Product Backlog. He / she is also accountable for maximizing the value of the Product and the work the Developers do
The Product Owner is accountable for:
1) Creating the Product Goal.
2) Explicitly communicating the Product Goal.
The entire Scrum team is responsible for creating the Sprint Goal.

The Scrum framework does not require the same Sprint length or aligned Sprints for all teams. So, the start date can be different. However, the Sprint length should not be shortened or lengthened.

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.

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

Different Teams working on the same Product:

• Must have the Same Product Backlog.
• Must have the Same Product Owner.
• Must have the Same Product Goal.
• Must have different Sprint Backlogs. (one for each team)
• Must have a shared Definition of Done.
• Can have different Sprint Lengths.
• Can have different Scrum Masters.