PSM II – PSM and PSPO

Different Scrum Teams working on the same product can have different Sprint length. The duration of a Sprint is fixed and should not be shortened or lengthened once the Sprint has started. 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 based on the quick feedback loops from the stakeholders.
Shorter Sprints limit risk of cost to a smaller time frame Limit risk of effort to a smaller time frame.

Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. To help with inspection, Scrum provides cadence in the form of its five events. Scrum prescribes five mandatory events for Inspection and Adaptation:
1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective
5. The Sprint (Container of the above four events).
The event that contains the four formal events is called the Sprint.

Each artifact contains a commitment. Commitment ensure that:
1) It provides information that enhances transparency.
2) It provides focus against which progress can be measured.
3) They exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

Like any other debt, a large accumulation of Technical Debt (bad code) can impact future maintainability of the product. The downsides of Technical Debt are as follows:
1. It misleads the Product Owners, Scrum Masters and even the developers with their assumptions about the “Current state” of the System. For example, if Product Backlog item $\mathrm{A}$ is assumed to be completed in a day, it might take three days for it to complete, because of unseen bad code or Technical Debt.
2. The Product becomes more unstable, as more functionality is added over bad code (or existing technical debt). Example: Let’s assume that the team decided to delay some important refactoring to facilitate an early release. Technical debt starts to accrue at that point, and it may not map cleanly to specific items on the Product Backlog. It is far more likely to impact components which crosscut a range of features. Moreover, if the necessary refactoring is significant it could impact the entire product, and it could affect features in uneven ways.

Remember, although Management does not actively involve itself in the Daily Scrum meetings, it does not mean they have no role at all. Management supports the Product Owner with insights and information needed to develop a high value product. They also Support the Scrum Master to cause organizational change that fosters empiricism, self-organization, bottom-up intelligence and intelligent release of software. Management external to the Scrum team is incredibly important in setting the vision and strategy to guide the overall direction of the organization.

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create an improvement plan which can be enacted. The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints or shorter.

During Sprint Planning, through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The selected items get moved to the Sprint Backlog. The Scrum Team may refine these items during this process, which increases understanding and confidence.

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

Every day in the Daily Scrum meeting, the Developers understands how they intends to work together (as a self-Managing team) to accomplish the Sprint Goal. Developers also work towards creating the anticipated Increment along with the rest of the team by the end of the Sprint.

The current items selected for a Sprint have been selected as most valuable with the Product Owner. These items serve the Sprint’s goal. No changes should be made that endanger the Sprint Goal. No one external to the Scrum Team can force changes on the Developers (Sprint Backlog) and the Product Owner (Product Backlog).
All changes which need to be made to the Product show flow through the Product Backlog and the Product Owner.

The Product Owner decides the order of the Product Backlog based on the complexity, risk, dependency and size of each Product Backlog item.

A Scrum team can only have one “active” Product Goal, so when the current Product Goal is achieved a new one would be created. This is the one Product Goal; the entire Scrum team focuses on.

A single Increment is needed at the end of the Sprint. Regardless of the number of teams, the teams should merge their code to have one single valuable Increment by the End of the Sprint. The Product owner and stakeholders would not be able to inspect the increment accurately if the code is not merged.

Scrum is:
A. Not a process, technique, or definitive method.
B. A framework within which can employ various processes and techniques.
C. Employs an iterative, incremental approach to optimize predictability and to control risk.
D. Lightweight.
E. Simple to understand.
F. Difficult to master.

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.

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.

People outside the Scrum Team can attend the Daily Scrums; however, they cannot participate (participate actively). They are involvement is controlled and guided by the Scrum Master.
Remember that the developers might need help from other business or technical users. The Team might invite others on the call to have a few questions answered. People outside the Scrum team can attend this meeting however they cannot actively participate. Only the Developers can actively participate in the ongoing Daily Scrum Calls.

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 at most a four-hour meeting for one-month Sprints. (Or shorter)

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 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. The Sprint Review is a working session and the Scrum Team should avoid limiting it to just a presentation.

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.

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.

Since iterations are timeboxed, the duration won’t be changed. You also wouldn’t change the iteration plan or expand the team. Instead, work that isn’t completed within the iteration is returned to the Product backlog. Therefore, the choice of completing 8 points and returning 12 points to the backlog is the correct option. Remember it’s not always necessary that the incomplete work would be picked up in the next Sprint, so that option is invalid.

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.

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint
Review, and Sprint Retrospective, happen within Sprints. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month.
The heart of Scrum is a Sprint where ideas are turned into value.
Sprint a time-box of one month or less during which a “Done”, useable, and potentially releasable Product Increment is created.

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 real world, almost every sprint will have at least one or two sprint backlog items which won’t be completed. In such situations, the Developers will work with the Product Owner to move it back to the Product Backlog. These items might (and not necessarily) be moved to the Next Sprint Backlog from the Product Backlog, if they are needed for the next sprints goal.

The Scrum Master is accountable for the Scrum Team’s effectiveness. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps change interactions to maximize the value created by the Scrum Team. The Scrum Guide Says the following:
The Scrum Master serves the Scrum Team by:
1) Coaching the team members selfmanagement and cross-functionality.
2) Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done.
3) Removing impediments to the Scrum Team’s progress.
4) Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

During the Sprint Review, the Scrum Team and Key Stakeholders (people outside the Scrum Team) collaborate about what was done in the Sprint. In the Sprint Review the next things that could be done to optimize value is also reviewed. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.

Developers in the Scrum Team are responsible for all estimates in the Product Backlog. The Product Owner may influence the Developers by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.