1. During Sprint Planning, the PO ensures that attendees are prepared to discuss the most important PBIs and how they map to the Product Goal.
2. During Sprint Planning we answer three important questions: a) Why is this Sprint Valuable? b) What can be done this Sprint? c) How will the chosen work get done?
3. The entire Scrum Team attends and collaborates on creating the Sprint Goal.
4. The Developers decide how many PBIs to select for the Sprint Backlog.

1. The developers decide on the practices to use to turn PBIs into a usable increment.
2. The more the Developers know about their past performance, upcoming capacity, and the DoD, the more accurate forecasts they will be able to do.
3. The Sprint Backlog is created during Sprint Planning and it is a combination of 3 things. i) The Sprint Goal ii) the selected PBIs, and iii) a Plan to deliver them.
4. The Scrum Team may invite other people to attend Sprint Planning to provide advice.
5. Sprint Planning is 8 hours for a 1-month Sprint and is usually shorter for shorter Sprints.

1. The Developers are the people in the Scrum Team who create any aspect of a usable increment during the Sprint.
2. The specific skills of the Developers will vary a lot depending on the work domain, i.e. they do not have to be software developers. Still, they could be scientists, researchers, manufacturers, etc.

1. The Developers create the plan for Sprint, this is the Sprint Backlog.
2. The Developers choose how many PBIs need to be included in a Sprint.
3. They are responsible for sizing (estimating) the PBIs and the techniques they would use to turn PBIs into usable increment
4. Developers participate in Daily Scrum and come up with an actionable plan for the day.
5. Developers are required to conform to the DoD (Definition of Done)
6. The Developers hold each other accountable as professionals.

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.