Scrum Guide update

Scrum Guide update

Last week, on November 18th, Scrum celebrated its 25th birthday with a Scrum Guide update.

These are the most important differences compared to the previous version:

  • Less prescriptive
  • Scrum for All – Application beyond software
  • The Scrum Guide still defines the rules of the game
  • More concise and interwoven
  • Leaner guide – Now only 13 pages (instead of 19)


In this post, I want to share some of the highlights in this new guide.

  • First of all, the core – the Scrum values and pillars – have not changed. A testament to their proven effectiveness. After being inspected, tried and tested by the entire Scrum community, these remain in the “working well, keep doing” column.
  • The guide has become much leaner. It is now a shorter guide containing a better description of the rules of the framework. There is also less room for misinterpretation.
  • The term Product Goal was introduced. Compared to the Sprint Goal, which is the commitment towards the Sprint Backlog, the Product Goal is the commitment towards the Product Backlog, spanning over multiple sprints and developed by the Product Owner.
  • Recommended squad size has changed its description from “3 to 9” developers to “typically less than 10”. However, the main advice is: Small enough to remain nimble and large enough to complete significant work within a Sprint.
  • The term Developer is defined as someone who is committed to creating any aspect of a usable increment each Sprint. If you contribute towards the sprint goal, consider yourself a developer.
  • The Sprint Planning now explicitly requires answering the question “Why are we doing this Sprint?”. This was already done implicitly by teams that created a Sprint Goal stating why that Sprint was valuable to stakeholders. The “What” and “How” remain part of the Sprint Planning as well.
  • Emphasis has been added to the fact that the Review meeting is a working session where we inspect the outcome of the Sprint and determine future actions. We should avoid limiting it to a presentation.
  • It has been made clearer that, as soon as a Product Backlog item meets the definition of Done, an increment is born, which could potentially be released. You do not need to wait until the Sprint is over to be able to release the increment.

I highly recommend reading the full guide. It’s only 13 pages and the last page is not that important. Also, reflect on how this guide can work for you.

Commitment, Focus, Openness, Respect and Courage.

Feel free to share your thoughts in a reply to this blog post.

Scrum on!

Leave a Reply