Changes between 2017 and 2020 Scrum Guides

  1. Even Less Prescriptive

    Over the years, the Scrum Guide started getting a bit more prescriptive. The 2020 version aimed to bring Scrum back to being a minimally sufficient framework by removing or softening prescriptive language. e.g. removed Daily Scrum questions, soften language around PBI attributes, soften language around retro items in Sprint Backlog, shortened Sprint cancellation section, and more.

  2. One Team, Focused on One Product

    The goal was to eliminate the concept of a separate team within a team that has led to “proxy” or "us and them” behavior between the PO and Dev Team. There is now just one Scrum Team focused on the same objective, with three different sets of accountabilities: PO, SM, and Developers.

  3. Introduction of Product Goal

    The 2020 Scrum Guide introduces the concept of a Product Goal to provide focus for the Scrum Team toward a larger valuable objective. Each Sprint should bring the product closer to the overall Product Goal.

  4. A Home for Sprint Goal, Definition of Done, and Product Goal

    Previous Scrum Guides described Sprint Goal and Definition of Done without really giving them an identity. They were not quite artifacts but were somewhat attached to artifacts. With the addition of Product Goal, the 2020 version provides more clarity around this. Each of the three artifacts now contain ‘commitments’ to them. For the Product Backlog it is the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done (now without the quotes) . They exist to bring transparency and focus toward the progress of each artifact.

  5. Self-Managing over Self-Organizing

    Previous Scrum Guides referred to Development Teams as self-organizing, choosing who and how to do work. With more of a focus on the Scrum Team, the 2020 version emphasizes a self-managing Scrum Team, choosing who, how, and what to work on.

  6. Three Sprint Planning Topics

    In addition to the Sprint Planning topics of “What” and “How”, the 2020 Scrum Guide places emphasis on a third topic, “Why”, referring to the Sprint Goal.

  7. Overall Simplification of Language for a Wider Audience

    The 2020 Scrum Guide has placed an emphasis on eliminating redundant and complex statements as well as removing any remaining inference to IT work (e.g. testing, system, design, requirement, etc). The Scrum Guide is now less than 13 pages.

Changes between 2016 and 2017 Scrum Guides

  1. Added section on the Uses of Scrum:

    Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:

    1. Research and identify viable markets, technologies, and product capabilities;
    2. Develop products and enhancements;
    3. Release products and enhancements, as frequently as many times per day;
    4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
    5. Sustain and renew products.

    Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.

    As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily. Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now widely used for products, services, and the management of the parent organization. The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.

    When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work, such as those types identified above.

  2. Changed wording in The Scrum Master section to provide better clarity to the role. The text now reads:

    The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

    The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

  3. Added to the section Scrum Master Service to the Product Owner

    Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.

  4. Updated the first paragraph of the Daily Scrum section to read:

    The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

  5. Updated the Daily Scrum section to provide clarity on the goals of the Daily Scrum including this text:

    The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:

    • What did I do yesterday that helped the Development Team meet the Sprint Goal?
    • What will I do today to help the Development Team meet the Sprint Goal?
    • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
  6. Added clarity around time-boxes

    Using the words “at most” to remove any questions that the time-box for Events means maximum length, but could be shorter.

  7. Added to the Sprint Backlog section:

    To ensure continuous improvement, it includes at least one high priority way in which the team works, identified in the previous Retrospective meeting.

  8. Added clarity to the Increment section:

    An increment is a body of inspectable, "Done"" work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal.

Changes between 2013 and 2016 Scrum Guides

  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.

Changes between 2011 and 2013 Scrum Guides

  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.

Changes between 2010 and 2011 Scrum Guides

  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.