Should the customers or Product Owner worry about making all the acceptance criteria known in advance? Or should the Development Team and Scrum Master worry about them?
I'd suppose that it is the responsibility of the customers to exactly express all the acceptance criteria. If they failed to do so, then it is their fault (not the Team's).
Scrum is based on an empirical process control system. It assumes that not everything is known and that knowledge will emerge over time. Trying to specify every acceptance criteria in exact detail may not be possible and may take way more time than needed.
Instead, Scrum explains that the Development Team has continuous contact with the Product Owner or Customer to receive feedback. Additional Acceptance Criteria and adjustments to previously written acceptance criteria can emerge during the sprint as part of over-the shoulder-reviews, short demos, proof-of-concepts early in the sprint or even wireframes or paper prototypes. The development team can accept these additional and adjusted acceptance criteria and work them into the increment immediately, or, if the work would be major or endanger the Sprint Goal, the Product Owner can choose to put the additional work on the Product Backlog for a future sprint.
Another opportunity to inspect the Increment happens at the Sprint Review. The Customer can inspect the Increment and provide feedback in the form of new and adjusted Product Backlog Items.
The aim of Scrum isn't to deliver everything first-time-right. It's to deliver things quickly and provide opportunities for feedback. This feedback will allow everyone to further refine the product and mold it into the product that is truly needed, not the one we had described on paper.
The Product Owner remains responsible for defining the What and the Why. They remain accountable for the functional acceptance criteria and the required non-functional characteristics of the product.
The Development Team remains responsible for defining the How and the Quality. They remain accountable for the technical acceptance criteria and to turn the non-functional characteristics of the product into technical solutions that meet these characteristics.
The Scrum Master has no accountability on content, only on the process. Therefore they play no part in this. Unless the process to get the requirements and to receive feedback is broken in your organisation. If that is the case, the Scrum Master should help remedy this situation.
This question often surfaces, but how to deal with our estimates? If we accept that we can't know everything all the time, we should also accept our estimates will be less accurate.
Interestingly, if we tend to find the same number of unknown acceptance criteria in every sprint, then their impact will become evident through a lower velocity without ever having to adjust the way we estimate.
According to the Scrum Guide (2019), the Scrum Reviews are "informal meetings" in which the stakeholders are invited to participate and collaborate. Being "informal meetings" we expect the requests, needs and ideas presented by the stakeholders to be informal. The stakeholders inputs are very important, but those requests, needs and ideas are only inspiration for the team to identify what can add value for the product.
"The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog includes: Clearly expressing Product Backlog items" (Scrum Guide; 2019)
From that perspective the responsibility of the Product Owner alone.
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. (Scrum Guide; 2019)
I think the Scrum Guide is clear enough: The Development Team always shares the accountability on incomplete backlog items.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable (Scrum Guide; 2019)
I think is no coincidence that the Scrum Guide emphasize that the Project Owner can rely on the Development Team to organize the backlog. In my experience this is the most common practice. As consequence, the Development Team share the accountability.
In the end, if the Scrum Team members begin the pointing fingers game, the backlog will become a contract and the team will loose its dynamic and fail.
Your Question reads, to me, like "Something went wrong. Who do we blame?" The only situation in which "responsibility" (read: blame) should be relevant is when it is necessary - namely, when selling to an external party. In which case, the only valid answer could ever be: "Check your contract". This is a question for a lawyer, not a project manager.
If you're working with an internal customer, then what does it matter? So you reached the end of an increment and the customer pointed out something that wasn't done as s/he wanted? Good. Now you know what to work on next. Move on.
As per a quick ctrl-f for 'responsible' in the Scrum Guide...
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. [...] The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
The product owner is responsible for defining all the items in the backlog with enough detail for the team to be able to work on them. Acceptance criteria is part of those details. The product owner needs to have these clearly expressed before work begins.
Of course it's also the team's responsibility to make an effort to understand the items from the backlog to the necessary level. If they have questions, need more details, etc, they need to raise them with the Product Owner.
It is also the Scrum Master's job to make sure people collaborate and communicate to the proper level needed.
Ultimately though, it is the Product Owner that remains accountable for having items properly defined, acceptance criteria and all.
And since nobody is perfect, if something occurs and some things remain unclear, or some acceptance criteria is forgotten or omitted, this is an opportunity to improve your practices, not to place fault. Try to find better ways to work together, not point fingers.
Have a customer or product owner to worry about making all the acceptance criteria known in advance?
We shouldn't expect the customer and Product Owner to get requirements perfectly right every time. The reasons for this are:
Or have a team and scrum master to worry about them?
The Scrum Master and the development team should be focusing on the process that they are using to discover acceptance criteria. If they recognise that important acceptance criteria are being missed then they should raise this at a retrospective so that the problem gets addressed.
I'd suppose that it is the responsibility of a customer to exactly express all the acceptance criteria. If they failed to do so, then it is their fault (not the team's).
One of the Agile values is customer collaboration over contract negotiation. Rather than looking to assign blame it is usually more productive to concentrate on improving the way things are done.
Perhaps by working collaboratively with the customer you can find a way to reduce or eliminate the problems you are facing?
