Writting better acceptance criteria

Clear acceptance criteria helps get it done right the first time.
January 22 2016

Back on my current fragile project and I've come across an acceptance criteria (AC) for a user story.

AC-21: When member is returned to this page from a subsequent page the user is only permitted to go through the online verification successfully once IF the user fails the online verification THEN the user is permitted to re-try the online verification process once more. In the case that the user can not attempt the online verification process again disable the ‘edit’ button within the ‘Your address details’ module.

I spent a bit trying to get my head around exactly what is required here and what is the motivation from the user, so I could code it up correctly.

What we've got here is a business analyst trying to be a coder.  Or maybe a coder turned BA, I don't know. Either way it's a poorly written requirement.  Mainly because it doesn't really given any information AND it talks about specifics of the software, such as buttons and modules etc.

Remember, behavioural AC's are well suited to be written in the "Given Then When" format.  Putting on my BA hat I would rewrite it like this:

AC-21: Given I am a member on step 3 and I have unsuccessfully validated my address once, when I return to step 2 to change my address, then I shall have one final attempt to update and validate my address.

What benefit is this?  It doesn't describe the business rule in terms of UI features that are enabled/disabled/visible.  It describes the business rule in an easily understood language.

Don't be that annoying person. Write clear specs.

Post a comment

comments powered by Disqus