1. Principles
1.1. Empirical Process Control
1.1.1. Transparency
1.1.1.1. Artifacts
1.1.1.1.1. Project Vision Statement
1.1.1.1.2. Prioritized Product Backlog
1.1.1.1.3. Release Planning Schedule
1.1.1.2. Meetings
1.1.1.2.1. Sprint Review Meetings
1.1.1.2.2. Daily Standup Meetings
1.1.1.3. Information Radiators
1.1.1.3.1. Burndown Chart
1.1.1.3.2. Scrumboard
1.1.2. Inspection
1.1.2.1. Scrumboard
1.1.2.2. Frequent Feedback
1.1.2.3. Final inspection
1.1.3. Adaptation
1.1.3.1. Daily Standup Meetings
1.1.3.1.1. Scrum Team members openly discuss impediments to completing their taks
1.1.3.1.2. After the meeting the Scrum Master coordinate help from other team members
1.1.3.1.3. Mentor those with relatively less experience in knowledge of the project or technology
1.1.3.1.4. When the needed resource does not reside within the team, the Scrum Master will acquire it externatlly
1.1.3.2. Constant Risk Identification
1.1.3.2.1. Create Prioritized
1.1.3.2.2. Groom Prioritized Product Backlog
1.1.3.2.3. Create Sprint Backlog
1.1.3.3. Change Requests
1.1.3.3.1. Develop Epic (s)
1.1.3.3.2. Create Prioritized Product Backlog
1.1.3.3.3. Groom Prioritized Product Backlog processes
1.1.3.4. Scrum Guidance Body
1.1.3.4.1. Create User Stories
1.1.3.4.2. Estimate Tasks
1.1.3.4.3. Create Deliverables
1.1.3.4.4. Groom Prioritized Product Backlog processes
1.1.3.4.5. Guidance and also provide expertise as required for the team to adapt do necessary changes and challenges
1.1.3.5. Retrospect Sprint Meetings
1.1.3.6. Retrospect Project Meetings
1.2. Self Organization
1.2.1. Focuses on Today's workers
1.2.2. Self-organize rather than command and control
1.2.3. Goals of a Self-organized Team
1.2.3.1. Understand the Project Vision
1.2.3.2. Leverage on cross functional team expertise
1.2.3.3. Proactively seek work
1.2.3.4. Execute work themselves
1.2.3.5. Open to learning new things
1.2.3.6. Continuously upgrade knowledge and skills
1.2.3.7. Delivery tangible results
1.3. Collaboration
1.3.1. Awareness
1.3.2. Articulation
1.3.3. Appropriation
1.3.4. Advocates project management as a shared value-creation process
1.4. Value based Priorization
1.4.1. Maximum business value
1.5. Time-Boxing
1.5.1. Sprints
1.5.2. Daily Standup Meetings
1.5.3. Sprint Planning Meetings
1.5.4. Sprint Review Meetings
1.6. Iterative Development
1.6.1. Manage changes better
1.6.2. Build projects that satisfy customer needs
2. Processes
2.1. Initiate
2.1.1. 1 - Create Project Vision
2.1.1.1. Project Business is reviewed to create Project Vision Statement
2.1.1.2. Product Owner is Identified
2.1.2. 2 - Identify Scrum Master and Stakeholder
2.1.2.1. Scrum Master is Identified
2.1.3. 3 - Form Scrum Team
2.1.3.1. Scrum Team members are identified
2.1.3.2. Product Owner responsible for selecting team members, often does so in collaboration with the Scrum Master
2.1.4. 4 - Develop Epics
2.1.4.1. Project Vision Statement serves as the basis for developing Epic
2.1.4.2. User Group Meetings may be held to develop Epic(s)
2.1.5. 5 - Create a Prioritized Product Backlog
2.1.5.1. Epic(s) and Unrefined User Stories refined and elaborated and prioritized to create a Prioritized Product Backlog
2.1.5.2. Done Criteria is also established
2.1.6. 6 - Conduct Release Planning
2.1.6.1. Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule
2.2. Project Plan and Estimate
2.2.1. 7 - Create User Stories
2.2.1.1. User Stories and their related User Story Acceptance Criteria are created
2.2.1.2. Usually written by the Product Owner
2.2.1.3. Designed to ensure that the customer's requirement are clearly depicted and understood
2.2.1.4. Involves Scrum Team members creating User Stories
2.2.1.5. Users Stories are incorporated in Prioritized Product Backlog
2.2.2. 8 - Approve, Estimate and Commit User Stories
2.2.2.1. Product Owner approves User Stories for a sprint
2.2.2.2. Scrum Master and Scrum Team estimate the effort required
2.2.2.3. Scrum Team commits to develop the customer requirements in the form of Approved, Estimated, and Committed User Stories
2.2.3. 9 - Create Tasks
2.2.3.1. The approved, Estimated, and User Stories are broken down and compiled into a Task List
2.2.3.2. Task Planning Meeting is held
2.2.4. 10 - Estimate Tasks
2.2.4.1. Scrum Core Team, in a Task Estimation Workshop, estimates effort required to a accomplish each in the Task List
2.2.4.2. Restult of this process is an Effort Estimated Task List
2.2.5. 11 - Create Sprint Backlogs
2.2.5.1. The Scrum Core Team holds Sprint Planning Meetings
2.2.5.2. Sprint Backlog containing all tasks to be completed in the sprint is created
2.3. Implement
2.3.1. 12 - Create Deliverables
2.3.1.1. Scrum Team works on the tasks in the Sprint Backlog to create Sprint Deliverables
2.3.1.2. Scrumboard is often used to track the work and activities being carried out
2.3.1.3. Issues or problems being faced by the Scrum Team could be updated in an Impediment Log
2.3.2. 13 - Conduct Daily Standup
2.3.2.1. Every day a highly focused time-boxed meeting is conducted referred to as the Daily Standup meeting
2.3.2.2. It's a forum for the Scrum Team update each other on their progress and impediments
2.3.3. 14 - Groom Prioritized Product Backlog
2.3.3.1. The Prioritized Product Backlog is continuously updated and maintained
2.3.3.2. Prioritized Product Backlog Review Meeting may be held
2.3.3.3. Any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog
2.4. Review and Retrospect
2.4.1. 15 - Convene Scrum of Scrums
2.4.1.1. Scrum Teams representatives convene for Scrum of Scrum Meetings
2.4.1.2. They collaborate and track their respective progress, impediments and dependencies across teams
2.4.1.3. Relevant only for large projects where multiple Scrum Teams are involved
2.4.2. 16 - Demonstrate and Validate Sprint
2.4.2.1. Scrum Team demonstrates the Sprint Deliverables
2.4.2.2. The purpose of this meeting is to secure approval and acceptance of the product or service by the product owner
2.4.3. 17 - Retrospect Sprint
2.4.3.1. Scrum Master and Scrum Team meet to discuss the lessons learned
2.4.3.2. Discuss negative and positive points observed on the last Sprint
2.4.3.3. Information is recorded as lessons learned which can be applied to future Sprints
2.4.3.4. There may be Agreed Actionable Improvements or Update Scrum Guidance Body Recommendations
2.5. Release
2.5.1. 18 - Ship Deliverables
2.5.1.1. Accepted Deliverables are delivered or transmitted
2.5.1.2. A formal Working Deliverables Agreement documents the successful completion of the Sprint
2.5.2. 19 - Retrospect Project
2.5.2.1. Organizational stakeholders and Scrum Core Team members assemble to retrospect the project
2.5.2.2. Identify, document and internalize the lessons learned
2.5.2.3. Lessons led to documentation of Agreed Actionable Improvements to be implemented in future projects
3. Aspects
3.1. Organization
3.1.1. Core Roles
3.1.1.1. Product Owner
3.1.1.1.1. Responsible for achieving maximum business value for project
3.1.1.1.2. Articulates customer requirements
3.1.1.1.3. Maintains business justification for a project
3.1.1.1.4. Represent customer's voice
3.1.1.2. Scrum Master
3.1.1.2.1. Ensures that Scrum Team has an appropriate environment
3.1.1.2.2. Guides, facilitates and teaches Scrum practices
3.1.1.2.3. Clears impediments for the team
3.1.1.2.4. Ensures that Scrum processes are being followed
3.1.1.3. Scrum Team
3.1.1.3.1. Responsible for understanding Product Owner specified requirements
3.1.1.3.2. Creating the project deliverables
3.1.2. Non Core Roles
3.1.2.1. Stakeholders
3.1.2.1.1. Customers, Users and Sponsors
3.1.2.1.2. Interface with the Scrum Core Team
3.1.2.1.3. Influence the project throughout
3.1.2.1.4. Project produces the collaborative benefits
3.1.2.2. Scrum Guidance Body (SGB)
3.1.2.2.1. Set of Documents or group of experts
3.1.2.2.2. Involved with defining objectives
3.1.2.2.3. Guides the work carried out by the Product Owner, Scrum Master, Scrum Team
3.1.2.3. Vendors
3.1.2.3.1. External Individuals or Internal Organization
3.1.2.3.2. Provice products and services that are not within the core competencies of the project organization
3.1.2.4. Chief Product Owner
3.1.2.4.1. In bigger projects has multiple Scrum Teams
3.1.2.4.2. Responsible for coordinating work of multiple Product Owners
3.1.2.5. Chief Scrum Master
3.1.2.5.1. Coordinates Scrum-related activities in large projects which requires multiple Scrum teams to work in parallel
3.2. Business Justification
3.2.1. Value-driven delivery
3.2.2. Uncertain of results or outcomes
3.2.3. Impossible to guarantee Project's success and completion
3.2.4. Scrum attempts to start delivering results as early in the project as possible
3.2.5. This provides an opportunity for reinvestment
3.2.6. Allows the Project's objectives and processes to change in case of business justification changes
3.3. Quality
3.3.1. Scrum adopts an approach of continuous improvement
3.3.2. The team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog
3.3.3. The Prioritized Product Backlog is simply never complete until the closure or termination of the project
3.3.4. Changes to requirements reflect changes in the internal and external business environment
3.3.5. Requires work to be completd in an incremental fashion through Sprints
3.3.6. Due to this, errors are fixed right away
3.3.7. Quality-related tasks are completed as part of the same Sprint
3.3.8. Ensures that quality is inherent in any deliverable created as part of a Sprint
3.3.9. Continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels
3.3.10. Constant discussions between the Scrum Core Team and stakeholders including customers and users
3.3.11. Ensures that the gap between customers expectations from the project ans actual deliverables produced in constantly reduced
3.4. Change
3.4.1. Stakeholder may change thir mind about what they want during the course of the project
3.4.2. It is not always feasible for stakeholdres to define requirements during project initiation
3.4.3. SCRUM welcomes change by using short iterative sprints
3.4.4. It enables customers to regularly interact with Scrum Team members and view deliverables as they are ready and event o change requirements if needed
3.5. Risk
3.5.1. Positive impact / Opportunities
3.5.2. Negative impact / Threats
3.5.3. Managing risk must be done proactively
3.5.4. It is an iterative process that should begin at project initiation and continue throughout the project's lifecycle
3.5.5. Risk management should follow standardized steps to ensure risks
3.5.5.1. Identified
3.5.5.2. Evaluated
3.5.5.3. Proper course of action is determined upon and acted upon
3.5.6. Risks should be identified, assessed, and responded to, based on two factors. Risk with a high probability and impact value are determined by multiplying both factors. Once a risk is identified, it is important to understand the risk.
3.5.6.1. The possible impact in the event of such occurrence
3.5.6.2. The probability of each risk's occurrence