Given – When – Then
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, (https://www.linkedin.com/pulse/theme-user-story-epic-ali-saracoglu-mba-psm-pspo-itil?trk=prof-post).
It is truth that User Stories form the basis of Acceptance Criteria. However, they are not adequate to be named as 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. GIVEN-WHEN-THEN formula also creates the unit test scenarios, so creating acceptance criteria with that formula decrease initiation and execution process of your testing period.
GIVEN-WHEN-THEN formula which is created by Dan North and Chris Matts, is an approach 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. It also helps to confirm whether utilities of product are match with the requests of customer.
Given-When-Then formula is generated within the context of 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 (to get more information about writing User Story, you can reach my related article on the link https://www.linkedin.com/pulse/theme-user-story-epic-ali-saracoglu-mba-psm-pspo-itil?trk=prof-post).
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. With the help of that “BUT” clause, restrictions and limitations can be defined for the scenario (for more information you can also take a glance at “Gold Plating” term).
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 respect. That is why, every single job that are included to the sprint, needed to have completed User Stories and Acceptance Criteria to match the customers’ needs with the output of the sprint.
In brief, creating User Stories and Acceptance Criteria are both hard to create and takes time. However, the sprint period that starts with fuzzy demands, spends the resources of the project. There is no doubt that Agile does not mean undocumented version of project management. Even if Scrum has flexibility to adapt the changing condition and demands; sprint should not start with ambiguous demands to meet with the customer request at the end of sprint.