How do you prevent poorly written acceptance criteria?
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?
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.
- 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.
- Ask as many questions, when story reaches you
- Ask for most-granular information in the story so you can estimate it properly
- Ask for outcome (RESULTS) of acceptance criteria that is always testable with minimal ambiguity.
- Ask your questions related to stories in sprint planning or product backlog grooming meeting, where stories are discussed
- Create one liner short test cases, so you can change it later if required