Scrum Commitments: Tying Up Loose Ends and Shoehorning the Definition of Done

TL; DR: Scrum Commitments

While the new Scrum Guide is less prescriptive and more inclusive, it also ties up loose ends by including elements better, namely the previously free-floating Sprint Goal and the Definition of Done with the creation of Scrum commitments. This inclusion works remarkably well in the former’s case; regarding the latter, we need a shoehorn, though.

The Scrum Guide 2020

Foremost, the new Scrum Guide is less prescriptive, eliminating many suggestions such as the Daily Scrum questions, the need for at least one mandatory action item from the Retrospective becoming a part of the Sprint Backlog, or the advice on why Sprint cancelations are rare events.

Four Unbalanced Accountabilities That Can Hurt Your Scrum Team

Find balance in your Scrum Team.


Scrum requires a self-organized team to deliver "done" increments at the end of each Sprint. This peculiarity sometimes raises criticisms and questions when it is discussed in training or when coaching the clients: how can teamwork without a leader? How are we going to do our job, if no one tells us what or how to do it?

Scrum Guide Decomposition, Part 4

This is the fourth and final part of the Scrum Deconstruction.  You can find part 1 here, part 2 here and part 3 here. As mentioned previously, I did this as a method to help me understand the Scrum Guide better, and as part of my study for the Scrum.org's PSM I exam that I took back in October 2017. I have made updates based on the newest version of the Scrum Guide, November 2017.

Here I share in the hope that someone finds it useful.

Scrum Guide Decomposition, Part 2

This is the second part of the Scrum Deconstruction.  You can find part 1 here. As mentioned previously, I did this as a method to help me understand the Scrum Guide better, and as part of my study for the Scrum.org’s PSM I exam that I took back in October last year. I have made updates based on the newest version of the Scrum Guide, November 2017.

Here I share in the hope that someone finds it useful.

Interpretations of the Scrum Guide

"I see a lot of nuances in how people interpret Scrum."

Today I’m going to talk about my interpretation of Scrum and the roles, events, artifacts, and rules that sit within it. I have worked with many different Scrum Teams from all kinds of different companies, so my interpretation is based on credible, practical experience.

A lot of people see the Scrum Master as a servant-leader, one who coaches the Scrum Team. This is wrong. The Scrum Master is really a project manager. They help the Scrum Team create high-value products, so they should lead the team by controlling the User Story Requirements List and assigning work to the developers and even the QAs. As leader, or manager, the Scrum Master has the final say on the order of the Product Backlog.