Business Gherkins: Communicate Scenarios
Product management varies across different organisations and it makes me super happy that tech companies share very similar contexts about what the role requires. It’s essentially about owning all the processes involved in the product cycle, core product managers essentially manage the development and iterations of the product, which means that you are constantly communicating with different stakeholders and the most important stakeholders for you are your customers and the product team (designers, product owner, engineers, QA, etc). One way of communicating customer needs is Business Gherkins.
Business Gherkins were initially developed by business analysts as a structured style of detailing the way a system is expected to behave given statements and some keywords. In simple terms, you use keywords to describe the behaviour of a product in a syntactic format.
The Gherkins language is a great way to add acceptance criteria to a theme, epic or user story. It is very useful when you work with a team that has not established a unique style of communicating requirements, user stories, etc. Gherkins help you detail scenarios in the form of acceptance criteria and it is super easy to read but it can be tedious to write when you have multiple scenarios. The scenario can be a happy one (where the feature achieves the user’s goals) and it can be a sad one(where the feature does not achieve the user’s goals.
The syntax is in the following keywords:
Given, When, Then.
These keywords describe system behaviour with scenarios. Let’s play with an epic for an e-commerce product that wants users to save cards for recurrent payments.
Epic: As a shopper, I want to add my card as a payment option so that I can make recurring payments on the mobile app.
Scenario: The shopper successfully adds cards as a payment option for recurring payments.
GIVEN The shopper is logged in
AND has purchased an item
WHEN The user selects a new payment method
AND Enters card details
THEN The system should save the card details.
AND The shopper should see a pop up that the card was successfully added.
The instance above does not do justice to what a business gherkins is in totality because it only communicated one scenario specifically a happy scenario for that epic, meanwhile there are also sad scenarios where things do not work as planned but before we delve into that, let’s look at what those keywords mean.
The “GIVEN” keyword simply represents the condition for the user’s goals to be achieved.
The “WHEN” keyword simply represents the action taken by the user for the goal they are set to achieve.
The “THEN” keyword simply represents the expected result from the action taken.
The “AND” keyword simply represents the continuation for every keyword. The AND keyword is important because we use phrases for every keyword and AND helps us keep things short and systematic.
Let’s try and create Gherkins for a sad scenario:
Epic: As a shopper, I want to add my card as a payment option so that I can make recurring payments on the mobile app.
Scenario: The shopper cannot add a card because the CVV on the card is wrong.
GIVEN The shopper is logged in
AND has purchased an item
WHEN The user selects a new payment method
AND Enters card details
AND The CVV at the back of the card is incorrect
THEN The system should not save the card
AND The shopper should see a pop up that the card failed to save.
Conclusion:
Business Gherkins are great for product teams especially those whose features work based on integrations that might cause the feature to fail or succeed. The product manager uses them as a form of acceptance criteria that details how the system should behave or what output the user of the product receives.
Gherkins might be daunting at first but they get easier to write and they start to inform your thinking on product functionality and the overall user experience of the product in question.
