That’s a huge word that carries a lot of weight.  It’s also a word that has had a shift in definition – as it relates to Scrum – in recent times.  So what, exactly, do we mean when we are talking about commitment?

For a long time, commitment meant “I am going to do everything it takes — working 9 days a week, 27.5 hours a day if necessary — to make sure this gets done exactly on time and exactly as described by the requirements.”  For some people, this is still what it means, being on call non-stop, never being able to disconnect, even on vacation, and putting that commitment above all else.

That’s not how this works.  That’s not how any of this works.

Go back to the Scrum Guide for a minute, open it in a separate window or tab.  Got it?  Now search for the word “commitment” in there.  As of the November 2017 update, there is exactly one place you will find it, and that’s in the Scrum Values.  Further, the Scrum Guide states:

“People personally commit to achieving the goals of the Scrum.”

That’s it.

Commitment doesn’t mean we have no life and pull out every single last stop to get everything done exactly as commanded by some arcane (and likely out of date) requirements document.

• It means that everyone on the team is dedicated to helping the team succeed.  The exact work that will be done within a Sprint can and will change as work is underway, but always with the end desire of achieving the Sprint Goals.
• It means that if we are behind, the Development Team will sit with the Product Owner and have a conversation to make adjustments to the work in the Sprint so that an increment of working software is done when the Sprint ends.
• It means that the Product Owner leaves flexibility in his or her Acceptance Criteria so that the team has room for negotiation.
• It means that the Scrum Master is actively listening and responding to the needs of the team.
• It means that we are going to do our best, but recognize that if we fall short it will not be for lack of effort.

Organizationally, it means that we empower our Scrum Teams, and give them the resources and flexibility they need to be successful.

When the team sets their Sprint Backlog, we should stop talking about commitment – as it relates to the old way of thinking – and recognize that we are talking about a forecast. Things may change as we get more clarity on any or all user stories in a Sprint.  Things may be moved out, or be added, to allow the team to still meet the Sprint Goal.

That doesn’t mean the team failed to meet its commitments, it means they are being truly Agile.