1. A section on Scrum Values. When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

    Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

  1. A section on Artifact Transparency has been added. Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.
  2. Sprint Planning is now one event. Two topics are addressed in it: What can be done this Sprint, and How will the chosen work be done. After the Development Team forecasts the Product Backlog items for the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal creates coherence in the Development Team’s work that would not be present in separate initiatives without a common goal. Note the formal inclusion of a Sprint Goal.
  3. The Product Backlog is refined rather than groomed. The refined Product Backlog items are transparent, well enough understood and granular enough to be input for the Sprint Planning and for selection for the Sprint. Product Backlog items with this transparency are called “Ready.” Ready and Done are two states that reinforce transparency.
  4. Scrum prescribes its events to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. A Sprint, as container event, has a fixed duration that cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved; ensuring an appropriate amount of time is spent without allowing waste in the process.
  5. The importance of the Daily Scrum as a planning event is reinforced. Too often it is seen as a status event. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. The input to the meeting should be how the team is doing toward meeting the Sprint Goal; the output should be a new or revised plan that optimizes the team’s efforts in meeting the Sprint Goal. To that end, the three questions have been reformulated to emphasize the team over the individual:
    1. What did I do yesterday that helped the Development Team meet the Sprint
    2. What will I do today to help the Development Team meet the Sprint Goal?
    3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
  6. The concept of value is reinforced to use in the Sprint Review. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
  1. 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.
  2. Scrum does not mandate a burn-down 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.
  3. Release Planning is a valuable thing to do when using Scrum, but isn’t required by Scrum itself.
  4. 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.
  5. The Product Backlog is "ordered," instead of "prioritized," providing flexibility to the Product Owner to optimize value in his or her unique circumstances.
  6. Added the practice of Product Backlog Grooming.
  7. Removal of many tips, optional practices and techniques.
  8. 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.
  9. Removed the reference to chickens and pigs.
  10. Removed reference to undone work.