There are no major changes to the Scrum Events in the 2020 Scrum Guide with the standard lineup continuing to hold: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. A set of changes related to the Scrum Events concerns the pairing of Commitments to the basic Scrum Artifacts, a topic I will cover in the next installment in this series.
Scrum Events Overview
The section introducing the Scrum Events is noticeably shorter than in the 2017 Scrum Guide. The new introductory section states that the Scrum Events exist to provide a formal opportunity to inspect and adapt Scrum Artifacts and to provide the transparency needed to be able to do so. Scrum Events should occur at the same time and place in each instance to reduce complexity.
This is a nice simplification of the purpose of the Scrum Events, emphasizing the action of Empirical Process Control and the importance of establishing a regular, repeating cadence, which improves the effectiveness and efficiency of the humans actually doing the work.
The only other change of note is that the Sprint now includes refining the Product Backlog explicitly, whereas previously this activity was implied as occurring during each Sprint.
This is the Event that has seen the most significant changes in the 2020 Scrum Guide. The essence of Sprint Planning is unchanged, but now there are three topics to cover – why, what, and how, instead of just two – what and how. Furthermore, the Product Owner is now responsible for making sure the Scrum Team is prepared to discuss the most important Product Backlog items and how they contribute to realization of the Product Goal (more on this next time when I cover Scrum Artifacts). This is a good addition that puts the onus on the Product Owner to understand how the pieces fit together before Sprint Planning begins.
Topic One: Why is this Sprint valuable? This is the new element of Sprint Planning. Basically, the Product Owner describes how this Sprint will add to the value of the product and then the entire Scrum Team collaborates to formulate a Sprint Goal that clearly communicates the why the Sprint is valuable to stakeholders. This change makes great sense as it alleviates the issue of the Product Owner not really having a clear understanding of the purpose of the current Sprint. It’s not just about piling on more stuff or keeping people busy; the purpose of every Sprint is to add value to the product.
The other two topics covered in Sprint Planning, what work to pull in off the Product Backlog and how to accomplish those items, are largely unchanged, though the explanations have been simplified and all references to software development practices have been removed. Again, good changes in my opinion.
The new description of the Daily Scrum spells out its purpose very nicely: it is a formal opportunity for the Developers to inspect progress toward the Sprint Goal and adjust the Sprint Backlog as needed to make the best possible progress each day.
The major change of note here is the removal of the “three questions” from the official practice of the Daily Scrum. In place of the three questions, this statement describes the activity of the Daily Scrum (page 9):
The Developers 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. This creates focus and improves self-management.
Notice that the “next day of work” can be today if the Daily Scrum occurs in the morning, which is clearly a very strong and effective practice.
The major change here is a dramatic simplification of the description and working of the Event. Essentially, the Sprint Review is now described as a working session during which the Scrum Team and stakeholders collaborate on what to do next to move the product forward. This is not just a presentation of work completed during the Sprint, though it does still contain that element. It is more about what was accomplished, what has changed, and what the next steps could be. Pretty straightforward.
Once again, the description of this closing Event of the Sprint has undergone a significant simplification with a clear, concise statement of purpose: “to plan ways to increase quality and effectiveness” (page 10). Items to be inspected include “individuals, interactions, processes, tools, and their Definition of Done,” assumptions that did not work out and the origins of those faulty assumptions, and the standard what went well, challenges encountered, and how those challenges were or were not addressed successfully.
The most impactful improvements rise to the top of the stack and “may” be added to the next Sprint Backlog. In the 2017 Scrum Guide the highest priority improvement item had to be added to the next Sprint Backlog. This is a small change that may or may not impact how teams practice Scrum. Strong Scrum Teams always put significant effort into improvement items resulting from their Sprint Retrospective.
That’s it for this installment. Next up: Scrum Artifacts. Until then, stay safe, stay sane, and keep a good thought.