1. Purpose, Goal, Understanding
1.1. Theory
1.1.1. process framework
1.1.2. since early 1990s
1.1.3. makes clear relative efficiency of product + work techniques
1.1.4. empiriciscm as principle: Scrum Pillars
1.1.4.1. transparency
1.1.4.2. inspection
1.1.4.3. adaptation
1.2. Uses
1.2.1. esp. effective in iterative and incremental knowledge transfer
1.2.2. to research and identify viable markets, techniques and capabilites
1.2.3. to develop and releases products / increments
1.2.4. to develop an release services (e.g. cloud)
1.2.5. to sustain and renew products
1.3. Values
1.3.1. commitment
1.3.2. courage
1.3.3. focus
1.3.4. openness
1.3.5. respect
2. Scrum Team
2.1. Product Owner
2.1.1. only one person
2.1.2. only one responsible for Product Backlog
2.1.2.1. orders the Prod.Backlog Items
2.1.2.2. expresses the Prod.Backlog Items: that Dev.Team understands them
2.1.2.3. ensures that items are visible, transparent and clear to all
2.1.2.4. may delegate task to manage Prod.Backlog, but stays responsible
2.1.3. interface between stakeholders and Dev.Team
2.1.4. entire organization must respect decisions
2.1.5. decides whether "Done" will be released
2.2. Development Team
2.2.1. self-organizing
2.2.2. cross-functional
2.2.2.1. specialized professionals
2.2.3. deliver a potentially releasable increment of "Done" product
2.2.4. no role titles, no sub-teams
2.2.5. 3-9 people
2.3. Scrum Master
2.3.1. servant-leader to Scrum team
2.3.2. helps people to understand Scrum
2.3.2.1. Product Owner
2.3.2.2. Dev.Team
2.3.2.3. entire organization
3. Scrum Events
3.1. Sprint
3.1.1. <= 1 month time
3.1.2. for delivering a "Done" product increment
3.1.2.1. useable
3.1.2.2. potentially relesable
3.1.3. no gaps between Sprints
3.1.4. fixed Sprint Goal & quality expectations
3.1.5. scope may be clarified / re-negotiated with Prod.Owner
3.1.6. cancellation of a Sprint
3.1.6.1. only by the Product Owner
3.1.6.1.1. when Sprint Goals becomes absolete: company changes strategic direction / market or technology conditions change
3.1.6.2. happens seldom
3.1.6.3. negative influence on Dev.team's motivation
3.2. Sprint Planning
3.2.1. max. 8 hrs per Sprint
3.2.2. moderated by Scrum Master
3.2.2.1. Scrum Master: - ensures event will happen / stick to timeframe - help people to understand event / role
3.2.3. answers to 2 questions
3.2.3.1. What can be delivered?
3.2.3.1.1. Product Owner: - what is objective - which Prod.Backlog Items relate to the goal
3.2.3.1.2. Dev. Team: - decides about items to fulfill
3.2.3.2. How will the work be done?
3.2.3.2.1. detailed delivery plan for each selected item of Prod.Backlog
3.2.4. input
3.2.4.1. Prod. Backlog
3.2.4.1.1. items completed in latest increment with past performance
3.2.4.1.2. remaining items
3.2.4.1.3. Capacity in coming Sprint
3.2.5. output
3.2.5.1. Sprint Goal
3.2.5.1.1. clear objective what has to be delivered
3.2.5.2. Sprint Backlog
3.2.5.3. Dev.Team can explain to Product Owner & Scrum Master what will be done how to reach Sprint Goal
3.3. Daily Scrum
3.3.1. max 15 min. each day, same time, same place = routine, reduces complexity
3.3.2. review of day before (results, problems, need to re-plan/change)
3.3.2.1. = inspect progress toward the Sprint Goal and how progress is trending toward completing the work in the Sprint Backlog
3.3.3. plan for the coming day
3.3.4. structure set by the Development Team and can be conducted in different ways
3.3.4.1. questions and/or discussions
3.3.4.2. Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work
3.3.5. Scrum Master
3.3.5.1. ensures that Daily Scrum happens and within 15 min.
3.3.5.2. if others present, ensures that these do not disturb meeting
3.4. Sprint Review
3.4.1. max. 4 hrs., at end of Sprint
3.4.2. whole Scrum Team and stakeholders
3.4.3. to inspect increment delivered and to adapt Prod.Backlog
3.4.3.1. Dev.Team: - demonstrates increments, - answers questions about it
3.4.3.2. Product Owner: -discusses Prod.Backlog as is - projects likely targets and delivery dates
3.4.3.3. together: - what to do next - review of marketplace / potential use changes - review of timeline, budget, potential capabilities, and marketplace for next anticipated releases of functionality or capability
3.4.4. output
3.4.4.1. revised Product Backlog - defined probable Product Backlog items for the next Sprint
3.5. Sprint Retrospective
3.5.1. max 3 hrs (shorter sprint = shorter)
3.5.2. prior to next Sprint Planning
3.5.3. whole Scrum Team
3.5.3.1. plans ways to increase product quality by improving work processes or adapting the definition of "Done"
3.5.4. Scrum Master
3.5.4.1. ensures: - that the event takes place - that attendants understand its purpose - that all keep within time-box
3.5.4.2. participates as a peer team member in the meeting from the accountability over the Scrum process
3.5.4.3. encourages the Scrum Team to improve, development process and practices to make it more effective and enjoyable
3.5.5. purpose
3.5.5.1. Inspect how the last Sprint went with regards to people, relationships, process, and tools
3.5.5.2. Identify and order the major items that went well and potential improvements
3.5.5.3. Create a plan for implementing improvements to the way the Scrum Team does its work
3.5.6. output
3.5.6.1. identified improvements that will be implemented in the next Sprint
4. Artifacts
4.1. Product Backlog
4.1.1. Product Owner is only responsible person for it
4.1.1.1. orders items at will (suitable only for more efficiency)
4.1.1.2. tracks total work remaining at least every Sprint Review
4.1.1.3. compares progress made in current sprint with effort in prior sprints
4.1.1.3.1. transparent for all stakeholders
4.1.2. "living document"
4.1.2.1. single source of requirements for any changes to be made to the product
4.1.2.2. earliest development of it lays out the initially known and best-understood requirements.
4.1.2.3. evolves during product development
4.1.2.4. assists as long as product exists
4.1.3. features
4.1.3.1. ordered list of everything that is known to be needed in the product
4.1.3.1.1. Higher ordered items are usually clearer and more detailed than lower ordered ones
4.1.3.1.2. estimates only by Dev.Team
4.1.3.2. lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases
4.1.3.3. items have the attributes of a description, order, estimate, and value. sometimes
4.1.3.4. sometimes items include test descriptions that will prove its completeness when "Done"
4.1.3.5. if multiple teams work: one Product Backlog with group attribute for items
4.1.3.6. refinement
4.1.3.6.1. act of adding detail, estimates, and order to items in the Product Backlog
4.1.3.6.2. collaborative, ongoing work of Prod.Owner and Dev.Team
4.1.3.6.3. consumes usually no more than 10% of the capacity of the Dev.Team
4.2. Sprint Backlog
4.2.1. set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal
4.2.1.1. with enough detail that changes in progress can be understood in the Daily Scrum
4.2.1.2. As new work is required, the Development Team adds it to the Sprint Backlog
4.2.2. forecast by the Development Team
4.2.2.1. As work is performed or completed, the estimated remaining work is updated
4.2.2.2. At any point, total work remaining in the Sprint Backlog can be summed
4.2.3. makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal
4.2.4. includes at least one high priority process improvement identified in the previous Retrospective meeting
4.2.5. Dev.Team is only responsible
4.3. Increment
4.3.1. sum of all the Product Backlog items completed during a Sprint and the value of all previous increments
4.3.2. body of inspectable, done work that supports empiricism = tested, useable and potentially releasable
4.4. transparency
4.4.1. Decisions to optimize value and control risk are made based on the perceived state of the artifacts.
4.4.2. Scrum Master's role to improve transparency
4.4.2.1. must help Scrum Team with practices for coping with incomplete transparency
4.4.2.2. work with the Scrum Team and the organization to increase the transparency of the artifacts
4.4.3. definition of "Done"
4.4.3.1. everyone must understand what "Done" means (what it means for work to be complete)
4.4.3.1.1. If definition of "Done" is part of conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.
4.4.3.1.2. if multiple Scrum Teams: all Development Teams must mutually define the definition of "Done".