1. An Increment is a stepping stone toward the Product Goal.
2. Each Increment is additive to all prior increments.
3. The sum of all Increments is presented to Stakeholders at the Sprint Review. However, Increments can be released to Stakeholders at any time.

1. The Scrum Team has to create one or more useful Increments each Sprint.
2. All Increments must be verified and usable.
3. The whole Scrum Team decides when to release an Increment.
4. Multiple increments can be released to stakeholders during a Sprint.
5. Work cannot be considered part of an Increment unless it meets the Definition of Done (DoD).
6. The commitment for the Increment is the DoD.

1. The Scrum Master (SM) is accountable for:
   • Establishing Scrum (as per the Scrum Guide) in the Scrum team and the Organization
   • The Scrum Teams effectiveness
2. The SM is a true leader who serves:
   • The Scrum Team by:
     • Causing the removal of impediments to the Scrum Team’s progress
     • Ensuring that all Scrum events that take place and are positive, productive, and kept within the timebox
   • The Product Owner by:
     • Helping find techniques for effective Product Goal Definition & Product Backlog Management
     • Facilitating stakeholder collaboration as needed.
   • The Organization by:
     • Leading, coaching & training them on Scrum adoption.

1. If the SM (or PO) is actively working on PBIs in a Sprint, they do so as “developers”.
2. The SM acts as a team coach and teacher. They manage not the people but the process.
   • They possess what’s called “Process Authority” and make sure everyone understand and embraces the Scrum theory, values, rules, and practices.
3. The Scrum Master is NOT a Project Manager
   • A Project Manager role does not exist in Scrum
4. The SM can work part-time as well as full-time.
5. Scrum doesn’t prohibit one person to act as a SM and a PO but it doesn’t recommend it either.
6. The SM can work on multiple Products & Product Teams.

1. The Product Backlog (PB) is an ordered list of what is needed to improve the product.
2. The PB is the single source of work undertaken by the Scrum Team.
3. Product Backlog Items (PBIs) that can be completed in 1 Sprint are considered “ready” for selection for a Sprint during Sprint Planning.
4. The Product Owner orders the PB in a way to maximize product value.
5. The Product Backlog will exist as long as the Product exists. It is ever-changing and dynamic.

1. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This includes adding detail such as:
   • Description
   • Order
   • Size
   • Etc
2. PBI attributes (e.g. description, order) often vary depending on the domain of work.
3. PBI’s on the top of the PB are more refined and hence smaller than PBI’s at the bottom.
4. The Product Backlog can be refined at any time as needed.
5. Multiple Scrum teams can share the same Product (and they would then have the same
6. Product Backlog, Product Owner & Product Goal).
7. Only the Developers can determine the size (estimate effort involved) for Product Backlog Items.
8. Product Backlog Refinement is an ongoing activity done by the PO and the Developers.
9. “A Product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.” – Scrum Guide 2020.

1. Only the PO can cancel the Sprint.
2. The PO is the expert on the marketplace for the Product.
3. During Sprint Planning, the PO brings a business objective, based on which the Scrum Team crafts a Sprint Goal.
4. There can only be one PO for a product. But a PO can work on multiple products.
5. During Sprint Review, the PO seeks feedback from key stakeholders.
6. A PO can also work as a developer on the team.
7. The PO can attend, but cannot “participate” in Daily Scrum meetings, except in the capacity of a developer.
8. The PO can attend but cannot participate in any PBI sizing (estimation) activities e.g. during Sprint Planning