1. SCRUM PILLARS
1.1. TRANSPARENCY
1.1.1. - A common language shared by all participants - A common definition of "Done" must be shared for by those performing and inspecting the work
1.2. INSPECTION
1.2.1. - Scrum users must inspect Scrum Artifacts and progress to identify deviation - The frequency of inspection shouldn't interfere with the work
1.3. ADAPTATION
1.3.1. - Adjustments must be done as soon as possible to minimize further deviation - There are 4 formal events for inspection and adaptation (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective).
2. SCRUM TEAM
2.1. CHARACTERISTICS
2.1.1. - Self-organized: choose how best to accomplish their work - Cross-functional: have all competencies needed to accomplish the work without depending on others. - Designed to optimize flexibility, creativity and productivity
2.2. SCRUM MASTER (SM)
2.2.1. Responsabilities
2.2.1.1. - Responsible for promoting and supporting Scrum (manages the scrum framework) - Servant-leader for the ScrumTeam - Helps everyone in understanding Scrum theory, practices, rules and values. - Helps those outside of the team to understand helpful and bad interactions with the Scrum team. - Helps everyone change interactions with the Scrum team to maximize the value created.
2.2.2. Service to the PO
2.2.2.1. - Finding techniques for effective Product Backlog Management - Ensuring that the PO knows how to arrange the Product Backlog - Understanding and practicing agility - Facilitating Scrum events
2.2.3. Service to the Dev Team
2.2.3.1. - Coaching self-organization and cross-functionality - Removing impediments - Helping to create high-value products - Facilitating Scrum events
2.2.4. Service to the Organization
2.2.4.1. - Leading and coaching Scrum adption - Planning Scrum implementations - Helping employees and stakeholders understand and enact Scrum - Causing change that increases the productivity of the team - Working with other SM to increase the effectiveness of the implementation of Scrum
2.3. DEVELOPMENT TEAM (DEV TEAM)
2.3.1. Consists of
2.3.1.1. - Professionals who do the work of delivering a potentially releasable Increment each sprint - Structured to manage their own work, optimizing the team's overall efficiency and effectiveness *Someone in the Dev Team can also play SM's role
2.3.2. Responsabilities
2.3.2.1. - Only members of the Dev Team create the increment - Responsible for tracking the remaining work of the Sprint
2.3.3. Team Size (3 to 9)
2.3.3.1. - fewer than 3 (decrease interaction, skills constraints, smaller productivity gains) - more than 9 (requires too much coordination, generates complexibility for an empirical process)
2.3.4. Characteristics
2.3.4.1. - self-organizing - cross-functional - no titles for the members - no sub-teams in the Dev team - members may have specialized skills and areas of focus, but accountability belongs to the Dev Team as a whole
2.4. PRODUCT OWNER (PO)
2.4.1. Consists of
2.4.1.1. a sole person not a committee
2.4.2. Responsabilities
2.4.2.1. Management of the Product Backlog: - clearly expressing items - prioritizing items - optimizing the value of the product resulting from work of the Dev Team - ensuring transparency and clear to all, and what the team will do next - ensuring the Dev Team understand items; *The Dev Team can do it, but the PO is accountable for it.
2.4.3. Roles
2.4.3.1. -Ensure that the most valuable functionality is produced first - Interacting with stakeholders
2.4.4. *The entire organization must respect the PO decisions. *Can delegate some activities to someone else *For a single product there should be 1 product Backlog and 1 PO (he can delegate some activities to the team)
3. DEFINITION OF "DONE"
3.1. Who defines it
3.1.1. The Dev Team (if there is no definition) *the Dev Team must conform to the definition
3.2. Function
3.2.1. - Is used to assess when work is complete on the product Increment - It guides the Dev Team in knowing how many items it can select during a Sprint Planning - It ensures artifact transparency. * Members must have a shared understand of what "Done" means. * If there is a definition of "Done" for the organization, all Scrum Teams must follow it * If there is not a definition of "Done" for the organization, Dev Team must define it
3.3. Mature Scrum Teams
3.3.1. Definition of "Done" will expand to include more stringent criteria for higher quality
3.4. Multiple Scrum Teams
3.4.1. Dev Teams on all Scrum Teams must mutually define the definition of "Done"
3.5. When item is considered "done"
3.5.1. - when the item has no work remaining to be released - No work left from the definition of "done" - all work to create an usable software
4. SCRUM ARTIFACTS
4.1. Definition
4.1.1. - Represent work or value to provide transparency and opportunities for inspection and adaptation - Designed to maximize transparency of key information (everybody has the same understanding of it)
4.2. PRODUCT BACKLOG
4.2.1. Definition
4.2.1.1. - An ordered list of all features, requirements, improvements and fixes that constitute changes to the product in future releases. - Is the single source of requirements for any changes to be made to the product - Is never complete, is dynamic, constantly changes to identify what the product needs to be appropriate, useful and competitive. - Items have the attributes of a description, order, estimate, and value. * As a product is used, the Product Backlog becomes a larger list, cause market provides feedback of it
4.2.2. Responsible
4.2.2.1. The PO is responsible for its content, availability, and ordering
4.2.3. Refinement
4.2.3.1. - Is the act of adding detail, estimates and order to items - Is an ongoing process in which PO and Dev Team collaborate on details of the items * Scrum Team decides how and when refinement is done (usually consumes 10% of the capacity of the Dev Team) * Items can be updated at any time by the PO
4.2.4. Level of Details
4.2.4.1. Higher ordered items are usually clearer and more detailed than lower ordered ones.
4.2.5. "Ready" Items
4.2.5.1. Items ready for selection in a Sprint Planning (refined and can be 'done' by the Dev Team within one sprint)
4.2.6. Estimates
4.2.6.1. The Dev Team is responsible for all estimates (PO may influence by helping it understand)
4.2.7. Monitoring Progress
4.2.7.1. - PO tracks the total work remaining to reach a goal at least at every Sprint Review - PO compares it to previous Sprint Reviews to assess progress *Projective practices like Burn-downs are useful. However, this does not replace empiricism (only what has happened can be used for forward-looking decision-making).
4.2.8. * Multiple scrum Teams often work on the same product and the same Product Backlog A Product Backlog attribute that groups items may then be employed
4.3. SPRINT BACKLOG
4.3.1. Definition
4.3.1.1. - Is the set of Product Backlog items selected for the sprint plus a plan for delivering an Increment and meeting the Sprint Goal - Is a forecast by the Dev Team of what functionality will be in the next increment and the work necessary to delivery it - It includes at least one high priority process improvement identified in the previous Retrospective meeting.
4.3.2. Responsible
4.3.2.1. - Only the Dev team can change its Sprint Backlog - Dev team modifies the Sprint Backlog thoughout the Sprint, and the Sprint Backlog emerges during the Sprint - If elements are deemed unnecessary are removed from the plan The Dev Team in agreement with the PO define the Sprint Backlog Scope
4.3.3. Monitoring Sprint Progress
4.3.3.1. - Dev Team tracks the work remaining in every Daily Scrum and can manage its progress - Used in Daily Scrum as a reference to understand changes in progress
4.4. INCREMENT
4.4.1. Definition
4.4.1.1. - Sum of all product backlog items completed in the Sprint and the value of the increments of all previous sprints - The increment is an step toward a goal.
4.4.2. How to increase transparency
4.4.2.1. - Doing all work needed to meet the definition of "Done" - Updating Sprint tasks properly in the tracking tool
4.4.3. * It must be in useable condition regardless of whether the PO decides to release it * It must meet the definition of "Done"
5. Scrum doesn't recommend tools or estimation methods Implementing only parts of Scrum is possible, but the result is not Scrum Essence of Scrum: a small team of people highly flexible and adaptive Scrum allow additional meetings not defined in Scrum
5.1. Promotes selforganization by
5.1.1. - being a lightweight framework - removing titles for Dev Team members - Dev Team deciding what work to do in a Sprint
6. SCALING SCRUM - NEXUS
6.1. For multiple teams working on the same project, the sprint start date doesn't have to be the same
6.2. Adding new Scrum team to a project
6.2.1. Productivity of the original team will decrease cause members will have to learn how to work on the same backlog and PO
7. SCRUM ARTIFACT TRANSPARENCY
7.1. SM ROLE
7.1.1. - Must work with others to understand if the artifacts are transparent - Must help everyone apply practices in the absence of complete transparency - Can detect incomplete transparency by inspecting artifacts, sensing patterns, differences between what is expected and real results - Should work with the Scrum them and the organization to increase transparency of the arctifacts
8. SCRUM VALUES
8.1. COMMITMENT
8.1.1. to achieving the goals of the team
8.2. COURAGE
8.2.1. to do the right thing and work on complex problems
8.3. FOCUS
8.3.1. on the work of the sprint and the goals of the team
8.4. OPENNESS
8.4.1. about the work and challenges
8.5. RESPECT
8.5.1. each other to be capable, independent people.
9. SCRUM EVENTS
9.1. - Is a specific amount of days for a team to work at a sustaibnable pace to finish selected work - Used to create regularity and to minimize the need for meetings not defined in Scrum - Time-boxed (maximum duration, cannot be shortned or lengthened) - End whenever the purpose of the event is achieved - Is a formal opportunity to inspect and adapt something
9.2. SPRINT
9.2.1. Purpose
9.2.1.1. to create a "done", useable and potentially releasable product increment
9.2.2. time-box
9.2.2.1. 1 month or less (if the horizon is too long, the definition of "done" may change, complexity and risk may increase). *Is better to have sprints of consistency length
9.2.2.2. Time-boxing promotes self-organization by: - helping everyone to focus on the same problem at the same time - encouraging people to creat the best result in the given time
9.2.3. Consists of
9.2.3.1. the Sprint Planning, Daily Scrum, the development work, Sprint Review and the Sprint Retrospective.
9.2.4. Frequency
9.2.4.1. Starts right after the previous sprint
9.2.5. During a Sprint
9.2.5.1. - Changes that affect the sprint goal are not made; - Quality goals do not diminish; - Scope may be cleared up and negotiated between the PO and Dev Team.
9.2.6. Sprints enable
9.2.6.1. - Predictability by ensuring inspection and adaptation of progress toward a sprint goal every 1 month - Limit risk to 1 month of cost;
9.2.7. Cancelling a Sprint
9.2.7.1. Authority
9.2.7.1.1. only the PO can cancel it (sometimes under influence from others)
9.2.7.2. Motives
9.2.7.2.1. - If the sprint goal becomes obsolete (company changes direction or market / technology conditions change) - If no longer makes sense to keep it
9.2.7.3. What happens
9.2.7.3.1. Completed and Done Items
9.2.7.3.2. Incomplete Items
9.2.7.4. Consumes resources and is often traumatic and very uncommon
9.2.8. Defining Sprint Length
9.2.8.1. - Level of uncertainty over the technology that is going to be used - Risk of being disconnected from the expectations of stakeholders - The ability to go to market with a product release
9.3. SPRINT PLANNING
9.3.1. Purpose
9.3.1.1. Plan the work to be performed in the Sprint
9.3.2. Attendees
9.3.2.1. entire Scrum Team *People outside scrum are also allowed
9.3.3. Time-box
9.3.3.1. 8h for one-month sprints
9.3.4. What?
9.3.4.1. What can be delivered in the Increment of the Sprint? - PO discusses the objective of the sprint and items that, if completed, would achieve the sprint goal. - Dev Team forecasts the functionality that will be developed - Entire Scrum Team collaborates on understanding the work of the Sprint - Dev Team (only) defines number of items selected from the product Backlog
9.3.5. How?
9.3.5.1. How will the work needed be achieved? - Dev Team decides how it will build the functionality into a 'done' product increment; - Dev Team usually starts by designing the system and the work needed to convert the backlog into an Increment; - Work planned for the first days of the sprint is decomposed by the end of this meeting to units of one day or less; - PO can help to clarify selected items and and make trade-offs. *Dev Team can invite other people to attend to provide technical or domain advice.
9.3.6. Inputs
9.3.6.1. Product backlog, latest product increment, projected capacity of the Dev Team, past performance of the Dev Team.
9.3.7. Outputs
9.3.7.1. Sprint Goal
9.3.7.1.1. objective set for the sprint that can be met through the implementation of the product backlog - provides guidance to the Dev Team and gives some flexibility - causes the Dev Team to work together rather than on separated initiatives *The Scrum Team defines the Sprint Goal
9.3.7.2. Sprint Backlog
9.3.7.2.1. product backlog items selected + plan for delivering them *if necessary, PO and Dev Team collaborates to re-negotiate the scope of the sprint backlog within the sprint.
9.3.8. SM Roles
9.3.8.1. -ensures that the event takes place -attendees understand its purpose -teaches to keep the event whithin the time-box
9.4. DAILY SCRUM
9.4.1. Purpose
9.4.1.1. - Plan the work for the next 24 h - Inspect progress toward the sprint goal - inspect how progress is trending toward completing the work in the sprint backlog
9.4.2. Attendees
9.4.2.1. Dev Team (defines the structure of the meeting and is responsible for conducting it)
9.4.3. Time-box
9.4.3.1. 15 min
9.4.4. Frequency
9.4.4.1. every day of the Sprint (at the same time and place to reduce complexity)
9.4.5. Benefits
9.4.5.1. - Optimize the probability of meeting the Sprint goal - Improve communications, eliminate other meetings, identify impediments, promote quick decision making; - Optimize team collaboration and performance by inspecting the work - Key inspect and adapt meeting.
9.4.6. Exemple of Question based meeting
9.4.6.1. - What did I do yesterday that helped the Dev team meet the sprint goal? - What will I do today to help the Dev team meet the sprint goal? - Do I see any impediment that prevents me or the Dev team from meeting the sprint goal?
9.4.7. Role of the SM
9.4.7.1. - Ensures that the meeting happens; - Teaches the Dev team to keep the meeting within the time-box - Ensure that others do not disrupt the meeting
9.4.8. Outcome
9.4.8.1. - a shared understanding of the most important work to be performed next to achieve the sprint goal - new impediments for the SM remove
9.5. SPRINT REVIEW
9.5.1. Purpose
9.5.1.1. - Inspect the increment and adapt the Product Backlog if necessary - Attendees collaborate on what was done and the next things that could be done to optimize value - To demonstrate the Product Backlog items completely "done" and to receive feedback from the PO *Informal meeting, not a status meeting
9.5.2. Attendees
9.5.2.1. Scrum Team and Stakeholders invited by the PO *People outside scrum are also allowed
9.5.3. Frequency
9.5.3.1. at the end of the Sprint
9.5.4. Time-box
9.5.4.1. 4h for one-month sprint
9.5.5. Elements
9.5.5.1. - PO explains what items have been 'done' and not been 'done'; - Dev Team discusses what went well and problems it ran through; - Dev Team demonstrates the work 'done' and answers questions about the increment; - PO discusses the current Product Backlog and projects targets and delivery dates; - Attendees collaborate on what to do next (valuable input to the next Sprint Planning); - Review changes in marketplace and potential use of the product; - Review timeline, budget, capabilities and marketplace for the next releases of functionalities.
9.5.6. Results (Outputs)
9.5.6.1. - Revised Product Backlog with probable items for the next Sprint - Adjusted Product Backlog to meet new opportunities
9.5.7. Role of the SM
9.5.7.1. - Ensures that the event takes place - Attendees understand its purpose - Teaches to keep the event whithin the time-box
9.6. SPRINT RETROSPECTIVE
9.6.1. Purpose
9.6.1.1. opportunity for the Scrum team to inspect itself and create a plan for improvements during the next sprint. - Inspect the last sprint considering people, relationships, process and tools; - Identify and order major items that went well and potential improvements; - Create a plan for implementing improvements in the Scrum team;
9.6.2. Attendees
9.6.2.1. SM, Dev Team, PO
9.6.3. Time-box
9.6.3.1. 3h for one month sprints
9.6.4. Frequency
9.6.4.1. after the Review Sprint and prior to the next Sprint Planning
9.6.5. Results (Outputs)
9.6.5.1. - Plan to increase product quality (by improving work processes or adapting the definition of "Done") - Improvements identified to be implemented in the next Sprint * Improvements may be implemented at any time, the Retrospective is a formal opportunity to focus on inspection and adaptation.
9.6.6. Role of the SM
9.6.6.1. - Participates as a peer team member (accountability over the Scrum process) - Ensures the meeting is positive and productive - Encourages the Scrum Team to improve its development process and practices - Teaches all to keep it within the time-box
10. DEFINITION OF SCRUM
10.1. Is a process framework within which people can address complex and adaptive problems - Lightweight, Simple to understand, Difficult to master - Is not a process, technique or definitive method - Provide effective in interative and incremental knowledge transfer - The essence of Scrum is a small team of people highly flexible and adaptive
11. TOOLS
11.1. SPRINT BURNDOWN CHART
11.1.1. The horizontal axis (sprints); the vertical axis (amount of work remaining at the start of each sprint).
11.1.2. Burndown charts track rok remaining across time