The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game

Iniziamo. È gratuito!
o registrati con il tuo indirizzo email
The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game da Mind Map: The Scrum Guide - The Definitive Guide to Scrum: The Rules of the Game

1. Purpose

1.1. Contains the definition of scrum

1.2. Each element of the framework serves a specific purpose

2. Scrum Defined

2.1. Scrum requires a Scrum Master to foster an environment where:

2.1.1. 1.) A Product Owner orders the work for a complex problem into a Product Backlog

2.1.2. 2.) The Scrum Team turns a selection of the work into an increment of value during a Sprint.

2.1.3. 3) The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

2.1.4. 4.) Repeat

3. 3 Scrum pillars

3.1. Transparency

3.1.1. The emergent process and work must be visible to those performing the work and those receiving it

3.1.1.1. Transparency enables inspection

3.1.1.2. Inspection without transparency is misleading + wasteful.

3.2. Inspection

3.2.1. Scrum artifacts and the progress toward agreed upon goals must be inspected frequently and diligently to detect potentially undesirable variances or problems

3.2.1.1. Scrum provides cadence in the form of it's 5 events

3.2.1.1.1. Events are designed to provoke change

3.2.1.2. Inspection without adaption is considered pointless.

3.3. Adaptation

3.3.1. If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable

3.3.1.1. The process being applied or the materials being produced must be adjusted.

3.3.1.1.1. Must happen as soon as possible

3.3.1.1.2. Adaption becomes more difficult when the people involved are not empowered or self-managing

4. Scrum has 3 Formal Artifacts

4.1. Product Backlog

4.1.1. Product Goal

4.2. Sprint Backlog

4.2.1. Sprint Goal

4.3. For the increment

4.3.1. It is the Def. of Done.

5. 5 Scrum Values

5.1. Commitment

5.2. Focus

5.3. Openness

5.4. Respect

5.4.1. members respect each other as capable, independent people, and are respected as such by the people with whom they work.

5.5. Courage

5.5.1. Team members have the courage to do the right thing and work on the tough problems.

6. Roles

6.1. Developers

6.1.1. Accountable for

6.1.1.1. Creating a plan for the sprint, and the Sprint backlog

6.1.1.2. Instilling quality by adhering to a Def. of Done

6.1.1.3. Adapting their plan each day toward the Sprint goal; and,

6.1.1.4. Holding each other accountable as professionals

6.2. Product Owner

6.2.1. Is accountable for

6.2.1.1. Maximizing the value of the product resulting from the work of the Scrum Team.

6.2.1.1.1. How this is done will vary widely across orgs, Scrum Teams, and individuals.

6.2.2. Also accountable for effective Product Backlog management which includes

6.2.2.1. Developing and explicitly communicating the Product Goal

6.2.2.2. Creating and clearly communicating Product Backlog items

6.2.2.3. Ordering Product Backlog items

6.2.2.4. Ensuring that the Product Backlog is transparent, visible + understood.

6.2.3. Product owner may do the above work or may delegate the responsibility to others

6.2.3.1. regardless they remain accountable

6.2.4. For product owners to succeed, the entire organization must respect their decisions

6.2.4.1. Decisions are visible in the content and ordering of the Product Backlog

6.2.4.2. Inspectable increment of product during sprint review

6.2.5. The Product Owner is one person, not a committee

6.2.5.1. May represent the needs of many stakeholders in the Product Backlog

6.2.5.1.1. those wanting to change the backlog can do so by trying to convince the Product owner

6.3. Scrum master

6.3.1. Accountable for establishing scrum as defined in the Scrum Guide

6.3.1.1. Help everyone understand scrum theory and practice

6.3.1.1.1. Both within the Scrum Team and the org

6.3.2. Must enable scrum team to improve it's practices, within the Scrum framework

6.3.3. Serves scrum team by:

6.3.3.1. Coaching the team members in self-management and cross-functionality

6.3.3.2. Helping the scrum team focus on creating high-value increments that meet the definition of done

6.3.3.3. Cause the removal of impediments to the Scrum Team's progress

6.3.3.4. Ensuring that all Scrum events take place and are positive, productive, and kept within a timebox

6.3.4. Serves Product owner by

6.3.4.1. Helping find techniques for effective Product Goal definition and Product Backlog management

6.3.4.2. Helping the Scrum Team understand the need for clear and concise product Backlog items

6.3.4.3. Helping establish empirical product planning for a complex environment

