1

Please give honest feedback about whether this is a good style of acceptance criteria. Please detail what is wrong with it.

Given <source system> has pushed the <account details file> into the specified location
when <file system> receives this <account details file>
then <file system> should pre-process raw <account details file> and transform it into consumable data and must check the processed <account details file> against the <validation rules>

*<validation rules>*
1. Raw <account details file> data should match with the processed <account details file> data in <file system>

2. Record count should match between raw <account details file> and processed <account details file> for file header, footer and body.
| improve this question | | | | |
  • What do you mean by in a JIRA? – Paul Wasilewski Apr 29 '17 at 14:52
  • This looks like Gherkin syntax. Why should JIRA care about the format of your acceptance criteria? What's the actual project management problem you're trying to solve? – Todd A. Jacobs Apr 30 '17 at 1:59
  • As written, this question is too specific to your individual use case to be anything other than an opinion poll. Please edit the question with additional context, and to allow for a canonical answer rather than soliciting opinions. While most answers will have some degree of opinion, PMSE is a Q&A site that strives to provide canonical answers to concrete questions. Once edited to be on-topic per our help center, the question can be re-opened. – Todd A. Jacobs May 3 '17 at 6:26
  • 1
    The question of what constitutes good acceptance criteria is valid and can be answered fairly objectively. Just remove the part about being specific to Jira. – Pedro May 5 '17 at 12:09
3

Good Acceptance Criteria cannot stand alone. It has to be derived from the requirement description - e.g. User Story. Therefore, a good requirement description is the starting point.

However, without knowing the requirement details is hard to say if your example is a good one or not. But anyway, let's take a look at the basics.

Acceptance Criteria should include functional and non-functional criteria which has to be fulfilled by the final product to confirm that the related requirement is realized.

Now, let's take a look again at your example.

Given <source system> has pushed the <account details file> into the specified location
when <file system> receives this <account details file>
then <file system> should pre-process raw <account details file> and transform it into consumable data and must check the processed <account details file> against the <validation rules>

*<validation rules>*
1. Raw <account details file> data should match with the processed <account details file> data in <file system>

2. Record count should match between raw <account details file> and processed <account details file> for file header, footer and body.

First of all, you are using the Given-When-Then formula which is primarily used to define Acceptance Tests. So I don't think this is a good approach to define Acceptance Criteria at all.

Acceptance Tests should be derived from the Acceptance Criteria. Acceptance Criteria helps to make clear when a requirement is done while a acceptance test is used to verify if it's really done. Imho a good way to write Acceptance Criteria is to write them as a bullet list.

  • File System has received pushed file ...
  • File System has validated the received file by validation rules ...
  • ...

Beside that your example doesn't include any non-functional criteria (Performance, Fault Management, Robustness, Comprehensibility, ...). As far as I can assess some non-functional criteria for your case might be.

  • The file system process, transforms and validates 1000 files within ...

  • If a account details file is not valid it has to be moved/deleted/marked ...

  • If the file system is not available pushed files should be processed when the file system is available again ...

  • The file system logs every received file ...

  • ...
| improve this answer | | | | |

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