Given – When – Then (CREATING ACCEPTANCE CRITERIA)
In my previous article, I mentioned about User Story, Theme and Epic concepts and focused on their functional assistance, you can find the article on the following link,
It is the truth that User Stories form the basis of Acceptance Criteria. However, even user requests that are shortened with only one sentence are input of the Product Backlog, even though they are not adequate to Acceptance Criteria or Definition of Done by itself. That is why, in Product Backlog Refinement meetings (aka Grooming), User Stories should be elaborated on. In this article, I handle the issue of GIVEN-WHEN-THEN formulas that we use for detailing User Stories for creating Acceptance Criteria. Because GIVEN-WHEN-THEN formula creates the unit test scenarios, creating acceptance criteria with that formula decrease your testing initiation and execution process.
GIVEN-WHEN-THEN formula which is created by Dan North and Chris Matts, is one of the method of Test-Driven Development(TDD) and it executes from the beginning to end of the sprint to minimize bugs in development period.
With the help of this methodology, pre-process and post-process parts are separated with each other clearly; and it also helps to reflect whether utilities of product and requests of customer are match or not.
Every acceptance criteria (aka. Scenario) is formed with 3 main theme;
- Scenario starts with a single situation explanation. This situation can be linked one or several condition with AND/BUT clause. (xxx GIVEN yyy AND/BUT zzz)
- In second part, action that triggered the process should be defined. If these actions are more than one, they can be linked each other with AND/BUT (WHEN aaa AND/BUT bbb)
- In last part of the formula, output of the process is clarified. (THEN www AND/BUT qqq)
My example starts with the level of User Story to reflect the whole scenario.
As a Bank Customer,
I want to buy/sold stock on the mobile app of the bank
So that, I can direct my investments on the mobile platform with my defined truth.
Based on this User Story, there are lots of scenarios can be written with the Given-When-Then formula.
I write the “Buying Stocks On Mobile App” scenario with Given-When-Then.
Scenario: Buying stocks on mobile application
GIVEN, Customer has right to buy stock
AND, Customer selects A,B,C or D type Stock
AND, Customer accepts legal policies
AND, Customer has enough remaining in investment account
WHEN, Customer clicks on “Buy Stock” button
THEN, application sent buying request to stock market
AND, application show the notification about buying is on process
AND, stock price discount to Customer’s account
AND, bought stock information is shown in customer portfolio
While writing the Acceptance Criteria with Given-When-When scenario, “BUT” condition has also significant value like “AND” clause to get what should not include to define restrictions and limitations (for more information you can also take a glance at “Gold Plating” term).
It is shown that, while creating Acceptance Criteria with Given-When-Then formula, it replies the question of ”how a feature or piece of functionality will work for the item” and provide the test scenario in unit-test level. User Stories and Acceptance Criteria complete each other in this perspective. That is why, every single job that are included to the sprint, should have complete User Stories and Acceptance Criteria to match the customers’ needs with the output of the sprint.
In brief, it may not said that, User Story and Acceptance Criteria are both hard to create nor take time while examining the items in detail. However, the sprint period that starts with fuzzy demands just spend the resources of the project. There is no doubt that Agile does not mean that undocumented version of project management. Even if Scrum can adapt the changing condition and demands; sprint should start with clearly defined demands to answer the customer request at the end of the project.