Scrum Guide 2011

Get Started. It's Free
or sign up with your email address
Scrum Guide 2011 by Mind Map: Scrum Guide 2011

1. references


2. David Starr

2.1. Chief Craftsman

3. Scrum Alliance vs.


4. changes

4.1. Removed

4.1.1. Release Planning Release Planning is a valuable thing to do when using Scrum, but isn’t required by Scrum itself.

4.1.2. Burndown Charts Scrum does not mandate a burndown chart to monitor progress. Scrum requires only that: • Remaining work for a Sprint is summed and known on a daily basis. • Trending toward completing the work of the Sprint is maintained throughout the Sprint. Dev Team must project the likelihood of achieving the Sprint Goal from time to time

4.1.3. Release Burndowns Amount of work remaining towards a "goal" must be summable at any time

4.1.4. Pigs and Chickens

4.2. Refined

4.2.1. Product Owner can delegate PO duties But PO still held accountable for ensuring backlog management is done well

4.2.2. Team -> 
 Development Team The team of people performing the work of creating an Increment is the Development Team. Regardless of the work performed by individual team members, they are known as Developers.

4.2.3. 6±3

4.2.4. Ordered Prioritized The Product Backlog is “ordered,” instead of “prioritized,” providing flexibility to the Product Owner to optimize value in his or her unique circumstances. Order affected by

4.2.5. Sprint Backlog The Sprint Backlog is the Product Backlog items selected for the Sprint, plus a plan for delivering them. There is no longer a required concept of “Sprint Backlog items” although that technique can make a great plan. A self-­‐organizing Development Team always has a plan.

4.2.6. Commitment Forecast Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.

4.2.7. Incremental Sprint Planning is now in the guide as optional In Sprint Planning Meeting, decide scope (which backlog items will be attempted) detailed plan for first few days of Sprint After Daily Scrums Dev Team meets to re-plan rest of sprint as needed

4.3. Added

4.3.1. Backlog Grooming is now required Everyone attends the backlog grooming meeting: the team, the Product Owner, and the ScrumMaster. During the maintenance meeting, everyone helps prepare the scrum backlog for the sprint planning meeting. This usually includes adding new stories and epics, extracting stories from existing epics, and estimating effort for existing stories. Why is this helpful? Because a groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours. When product backlog items contain clearly defined acceptance criteria and are estimated by the appropriate team members, the planning process does not have to be tense or overly long. By dedicating a time to backlog maintenance, the team ensures that this preliminary planning always occurs prior to the sprint planning meeting.

4.3.2. Retrospectives: Plan to implement changes is now required

5. Scrum is Open for Modification

6. Scrum is Open for Extension

6.1. Integration Scrum

6.2. Scrum Basic

6.3. ATDD Sprint Plan

6.4. Product Backlog Grooming

6.5. Estimating

6.6. Scrum of Scrums

6.7. Continuous Delivery

6.8. Feature Scrum

7. scrum guide

7.1. Philosophy

7.1.1. New Title of the guide: "The Scrum Guide - The Definitive Guide to Scrum : The Rules of the Game" chess comparison Scrum is defined in the Scrum Guide Scrum is all or nothing -- partial implementations mean that Scrum is not being done correctly Much more emphasis in the guide's prose on Scrum being rules oriented

7.1.2. More emphasis on Scrum Master servant leadership

7.1.3. All references to software have been removed References to software have been replaced with "product" and "increment"