On November 7th 2017, Jeff Sutherland and Ken Schwaber released the latest version of the Scrum Guide. The Scrum Guide reflects the definition of Scrum. Although Scrum has been introduced to the public in 1995, the first version of Scrum Guide was written in 2010. Since that first release there have been 4 revisions.
This latest release is all about addressing common Scrum misunderstandings. In this blog post, I will present the top 5 misconceptions that are set straight in this latest release of the Scrum Guide.
Misconception number 1: Scrum is IT only
Although the Scrum Guide didn’t contain any words like IT or software, a misconception often heard is that Scrum is meant for IT only. Ironically, the latest version of the Scrum Guide now does contain the word “software”, but only to point out that Scrum is not limited to software development alone. The new chapter “Uses of Scrum” states that Scrum is widely used for products, services, and the management of the parent organization. Scrum is a framework in which complex problems can be addressed, and yes, software development tends to be complex too.
To further avoid this misunderstanding, it has been made explicit that the words “develop” and “development” refer to complex work in general. So members of the Development Team are people who do complex work.
Misconception number 2: At the end of the Sprint, a product increment is delivered and released
Deliveries can be made by the Development Team throughout the Sprint at any time and frequency, as long as there is at least one potentially releasable product increment delivered each Sprint. And as described in the paragraph “Sprint”, releases can be done at any time and frequency as well. Scrum does not even require that there is a release each Sprint. Only the Product Owner decides when to release, and this can be multiple times during a Sprint.
Misconception number 3: During Daily Scrum you must answer “the 3 questions”
The 3 questions mentioned in the Scrum Guide are:
- 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?
It has now been made clear that there are different possible ways of conducting the Daily Scrum, as long as the Development Team focusses on their progress towards the Sprint Goal. This is done by inspecting the work and results since the last Daily Scrum, and adapting their work for the upcoming 24 hours to optimize collaboration and performance. “The 3 questions” format is just an example and not a prescription.
Misconception number 4: Sprint Review takes four hours for a one-month Sprint
Where previously was stated:
“This is a four-hour time-boxed meeting for one-month Sprints.”
It now states:
“This is at most a four-hour time-boxed meeting for one-month Sprints.”
This emphasizes that you can agree to set a smaller time box. This applies as well to the Sprint Retrospective. And if you are done before the time box expires, you finish earlier.
Misconception number 5: The Scrum Master is just a team coach
The role of the Scrum Master is often misunderstood. Luckily, the latest Scrum Guide describes more clearly what the Scrum Master is responsible for:
“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.”
A Scrum Team operates in an organizational context. This context influences how effective the Scrum Team can be. Coaching the rest of the organization and optimizing the environment around the Scrum Team is crucial in order to be successful with Scrum. The Scrum Master can be seen as a change agent for agility and Scrum in the whole organization, who removes impediments along the way.
To further clarify how the Scrum Master serves the Product Owner, the following has been added: “Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.”
This doesn’t mean the Scrum Master is taking care of this on behalf of the Product Owner, but implies that the Scrum Master helps the Product Owner understand the importance of doing this, and coaches the Product Owner in making this happen.