6.3.4.4. Facilitating stakeholder collaboration as requested or needed.

6.3.5. Serves organization by

6.3.5.1. Leading, training and coaching the org in its Scrum adoption

6.3.5.2. Planning and advising Scrum implementations within the organization

6.3.5.3. Help employees and stakeholders understand and enact an empircal approach for complex work;

6.3.5.4. Removes barriers between stakeholders and Scrum Teams

7. Scrum events

7.1. The Sprint

7.1.1. heartbeat of scrum, where ideas are turned into value

7.1.2. Fixed length events of one month or less to create consistency.

7.1.3. A new sprint starts immediately after the conclusion of the previous Sprint

7.1.3.1. Sometimes you need to slow down!

7.1.4. During it

7.1.4.1. No changes are made that would endanger the Sprint Goal

7.1.4.2. Quality does not decrease

7.1.4.3. Product Backlog is refined as needed

7.1.4.4. Scope may be clarified and renegotiated with the Product Owner as more is learned

7.1.5. Enable predictability by ensuring inspection and adpation of progress toward a Product Goal at least

7.1.5.1. Once every calendar month

7.1.5.2. Each sprint may be considered a short project

7.1.6. Various practices exist to forecast sprint progress

7.1.6.1. Burn-downs

7.1.6.2. Burn-ups

7.1.6.3. Cumulative flows

7.1.7. Only what has happened can be used for forward-looking decision making

7.1.8. A Sprint can be canceled if the sprint goal becomes obsolete

7.1.8.1. Only product owner has authority to cancel a sprint.

7.2. Sprint planning

7.2.1. Entire scrum team

7.2.2. Product owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.

7.2.3. Scrum team may invite other people to attend Sprint Planning to provide advice

7.2.4. Addresses

7.2.4.1. Topic one: Why is the Sprint Valuable

7.2.4.1.1. Product Owner proposes how the product could increase its value and utility in the current Sprint

7.2.4.1.2. Entire team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

7.2.4.1.3. Sprint Goal MUST be finalized prior to the end of sprint planning meeting.

7.2.4.2. Topic two: What can be done this Sprint?

7.2.4.2.1. Select items from the Product Backlog after discussing with developers and Product owner

7.2.4.2.2. Can be challenging to not overcommit

7.2.4.3. Topic three: How will the chosen work get done?

7.2.4.3.1. For each selected Product Backlog item

7.2.5. TImeboxed to a max of 8 hours for a one-month sprint

7.2.5.1. For shorter sprints the event is usually shorter.

7.3. Daily scrum

7.3.1. Purpose inspect progress toward the Sprint Goal and adapt the SPrint backlog as necessary, adjusting the upcoming planned work.

7.3.1.1. 15-minute event for the developers and scrum team

7.3.1.2. If the Product owner or scrum master are actively working on items in the Sprint Backlog -> They also participate as developers.

7.3.1.3. Devs can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work

7.3.1.3.1. This creates FOCUS and improves self-management

7.3.2. Improve communication, identify blockers, promote quick decision-making and consequently eliminate the need for other meetings

7.3.3. Devs often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint's work.

7.4. Sprint Review

7.4.1. Inspect outcome of the sprint

7.4.2. Determine future adaptations

7.4.3. Team presents the results of their work to key stakeholders and progress toward the Sprint Goal is discussed (demo)

7.4.4. It's a working session Team should avoid limiting it to a presentation

7.4.4.1. Based on info attendees collaborate on what to do next. Product Backlog may also be adjusted to meet new opportunities.

7.4.5. Max of 4 hours for a 1 month sprint -- shorter for shorter sprints

7.5. Sprint Retros

7.5.1. Plan ways to increase quality and effectiveness

7.5.2. Team inspects how the last sprint went with regards to individuals, interactions, processes, tools, and their Def. of Done.

7.5.2.1. Inspected elements often vary with the domain of work

7.5.2.2. Assumptions that led them astray are identified and their origins explored.

7.5.2.3. Scrum team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

7.5.2.4. Team identifies most helpful changes to improve its effectiveness

7.5.2.4.1. The most impactful improvements are addressed as soon as possible.

7.5.2.4.2. They can be added to the sprint backlog for the next sprint.

7.5.3. Timeboxed to a max of 3 hours

8. Increment

8.1. Is a concrete stepping stone toward the Product Goal.

8.1.1. Each increment is additive to all prior increments and thoroughly verified, ensuring all increments work together.