As I visit with software development teams, I keep running into the same confusion about the word "acceptance." Two ideas get jammed together that really shouldn't be. Let me pull them apart, because the distinction matters more than it sounds.
Acceptance criteria are the Product Owner's or stakeholders' definition of success for a given PBI. They define Done. Acceptance testing is the activity of verifying that those criteria are satisfied. One is the standard. The other is the act of checking against it. Conflating the two leads to sloppy thinking and, worse, sloppy claims about what's actually finished.
The misconceptions I hear most
The first is that acceptance is performed by the users, often called user acceptance testing. In Scrum, this is never true. Only the Developers do the work, and that means all the work, including testing. If stakeholders want to give feedback, the Sprint Review is the place for it. They don't get access to the red button that declares a PBI not Done.
The second misconception is the dangerous one: that having passing acceptance tests is equivalent to the PBI being Done. It isn't. Passing acceptance tests only prove that the acceptance criteria have been satisfied. They do not prove that every aspect of the Definition of Done has been met. You might still owe documentation, a release note, or other quality work before that PBI is truly Done.
When acceptance is its own activity
Here's where it gets sharper. If your Definition of Done includes the Product Owner "accepting," "liking," or "loving" the work, then acceptance testing and Product Owner acceptance become two distinct activities. Any Developer can run and pass an acceptance test. Only the Product Owner can accept the PBI. Those are not the same event, and pretending they are will eventually burn you.
This kind of subjective acceptance is hard to capture in an executable specification and impossible to automate. It will always be a carbon-based test, meaning the Product Owner has to put their own eyes and fingers on the work. So don't wait for the Sprint Review to discover whether they like it. It's a smell when a Product Owner is inspecting PBIs for the first time at the Review. Get that feedback earlier, while there's still time to act on it.
So sharpen your language. Criteria define Done. Testing verifies the criteria. Acceptance, when your Definition of Done calls for it, is the Product Owner's separate nod. Three distinct things.
Stop saying "acceptance" when you mean "acceptance testing." The teams that keep them straight ship with fewer surprises.