Acceptance Criteria

Myth: The PO must document the Acceptance Criteria(AC) for each Story.
Variations:

• The team can reject taking a Story if the AC are not defined
• The PO is responsible for defining the AC
• ...

Follow-up myths:

• ...

Category: General Scrum myths
Danger: Moderate

The basis of the myth

Acceptance Criteria are derived from the Scrum Guide, without being specifically mentioned. What is mentioned is only this:

Those performing the work and those accepting the work product must share a common definition of “Done”

Explicit Acceptance Criteria increase transparency and align expectations, so they are a good idea for most teams.

Why is it a myth?

The first part of the myth is that AC's are mandatory parts of Scrum, the second is that they somehow are PO domain. But there are a lot of hidden assumptions that hold explosive potential:

Assumption #1: The Requirement Manager
A Product Owner in Scrum is responsible for making sure that the team delivers the most valuable product. In traditional organizations, this is often the responsibility of a "Requirements manager" who not only dictates the "What", but also the "How". This concept simply does not transfer to Scrum. Maintaining it creates a culture where teams don't take ownership of the delivery.

Assumption #2: Single Point of Failure (SPOF)

A Product Owner (should) know what the customer needs, but that doesn't mean the developers don't. The Agile Manifesto encourages continuous dialogue between developers and Customers, so developers should also have a clear understanding of customer needs. Holding the PO personally responsible for providing a comprehensive list of Acceptance Criteria turns the PO into a Single Point of Failure, and a bottleneck.

Assumption #3: Big Upfront Design (BUFD)

Comprehensive lists of Acceptance Criteria assume that before the Sprint starts, significant work has been invested into defining details of the solution. Not only does this assume that analysis happens before the Sprint, it also assumes the PO is Chief Analyst - a concept highly incompatible with their definition in Scrum!

Consequences

Hidden Waterfall

When developers assume that someone other than they has responsibility for ensuring success before they even start working, this hints of a Waterfall mindset and an absolution of responsibility. 

Lost Opportunities

Business value can only be maximized through continuous Inspect+Adapt. By presuming that Acceptance Criteria can be comprehensively defined early in the process, the team is undermining both continuous feedback and adaption.

Capacity Waste

The Product Owner is already struggling to allocate their limited time with maximum value for the Scrum team. Holding the PO responsible for detailed Acceptance Criteria forces the PO to drop other, potentially significantly more important activities, such as acquiring funding or managing stakeholders.

Design constraints

Acceptance Criteria typically require a certain understanding of how the solution will be designed. This might even create technical constraints on a level the PO is unaware of. Predefined Acceptance Criteria might force the team to create suboptimal solutions.

Remedies

Detailed Acceptance Criteria help to provide clarity and align expectations. They solve the problem of Product Owners not being happy with the solutions provided by the team. A better solution is to continuously engage the Product Owner in dialog throughout the Sprint.

At some point, they need to be defined - usually no later than the creation of Acceptance Tests, which are part of sustainable development. Since AT's are development domain, the people with the most skill at defining useful AC's are usually developers, anyways. If they don't know how to do that, they need some training.

Rather than train the PO in providing "better AC's", the team needs to learn to have the right conversations. Take heed of which necessary conversations are not happening and adjust there.