1. Events
1.1. Sprint
1.1.1. Container
1.1.1.1. Minimizing risk
1.1.1.2. Events
1.1.1.2.1. Planning
1.1.1.2.2. Daily
1.1.1.2.3. Review
1.1.1.2.4. Retrospective
1.1.1.3. Development work
1.1.2. Maximum 1 month
1.1.3. No changes endangering sprint goal
1.1.4. No reduction of quality
1.1.5. Negotiable between dev team and PO as more is learned
1.1.6. Goal
1.1.6.1. Enables inspection
1.1.6.2. Enables adaptation
1.1.7. Can be cancelled by PO if goal is obsolete
1.1.7.1. All done / completed items are reviewd
1.1.7.2. All unfinisched items are re-estimated and put back on backlog
1.2. Planning
1.2.1. Maximum 8 hours
1.2.2. What can be delivered
1.2.2.1. Chosen by dev team from the ordered backlog
1.2.3. How can it be delivered
1.2.3.1. May renegotiate with PO
1.2.3.2. May invite others
1.2.4. Input
1.2.4.1. Backlog
1.2.4.2. Last increment
1.2.4.3. Projected capacity
1.2.4.4. Past performance
1.2.5. Output
1.2.5.1. Goal
1.2.5.1.1. Crafted by scrum team
1.2.5.1.2. Guidance to the dev team
1.2.5.1.3. Anchor for potential negotiation of the scope
1.2.5.2. Sprint backlog
1.2.5.2.1. Selected backlog items
1.2.5.2.2. Plan to implement
1.2.5.2.3. Tasks for the next days
1.2.6. Formal event to inspect and adapt
1.2.7. Done by the whole scrum team
1.3. Daily Standup
1.3.1. Maximum 15 minutes
1.3.2. Synchronize activities
1.3.2.1. What has be done for the sprint goal
1.3.2.2. What will be done for the sprint goal
1.3.2.3. What are the impediments
1.3.2.3.1. For me
1.3.2.3.2. For the dev team
1.3.2.4. Project likelihood to reach Sprint Goal
1.3.3. Create plan for next 24 hours
1.3.3.1. Inspect work of last day
1.3.3.1.1. Inspect progress trend towards sprint goal
1.3.3.2. Forecast work
1.3.3.2.1. Optimizes probability to reach goal
1.3.3.3. Adapt
1.3.3.3.1. Improve communication
1.3.3.3.2. Eliminate other meeting
1.3.3.3.3. Identify impediments
1.3.3.3.4. Improve knowledge
1.3.3.3.5. Enables quick decisions
1.3.4. Same time
1.3.4.1. Same place
1.3.5. Responsibility
1.3.5.1. Dev team
1.3.6. Members
1.3.6.1. Only dev team as participants
1.3.6.2. Visitors are not allowed to participate
1.4. Refinement
1.4.1. Inspect increment
1.4.2. Adapt backlog if needed
1.4.3. Members
1.4.3.1. Scrum team
1.4.3.2. Stakeholders
1.4.3.2.1. Invited by PO
1.4.4. What could be done next to optimize value
1.4.5. Maximum 4 hours
1.4.6. Output
1.4.6.1. PO explains sprint log items
1.4.6.1.1. done
1.4.6.1.2. not done
1.4.6.2. Lessons learned
1.4.6.2.1. What went well
1.4.6.2.2. What went wrong
1.4.6.2.3. How were problems solved?
1.4.6.3. PO discusses backlog
1.4.6.3.1. Projected done dates
1.4.6.4. Joint discussion of what to do next
1.4.6.5. Review on how marketplace may have changed may impact next anticipated release
1.4.6.5.1. Timelines
1.4.6.5.2. Budget
1.4.6.5.3. Capabilities
1.4.6.6. Revised product backlog
1.5. Retrospective
1.5.1. Maximum 3 hours
1.5.2. What went well?
1.5.3. What are potential improvements?
1.5.3.1. Plan to implement
1.5.4. Opportunity for self inspection
1.5.4.1. People
1.5.4.2. Relations
1.5.4.3. Processes
1.5.4.4. Tools
1.5.5. How can the definition of done be improved?
1.5.6. Members
1.5.6.1. Scrum Team
2. Roles
2.1. Product Owner
2.1.1. Product Backlog Management
2.1.1.1. Clearly expressing backlog items
2.1.1.1.1. Visible
2.1.1.1.2. Transparent
2.1.1.1.3. Clear to all
2.1.1.1.4. Shows what is done next
2.1.1.2. Ordering by value
2.1.1.3. Optimizing value of work
2.1.1.4. Assuring the development team understands items to the level needed
2.1.1.5. Ensuring transparency
2.1.2. Responsible as a person
2.2. Scrum Master
2.2.1. Servant leader
2.2.2. For PO
2.2.2.1. Supporting development team on understanding the backlog
2.2.2.2. Ensures scrum is understood and enacted
2.2.2.3. Understanding and practicing agility
2.2.2.4. Supporting PO on backlog management techniques
2.2.2.5. Coaching PO on planning in empirical environment
2.2.2.6. Facilitating events as needed
2.2.3. For dev team
2.2.3.1. Coaching
2.2.3.1.1. Self-organization
2.2.3.1.2. Cross-functionality
2.2.3.1.3. In environments where scrum is not fully understood and adopted
2.2.3.2. Helping to create high value
2.2.3.3. Removing impediments
2.2.3.4. Facilitating events as needed
2.2.4. Organization
2.2.4.1. Agile coaching
2.2.4.1.1. Learing
2.2.4.1.2. Convincing
2.2.4.1.3. Change
2.2.4.2. Planning scrum implementation
2.2.4.3. Helping employees and stakeholders to understand and enact scrum
2.2.4.4. Causing change to increase productivity
2.2.4.5. Working with other Scrum Masters to increase productivity
2.2.5. Transparency
2.2.5.1. Ensure artifact transparency
2.2.5.2. Foundation for decision
2.3. Development Team
2.3.1. Cross-functional
2.3.2. Self-organizing
2.3.3. No titles
2.3.4. No sub-teams
2.3.5. Rsponsible as a whole
2.3.6. Size
2.3.6.1. Minimum 3
2.3.6.2. Maximum 9
2.4. Team Model
2.4.1. Creativity
2.4.2. Flexibility
2.4.3. Productivity
3. Artifacts
3.1. Represents
3.1.1. Work
3.1.2. Value
3.2. Opportunities
3.2.1. Inspection
3.2.2. Adaptation
3.3. Goal
3.3.1. Maximize transparency of key information
3.4. Product backlog
3.4.1. Ordered list
3.4.1.1. Features
3.4.1.2. Functions
3.4.1.3. Requirements
3.4.1.4. Enhancements
3.4.1.5. Fixes
3.4.1.6. Attributes
3.4.1.6.1. Description
3.4.1.6.2. Order
3.4.1.6.3. Estimate
3.4.1.6.4. Value
3.4.1.6.5. (Scrum team to implement)
3.4.2. Single source
3.4.3. Never complete
3.4.4. Living artifact
3.4.5. Refinement
3.4.5.1. Ongoing process
3.4.5.2. Not more than 10% of capacity
3.4.5.3. When and how defined by scrum team
3.4.5.4. Product backlog can be updated anytime by PO
3.4.6. Items that can be done within one sprint are marked ready
3.4.7. Progress toward goal updated at least every review by PO
3.4.7.1. Burn-down
3.4.7.2. Burn-up
3.4.7.3. Cumulative flows
3.5. Sprint backlog
3.5.1. List of items from backlog for sprint
3.5.2. Plan to deliver increment
3.5.3. Evolves durring sprint
3.5.4. Can only be changed by dev team
3.5.5. Updated at least for every daily Scrum
3.6. Increment
3.6.1. Sum of completed backlog items from last sprint
3.6.2. Value of all previous increments
3.6.3. Additive to prior increments
3.7. Transparency
3.7.1. Responsibility of the SM to increase transparency
3.7.2. Responsibility of the SM to track any gaps in communication
4. Authors
4.1. Ken Schwaber
4.2. Jeff Sutherland
5. Values
5.1. Commitment
5.2. Courage
5.3. Focus
5.4. Openness
5.5. Respect
6. Pillars
6.1. Transparency
6.1.1. Common language
6.1.2. Shared definition of done
6.1.3. Visible
6.2. Inspection
6.2.1. Frequent
6.2.1.1. Not so frequent it blocks work
6.3. Adaptation
6.3.1. Adjustment when defined thresholds are not met
6.3.2. Events for inspection and adaptation
6.3.2.1. All but the scrum container itself
7. Rules
7.1. Binding
7.1.1. Events
7.1.2. Roles
7.1.3. Artifacts
7.2. Governing
7.2.1. Relationships
7.2.2. Interaction
7.3. Described in the Scrum Guide
8. Framework
8.1. Targeting complex adaptive problems
8.2. Essential components
8.2.1. Scrum teams
8.2.2. Roles
8.2.3. Events
8.2.4. Artifacts
8.2.5. Rules
8.3. Attributes
8.3.1. Produces high value
8.3.2. Productive
8.3.3. Creative
8.4. Theory
8.4.1. Empirical process control
8.4.2. Knowledge comes from experience
8.4.2.1. Decisions based on experience
8.4.3. Optimize predictability
8.4.4. Control risk
9. History
9.1. OOPSLA conference in 1995
9.2. The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka 1986
10. Related (non-original) Topics
10.1. Agile Manifesto
10.1.1. Individuals & Interactions over Processes & Tools
10.1.2. Working Software over Comprehensive Documentation
10.1.3. Customer Collaboration over Contract Negotiation
10.1.4. Responding to Change over Following a Plan
10.1.5. Principles
10.1.5.1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
10.1.5.2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
10.1.5.3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
10.1.5.4. Business people and developers must work together daily throughout the project.
10.1.5.5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
10.1.5.6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
10.1.5.7. Working software is the primary measure of progress.
10.1.5.8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
10.1.5.9. Continuous attention to technical excellence and good design enhances agility.
10.1.5.10. Simplicity--the art of maximizing the amount of work not done--is essential.
10.1.5.11. The best architectures, requirements, and designs emerge from self-organizing teams.
10.1.5.12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
10.2. User Stories
10.2.1. https://medium.com/@bhuvana.murthy/agile-ux-good-user-story-is-about-sizing-3056c171
10.2.2. INVEST
10.2.2.1. Independent
10.2.2.2. Negotiable
10.2.2.3. Vauable
10.2.2.4. Estimable
10.2.2.5. Small
10.2.2.6. Testable
10.2.3. Connextra, UK, 2001