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?

  • 1
    "so far you can not adapt to it" why not? Scrum says nothing about how to document acceptance criteria. Not that you should, nor that you shouldn't. The word "acceptance" is 0 times in the Scrumguide: scrumguides.org/scrum-guide.html Apr 26, 2019 at 13:10

3 Answers 3


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

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

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.