Scrum.org published an updated Scrum Guide in November of 2017 and here is a summary of the changes to the guide.
The use of Scrum
The latest Scrum Guide recognises that Scrum is not just for software development, but may be used in various contexts. These contexts highlight the flexibility of Scrum and how an empirical process, values and focus on learning can help solve almost any complex problem. By adding this section Jeff and Ken provide a way for Scrum Masters not in software delivery to justify the use of Scrum. It helps resolve the age-old question ‘Scrum is only designed for software development’.
Revising the role of the Scrum Master
The Scrum Master role is a key catalyst in driving change within any organisation by serving the team in their application of Scrum. The revised Scrum Guide expands clarity of the role by adding ideas around what they do and how they do it.
The Daily Scrum
Probably one of the top 2 most important ceremonies in Scrum but often this daily event becomes a status update instead of focusing on calibrating the plan. By changing the emphasis from the oh so old fashioned 3 questions and describing other ways the daily Scrum/ Standup can be run, re-enforces the idea of relentless pursuit of improvement rather than status.
Time Box is a maximum length
Although a very simple idea it still got lost in translation. It refers to the maximum time allowed and not a recommended time allowed. Many teams used this to ensure we are trapped in a meeting for the maximum time. This leads to unnecessary behavior, for example where everyone sits around for the 15 minutes for the daily Standup, or insists that a Sprint Planing takes 4 hours. The idea of a time box in Scrum is to focus the team, reduce amount of work being worked on and keep the cadence of execution.
Scrum is a framework that helps teams deliver work in a complex environment. That means the team should always be looking for better ways to work through the inspect and adapt method, to learn and to oil the machine for optimal performance. By adding the idea that the Sprint Backlog includes one high priority improvement the Scrum Guide reminds teams that improvement is NOT optional and that every team should have at least one thing they are trying to improve at any point in time. This concept is so important that we have seen it incorporated in SAFe© 4.5 as well.
Many of these are common sense, but I suppose it needs to be documented for common understanding and for body of knowledge purposes.