Every new user story presented to the team for development, must be accompanied with a set of user acceptance criteria which can drive development and testing.
——————–
Acceptance criteria is a great tool to ensure that the product being developed is actually what the Product Owner wants. Every user story is accompanied by a set of criteria that specifies how it will be tested and verified, in order to be accepted.
The concept behind acceptance criteria, hence, extends itself to the fields of user acceptance and testing activities and in general it means that every endeavor in developing must be guided by a specification of how it will be tested.
Often it happens, indeed, that if no acceptance criteria have been specified, developers finish to code, pass it over to tester and Product Owner for testing and acceptance phases, which reject it because it doesn’t satisfy their expectations.
Even more discouraging is when the story is rejected because of some minor issues caused by misunderstandings.
The trick here is to start in the right direction from the very beginning, that is when the Product Owner presents the stories during the planning meeting.
Let’s take the user story below as an example.
As a home banking user
I want to make a money transfer
So that I can pay the loan even if the bank is closed
To specify the user acceptance criteria (UAC) I like to use the GWT (Given When That) syntax, which is explained below:
Given [a specific condition] And [...] When [an event occurs] Then [outcome] And [...]
Now, let’s see three basic acceptance scenarios which can be used to test and accept the user story above.
Scenario 1
Given that the account balance is € 2.000,00
And the user is trusted
And the beneficiary bank account exists,
When the transfer amount is € 800,00
And the security operation code is correct,
Then the bank should transfer € 800,00 to the beneficiary
And the account balance should be updated to € 1.200,00
Scenario 2
Given that the account balance is € 500,00
And the user is trusted
And the beneficiary bank account exists,
When the transfer amount is € 800,00
And the security operation code is correct,
Then the bank should not operate any transfer
And a message must displayed saying there are insufficient funds
Scenario 3
Given that the account balance is € 2.000,00
And the user is trusted
And the beneficiary bank account exists,
When the transfer amount is € 800,00
And the security operation code is NOT correct,
Then the bank should not operate any transfer
And a message must displayed saying the code is incorrect
With this information available, developers and testers could immediately work together to refine the behavior of the functionality.
Thus, the tester can work on test cases and scenarios and the developer has a clear understanding of how her work will be verified and tested; she hence will develop only the minimum amount of well-written code to make all tests pass.
Simplicity actually starts from here: do your remember the Agile Manifesto principle?
“Simplicity–the art of maximizing the amount of work not done–is essential.“
Simple, isn’t it?!
