A new Scrum Guide was released in November 2020. What are the changes and how does it impact us?
Firstly what is the purpose of the Scrum Guide?
The Scrum Guide is a document that contains the definition of the Scrum framework. It defines the Scrum roles, events artifacts and rules to bind them together. The first Scrum Guide was created by Ken Schwaber and Jeff Sutherland in 2010. The guide was updated several times over the years to improve Scrum, with the latest version in 2020.
What are the changes from the 2017 to 2020 Scrum Guide, which is now 5 pages shorter?
Less prescriptive
Over the years the Scrum Guide started getting more prescriptive. The new version brings it back to being a basic non-prescriptive framework. It is therefore a less software-specific guide. All prescriptive language has therefore been removed.
Some examples below:
- Removing the 3 Daily Scrum questions. This allows the team to decide how they want to check in every day.
- Soften language around the Product Backlog Items (PBI’s) and Sprint Backlog items
- Less prescriptive around cancelling a Sprint. In the new version, a Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner (PO) has the authority to cancel the Sprint.
The roles – all for one
Before, the concept existed that a separate team (Development Team) existed within the team (the Scrum Team). The guide has been changed to clearly state that it is one team that focused on one product. The Development Team is now called Developers.
The Scrum team now has the same objectives, with the three different sets of accountabilities: Product Owner, Scrum Master (SM) and Developers.
Product goal as a new concept
The product goal has been introduced as a new concept. This is to provide focus to the Scrum team to a bigger valuable objective, the Product Goal. Each Sprint should bring the product closer to the overall Product Goal.
Adding a Sprint Planning topic
Before the What and How had to be answered in the Sprint planning. In this new version, the topic was added to answer the Why. This topic refers to the Sprint Goal.
Self-managing over Self-organising teams
Previously the Scrum team could choose who and how to get work done. There is now more focus on emphasising a self-managing team who choose the who, how and what they work on.
The Scrum team (PO, SM and Developers) all have a say, all decide the why and all decide the way forward.
A home for the Sprint Goal, Definition of Done (DoD) and Product Goal
Before the Sprint Goal and DoD had no clear identity. They were not definite artifacts but somehow attached to it.
With the added Product Goal, there is a home for the Sprint Goal, DoD and the Product Goal. They are all now the commitments of the three artifacts.
The commitments as follows:
- The Product Backlog has a Product Goal
- The Sprint Backlog has a Sprint Goal
- The Increment has a DoD
These exist to bring transparency and focus to the artifacts.
Improvements allowed on Sprint Backlog
In the Retrospective the ScrumTeam identifies the most helpful change to improve. This improvement is allowed to be added to the Sprint Backlog for the next Sprint.
What hasn’t changed is Scrum is still Scrum. It is still a lightweight framework to solve complex problems and deliver value. While it might be tempting to engage in deep debates about the words and phrasing in the new Scrum Guide, it’s good to remind ourselves of the purpose of the Scrum framework. It’s a framework that is purposefully incomplete. It’s only defining the parts required to implement the Scrum theory. These parts work well in highly unpredictable environments and solutions, where they work in small incremental steps toward a clear goal. With each increment to check if the direction is still correct and all still working smoothly. Also keep in mind that Scrum is built upon the collective intelligence of the people using it, rather than providing people with detailed instructions. With all that said, I think the new Scrum Guide brings that home even better than earlier iterations.
