1. to plan ways to increase quality and effectiveness
2. inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work
3. Sprint Retrospective
3.1. inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done
3.1.1. not the only time Developers are allowed to adjust their plan
3.2. discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved
3.3. identifies the most helpful changes to improve its effectiveness
3.3.1. addressed as soon as possible
3.3.2. may even be added to the Sprint Backlog for the next Sprint
3.4. concludes the Sprint
3.5. timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
4. Definition
4.1. Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions **for complex problems.**
5. Based On
5.1. **empiricism**
5.1.1. reduces waste and focuses on the essentials
5.1.2. asserts that knowledge comes from experience and making decisions based on what is observed
5.2. **lean thinking**
6. 15-minute event for the Developers of the Scrum Team
7. A Scrum Team is expected to adapt the moment it learns anything new through inspection.
8. primary focus is on the work of the Sprint to make the best possible progress toward these goals.
9. enabling the Scrum Team to improve its practices, within the Scrum framework
10. Events
10.1. Sprint
10.1.1. Turn ideas into value
10.1.2. fixed length events of one month or less
10.1.3. new Sprint starts immediately after the conclusion of the previous sprint (Retrospective)
10.1.4. Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints
10.1.5. During the Sprint
10.1.5.1. No changes are made that would endanger the Sprint Goal
10.1.5.2. Quality does not decrease
10.1.5.3. The Product Backlog is refined as needed
10.1.5.4. Scope may be clarified and renegotiated with the Product Owner as more is learned
10.1.6. A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint
10.2. Sprint Planning
10.2.1. laying out the work to be performed for the Sprint by the entire Scrum Team
10.2.2. may also invite other people to attend Sprint Planning to provide advice
10.2.3. address
10.2.3.1. Why is this Sprint valuable
10.2.3.2. What can be Done this Sprint
10.2.3.2.1. select items from the Product Backlog to include in the current Sprint
10.2.3.3. How will the chosen work get done
10.2.3.3.1. Developers decompose Product Backlog items into smaller work items of one day or less
10.2.4. timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
10.3. Daily Scrum
10.3.1. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
10.3.2. produces an actionable plan for the next day of work
10.3.3. improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
10.4. Sprint Review
10.4.1. inspect the outcome of the Sprint and determine future adaptations
10.4.2. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed
10.4.3. avoid limiting it to a presentation
10.4.4. Timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
11. Pillars
11.1. transparency
11.1.1. Transparency enables inspection. Inspection without transparency is misleading and wasteful.
11.2. inspection
11.2.1. Inspection enables adaptation. Inspection without adaptation is considered pointless.
11.3. adaptation
12. Values
12.1. Commitment
12.1.1. commits to achieving its goals and to supporting each other
12.1.1.1. Sprint Backlog
12.1.1.1.1. Sprint Goal
12.1.1.1.2. Selected Product Backlog
12.2. Focus
12.3. Openness
12.3.1. open about the work and the challenges
12.4. Respect
12.4.1. respect each other to be capable, independent people, and are respected as such by the people with whom they work
12.5. Courage
12.5.1. have the courage to do the right thing, to work on tough problems.
13. Team
13.1. consist of
13.1.1. Scrum Master
13.1.1.1. accountable for
13.1.1.1.1. establishing Scrum
13.1.1.1.2. he Scrum Team’s effectiveness
13.1.1.2. serves the Scrum Team
13.1.1.2.1. Coaching the team members in self-management and cross-functionality
13.1.1.2.2. Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done
13.1.1.2.3. Causing the removal of impediments to the Scrum Team’s progress
13.1.1.2.4. Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox
13.1.1.3. serves the Product Owner
13.1.1.3.1. Helping find techniques for effective Product Goal definition and Product Backlog management
13.1.1.3.2. Helping the Scrum Team understand the need for clear and concise Product Backlog items
13.1.1.3.3. Helping establish empirical product planning for a complex environment
13.1.1.3.4. Facilitating stakeholder collaboration as requested or needed
13.1.1.4. serves the organization
13.1.1.4.1. Leading, training, and coaching the organization in its Scrum adoption
13.1.1.4.2. Planning and advising Scrum implementations within the organization
13.1.1.4.3. Helping employees and stakeholders understand and enact an empirical approach for complex work
13.1.1.4.4. Removing barriers between stakeholders and Scrum Teams
13.1.2. Product Owner
13.1.2.1. maximizing the value of the product resulting from the work of the Scrum Team
13.1.2.2. may delegate the responsibility to others
13.1.2.3. one person, not a committee
13.1.3. Developers
13.1.3.1. committed to creating any aspect of a usable Increment each Sprint
13.1.3.2. accountable for
13.1.3.2.1. Creating a plan for the Sprint, the Sprint Backlog
13.1.3.2.2. Instilling quality by adhering to a Definition of Done
13.1.3.2.3. Adapting their plan each day toward the Sprint Goal
13.1.3.2.4. Holding each other accountable as professionals
13.2. cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how
13.3. small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people
13.3.1. smaller teams communicate better and are more productive
13.3.2. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product
13.3.2.1. share the same Product Goal, Product Backlog, and Product Owner.
13.4. responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required
13.5. structured and empowered by the organization to manage their own work
13.6. accountable for creating a valuable, useful Increment every Sprint
14. commitment
14.1. Sprint Goal
15. Work cannot be considered part of an Increment unless it meets the Definition of Done.
16. Artifacts
16.1. Product Backlog
16.1.1. ordered list of what is needed to improve the product
16.1.2. Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
16.1.3. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items.
16.1.3.1. This is an ongoing activity to add details, such as a description, order, and size
16.1.4. The Developers who will be doing the work are responsible for the sizing
16.1.4.1. The Product Owner may influence the Developers by helping them understand and select trade-offs.
16.1.5. commitment
16.1.5.1. Product Goal
16.1.5.1.1. a future state of the product
16.2. Sprint Backlog
16.2.1. plan by and for the Developers
16.2.2. updated throughout the Sprint as more is learned
16.2.3. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.
16.3. Increment
16.3.1. may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
16.3.2. commitment
16.3.2.1. Definition of Done
16.3.2.1.1. a formal description of the state of the Increment when it meets the quality measures required for the product
16.3.2.1.2. providing everyone a shared understanding of what work was completed as part of the Increment
16.3.2.1.3. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
16.3.2.1.4. If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
16.3.2.1.5. multiple Scrum Teams working on the same product must mutually define and comply with the same Definition of Done.