“Gherkins” come from the world of Behavior-Driven Development. Whether or not they wind up being used for automated testing doesn’t matter in this context, because Gherkins are the very best way that a Product Owner can provide small stories with focused, clear requirements.
Typical User Story Format
As a (persona), I need to (action I need to complete) so that (the benefit received; the outcome; the value created).
Gherkins as a Different Kind of Acceptance Criteria
Devs and QA tend to love it when POs write tiny little stories in Gherkin format because it’s immediately obvious what they need to code and test. Plus, when things break, it’s super-easy to figure out when and where it happened.
Here’s what they look like:
Given (context)
And… (additional context as needed)
Or… (additional conditions as needed)
When (action) Note that this is a SINGLE call to action and that there are no And’s or Or’s here
Then (outcome)
And… (additional info as needed)
Or… (additional possibility as needed)
Using this format will alert you to when a story is starting to creep up in size. If you have lots of And’s or Or’s, there’s a good chance a few extra stories are hiding in there!
Writing Gherkins: a real-world example
So, does this actually work in real life? Absolutely. I have never seen a team that introduced Gherkins NOT have more efficient Refinement and Planning or not see immediate improvement in their delivery and predictability. And I’ve worked with a lot of teams. In fact, I would go as far as to say that the teams who use Gherkins are the best-equipped for truly Agile because the combination of good Gherkins and small stories all but eliminates rework (vague + big = swirl + rework).
Sample Gherkins
Business logic: Add a check to a specific checkbox that appears on Screen A with List A, AND on another Screen B in a different system with List B when
Case 1: Condition 1 is met (occurs when three specific things are TRUE), OR
Case 2: Condition 1 is not met but Condition 2 is met (occurs when two other specific things are TRUE)
Oftentimes this would be treated as a single (large and unclear) story. Why? Because of the prevalent (but incorrect!) assumption that a larger batch is more efficient to work on, and because it’s not valuable to the customer until all the logic is in place (which is actually true – but here we are simply talking about the mechanics of doing the work, not value delivery.)
So, how many good, small stories do you think might come out of this requirement? Turns out, it’s actually a couple of dozen.
First case: Story #1
SCENARIO 1:
Given that I am on the Badges Screen
And my score on Beginner Level was >= 50
When the “My Awesomeness” List is displayed
Then the box for “Beginner” is checked
SCENARIO 2:
Given that I am on the Badges Screen
And my score on Beginner Level Part 1 was NOT >= 50
When the “My Awesomeness” List is displayed
Then the box for “Beginner” is NOT checked
First case: Story #2
SCENARIO 1:
Given that I am on the Badges Screen
And my score on Beginner Level Part 1 was >= 50
And my score on Beginner Level Part 2 was >=25
When the “My Awesomeness” List is displayed
Then the box for “Beginner” is checked
SCENARIO 2:
Given that I am on the Badges Screen
And my score on Beginner Level Part 1 was NOT >= 50
Or my score on the Beginner Level Part 2 was NOT >=25
When the “My Awesomeness” List is displayed
Then the box for “Beginner” is NOT checked
Rapid Refinement Tips: Tactical advice
Lisa Mabli is a Managing Agile Consultant at LitheSpeed. See Lisa talk about great Gherkins live below.
Contact us to bring private training to your team.
