The C Word in the Scrum Guide

From a Product Owner's perspective the Development team still needs to be held accountable for their forecast. If things go according to plan during the sprint, then the PO should have the expectation that the forecast should be delivered. If things don't go according to plan, then they should be involved in the discussions on changing the forecast. Regardless, at the end of the sprint the team needs to be held accountable for the increment delivered.

Thank you very much the comment. I would say the dev team should work to find a forecasting method that is reliable and representative of their process/organization.

From what I am seeing, there's a big push on teams being more DevOps. In that reality, they have for example outages, production bugs or post mortems to review because of regulations. As dev teams have to manage operations with development now, I find it unrealistic that the team hit 100% their forecast every iteration.

Dear Louis-Philippe Carignan
your article is a valuable contribution in the general discussion about how "the team commits..." had created so much confusion and we are very grateful.

However it's important to remark the difference between the verb TO COMMIT and the substantive COMMITMENT

The first suggest, as you properly remarked, that the action "has to" be performed, as if the Dev Team members have "signed an obligation" with their PO (very old Industry approach, indeed) and if they don't deliver, then their somehow have failed!

On the contrary, Committment is one of the 5 core VALUES of Scrum, officially added to the Guide!

The proper and sincere adoption of Commitment - as an attitude, a value, not a prescription - reflects itself into the Sprint forecast, including all the efforts to genuinely do our best to meet it, remaining open and ready to failure, inspection and adaptation.

I find Gunther Verheyen's words truly inspiring, so I won't rephrase them, but simply post a quote here below, so you guys can get my, our point.

Happy and productive scrumming! 🙏
LLAP
Michael

"To better reflect the original intent and connect more effectively to empiricism, ‘commitment’ in the context of scope for a Sprint was replaced with ‘forecast’.

However, commitment still is and remains a core value of Scrum:

The players commit to the team. Commit to quality. Commit to collaborate. Commit to learn. Commit to do the best they can, every day again. Commit to the Sprint Goal. Commit to act as professionals. Commit to self-organise. Commit to excellence. Commit to the Agile values and principles. Commit to create working versions of product. Commit to look for improvements. Commit to the definition of Done. Commit to the Scrum framework. Commit to focus on value. Commit to finish work. Commit to inspect and adapt. Commit to transparency. Commit to challenge the status-quo."

Source: https://guntherverheyen.com... translated in 10+ languages)

Thank you so much Michael for taking the time for such a valuable comment. I didn't want to extend my post on the word commitment in the Values section or come back to the 2011 article explaining why the Scrum guide back then replaced commitment with forecast. I just wanted to stay focus on the sprint planning event.

I really appreciate what you added Michael. I'm totally in line with Gunther's quote.

Ken and Jeff's original Scrum book emphasized commitment very strongly. In the first scrum training course I ever went on (given by Ken), commitment was talked about as a core value of the team and vital to success. At the end of sprint planning, the team must believe the goal and the sprint backlog are achievable, and their behaviours during the sprint must be to protect the goal. If sprint planning just results in a bunch of tasks that may or may not get done in the sprint, that's not scrum in any form that I recognize. In your example of a team being DevOps...

1) if their actions routinely result in large numbers of production incidents, they probably need to devote time to refactoring and improving their quality assurance practices.

2) most mature DevOps teams will address your concerns by factoring some level of unpredictability into their velocity and use that as the basis for planning (i.e. perhaps only 70% of their time can realistically go on planned work)

3) teams that are mostly interrupt-driven and therefore cannot plan probably shouldn't use scrum.

Personally, I'm not in agreement with the de-emphasizing of commitment for scrum teams. The team members are adults and should bear responsibility for their words and actions, work to meet their commitments having made them and then inspect-and-adapt if they found they took on an unsustainable amount of work. I have a lot more respect for teams that work that way than ones that simply allow a sprint to fail because their estimating needs to improve.