How do you prevent poorly written acceptance criteria?

Question

One of the biggest problems from my daily work in the team is the acceptance criteria are mostly too unclearly defined. What this means in detail:

• Stands inquiries, because the PO or a developer has expressed itself in the acceptance criteria again wrong or too broad

• Acceptance is sometimes very difficult because acceptance criteria
  have to be added

• Constant post-processing of test cases by supplementing or adapting
  the acceptance criteria

• I have addressed the topic several times in retroperspective, but so far you can not adapt to it, or refer me to the Scrum process.

Despite my many years of experience, I am reaching my limits and unfortunately can not continue. Maybe you?

Answer 1

prevent them ? hmmm

• Educate on how to write them the right way
• Educate on why to write them the right way
• Dducate on consequences of writing poor ones
• Have a review step before they are used
• Create published standards
• Agree to follow standards

Answer 2

The standard format to write a user story is below, but it does not guarantee that user stories would be written well. But it should be followed.

**As a < role >

I want to < do something >

So that < business value >**

Few suggestion you can try that I have followed in my software testing services organization.

1. Ask for business use case for each story from PO, it will help you to understand the real problem and you can relate the feature functionality with it.
2. Ask as many questions, when story reaches you
3. Ask for most-granular information in the story so you can estimate it properly
4. Ask for outcome (RESULTS) of acceptance criteria that is always testable with minimal ambiguity.
5. Ask your questions related to stories in sprint planning or product backlog grooming meeting, where stories are discussed
6. Create one liner short test cases, so you can change it later if required

Answer 3

User stories are a good approach. have a look at the INVEST pattern. it states that a story has to be testable. So when working at a story, it should be clear what to test and if the test succeeds, than the story is done.

If you then encounter changing acceptance criteria, treat it like a new user story. When you still feel an unreasonable test maintenance per story, you could maybe look for improvements in you test automation.