1. Theory
1.1. Empiricsm
2. Three pillar
2.1. Transparancy
2.2. Inspection
2.3. Adaptation
3. Value
3.1. commitment
3.2. courage
3.3. focus
3.4. openness
3.5. respect
4. Scrum team
4.1. Team
4.1.1. Product Owner
4.1.1.1. Sole person responsible for managing the Product Backlog
4.1.1.2. remains accountable of product backlog
4.1.2. Development Team
4.1.2.1. self-organizing
4.1.2.2. cross-functional
4.1.2.3. No titles
4.1.2.4. No sub-teams
4.1.2.5. Accountability belongs to the Development Team
4.1.2.6. Team size ( 3 ~ 9 )
4.1.2.6.1. < 3
4.1.2.6.2. > 9
4.1.2.6.3. Not include Product Owner And Sprint Master
4.1.3. Scrum Master
4.2. Designed
4.2.1. optimize flexibility
4.2.2. creativity
4.2.3. productivity
4.3. Deliver
4.3.1. iteratively
4.3.2. incrementally
4.3.3. maximizing opportunities for feedback
5. Scrum Master
5.1. Service to the Product Owner
5.1.1. Ensuring goals, scope, and product domain are understood by everyone
5.1.2. Finding techniques for effective Product Backlog management
5.1.3. Helping the Scrum Team understand the need for clear and concise Product Backlog items
5.1.4. Understanding product planning in an empirical environment
5.1.5. Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value
5.1.6. Understanding and practicing agility
5.1.7. Facilitating Scrum events as requested or needed
5.2. Service to the Development Team
5.2.1. Coaching the Development Team in self-organization and cross-functionality
5.2.2. Helping the Development Team to create high-value products
5.2.3. Removing impediments to the Development Team’s progress
5.2.4. Facilitating Scrum events as requested or needed
5.2.5. Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
5.3. Service to the Organization
5.3.1. Leading and coaching the organization in its Scrum adoption
5.3.2. Planning Scrum implementations within the organization
5.3.3. Helping employees and stakeholders understand and enact Scrum and empirical product development
5.3.4. Causing change that increases the productivity of the Scrum Team
5.3.5. Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization
6. Scrum Event
6.1. The Sprint
6.1.1. Time
6.1.1.1. <= 1 month Is OK
6.1.1.2. > 1 month
6.1.1.2.1. definition of what is being built may change
6.1.1.2.2. complexity may rise
6.1.1.2.3. risk may increase
6.1.2. Cancel
6.1.2.1. Only the Product Owner has the authority
6.1.2.2. May do so under influence from the stakeholders, the Development Team, or the Scrum Master
6.1.2.3. Sprint Goal becomes obsolete
6.1.2.3.1. company changes direction
6.1.2.3.2. market or technology conditions change
6.1.3. Goal
6.2. Contain
6.2.1. Sprint Planning
6.2.1.1. Time
6.2.1.1.1. 8 hours / one-month Sprint
6.2.1.2. Answers
6.2.1.2.1. What can be delivered in the Increment resulting from the upcoming Sprint?
6.2.1.2.2. How will the work needed to deliver the Increment be achieved?
6.2.1.3. Topic
6.2.1.3.1. What can be done this Sprint?
6.2.1.3.2. How will the chosen work get done?
6.2.2. Daily Scrums
6.2.2.1. Time
6.2.2.1.1. <= 15 minute
6.2.2.1.2. Every day
6.2.2.2. Plan for next 23 hours
6.2.2.3. Where
6.2.2.3.1. Same time
6.2.2.3.2. Same place
6.2.2.4. internal meeting
6.2.2.5. This is a key inspect and adapt meeting
6.2.3. Development work
6.2.4. Sprint Review
6.2.4.1. Type
6.2.4.1.1. informal meeting
6.2.4.1.2. Not status meeting
6.2.4.2. Time
6.2.4.2.1. <= 4 hours / 1 month sprint
6.2.4.3. Include
6.2.4.3.1. Attendees include the Scrum Team and key stakeholders invited by the Product Owner
6.2.4.3.2. The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done"
6.2.4.3.3. The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved
6.2.4.3.4. The Development Team demonstrates the work that it has "Done" and answers questions about the Increment
6.2.4.3.5. The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed)
6.2.4.3.6. The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning
6.2.4.3.7. Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next
6.2.4.3.8. Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
6.2.4.4. Result
6.2.4.4.1. Revised Product Backlog
6.2.5. Sprint Retrospective
6.2.5.1. Time
6.2.5.1.1. After Sprint review And before next sprint plan
6.2.5.1.2. 3 hours / 1 month sprint
6.2.5.2. contents
6.2.5.2.1. Inspect how the last Sprint went with regards to people, relationships, process, and tools
6.2.5.2.2. Identify and order the major items that went well and potential improvements
6.2.5.2.3. Create a plan for implementing improvements to the way the Scrum Team does its work
6.3. During
6.3.1. No changes are made that would endanger the Sprint Goal
6.3.2. Quality goals do not decrease
6.3.3. Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned
7. Scrum Artifacts
7.1. Product Backlog
7.1.1. attributes
7.1.1.1. description
7.1.1.2. order
7.1.1.3. estimate
7.1.1.4. value
7.1.2. refinement
7.1.2.1. adding detail
7.1.2.2. estimates
7.1.2.3. order to items
7.1.2.4. no more than 10% of the capacity of the Development Team