Scrum Myth: The Sprint Backlog is a Commitment

What if a product owner cannot attend backlog meetings due to time constraint or communication gaps? Should a scrum master coordinate with Product owner and discuss business value and clarify requirements or discuss with the team and then coordinate with product owner?

The first option would be to try to get the Development Team (DT) and the Product Owner to talk direct to each other at some point before the PO's other meeting. I wouldn't restrict backlog refinement to a meeting, the team could easily discuss with the product owner ahead of time or the product owner could see the backlog refinement sessions as worthwhile and not schedule other meetings during that time. The Scrum Values extend to the Whole Scrum Team not just the DT so if the DT are committed to the Sprint Goal then so should the PO be committed to the same Sprint Goal.
It is the least preferable option for the Scrum Master to become the conduit of information.

... perhaps we should recommend this article to our recent employer, Alasdair ... from Nigel

Is really impossible for the PO to reserve 8 hours each month to clarify what he/she wants to be built in the next Sprint?

To wake some people up, I dare to bluntly say "no time, no product"... Given all Scrum events are timeboxed, the timing these take place is known well in advance. The Product Owner has to take his/her responsibility on this... Clarifying requirements should already have taken place during the backlog refinement.

This is a common misunderstanding within many organizations. Usually these people also believe that Agile means two week deadlines with daily (or almost daily) status reports.

Instead of rephrasing (then quoting) The Scrum Guide, it might have been more effective to focus the content of the article on clarifying how forecasting is different than classic PMI project plan expectations.

If they are running 4 week sprints then the PO should be prepared to do so, but if they are fulfilling the role of PO well then they are probably clarifying on a regular basis the same as refinement and then wouldn't need the 8 hours. Its a time box following the standard format that if you complete the activity within the timebox then you can end the session the only special container type time box is the Sprint itself.

Nobody said that the 8 hours had to be in just one meeting :)

Educating managers, directors, chiefs, etc who have been living the traditional, manufacturing-based project management mindset for a long time is nearly impossible in my experience. Also due to the technologists having been trained and working in the same mindset makes it difficult for many of them to adjust their approaches; they often enjoy the status of being the XYZ specialist. This is one reason that I have left the corporate software product development world. There is no winning, just rebranding the same-old same-old.

Would you mind to clarify me about the following phrase.

"As you read further you can see that it states the Development Team updates the Sprint Backlog regularly. If new work is identified and required, it is added and if work is deemed no longer necessary it is removed."

This means that some work will be created without having their origine at the Product Backlog? Let me explain my doubt a little more. For instance the team forgot to add a very important feature that was identified only in the middle of the sprint. Can we create this item directly in the Sprint Backlog or should we first create it in the Product Backlog and then put it in the Sprint Backlog?

Hi, Rodrigo!!

In case we discover something necessary to do with the selected product backlog items we pulled to the spring backlog, we need to add these items to our sprint backlog.

In case it is something bigger, an item missing from the product backlog, it must be done by the PO, as he owns the product backlog.

In Sprint Planning we go through the Sprint Backlog items and the needed tasks, so it all should be feasible to do with the already existing items.

Nevertheless, such discovery should be discussed with the PO as soon as possible to adjust whatever might be needed :)

I disagree with the characterization as a "Myth". It was actually part of the scrum guide until 2011, when it was changed to "forecast".

Fully understand Sprint Backlog is not a commitment. But just curious that the Sprint Goal is not a scrum artefact, how can we enhance the transparency and commitment? After all, the more transparency is, the stronger commitment is.

When is the Sprint Backlog created? During the Sprint Planning meeting or Prior to the Sprint Planning meeting

DTFW RTFM
https://scrumguides.org/scr...
The Sprint Backlog is the output of the Sprint Planning event.

You are acknowledging that it is not commitment then asking how to enforce commitment. 🤔
The Sprint Goal can be, and arguably should be, communicated so that stakeholders external to the Scrum Team know what to expect before the Sprint Review event is conducted.
The commitment that is important is to the value of the Product Incement, therefore the product itself. Professionalism to the craft is the solution. This can be achieved via promoting and supporting the self-organization of the Scrum Team.

Makes sense. It is helpful

The PO's job is to attend the meetings. If not possible then the person is not a PO and has nothing to do with the job or you are not doing Scrum.

If you want to solve the problem, then ask the 5 "why" question.
If the issue comes from the PO, then you must realign the person on their job
If the issue is management, then get the Scrum Master to deal with them

Very good clarification.

As mentioned the real commitment in a sprint is towards the Sprint Goal. The items it takes to deliver the Sprint Goal may not be written in stone. The commitment is also flipped from a team manager nagging the developers to deliver all the items to the developers themselves being responsible to have a conversation with the product owner at the earliest point the consider the sprint goal may not be deliverable.

If it was to highlight a whole new product backlog item then a discussion should occur among the developers and the product owner to understand, prioritise and if necessary for the goal possibly bring it in to the sprint. If you mean work is discovered to deliver an item that is already in the sprint backlog then it is either a task to be done or a test to be fulfilled and this is within the remit of the developers to add to the sprint backlog in order to complete the delivery of the PBI and sprint goal.

Thanks that's a common response when discussed in a class :)

That would be into refinement which would be great if it was made formal in the guide. The better the use of refinement the less problems tend to occur in sprint planning. Nothing then against being smart and using the teams down or in between tasks time to help in refinement.

Thanks for clarifying! It's like "I am committed to giving a good education to my son". But being committed to what subject he chooses at school makes no sense!!

Quite a wide spread myth indeed, thanks for clearly elaborating it