Traditional vs. Gherkin User Stories
How switching to the Gherkin model transformed product outcome
After 6 years of being a product manager, I decided to change my style of writing user stories. I was getting frustrated by the inconsistencies of stories, the unknown product gaps discovered during the development process, and by the number of stories getting rejected by QA. After some research, I discovered the Gherkin model, and I wish I found it sooner.
Benefits of Gherkin
Speak engineering
Reading user stories is not all that exciting, especially when they are long and confusing. The Gherkin model provides a structured framework that speaks their language…
- Scenario: What is the desired behavior or action?
- Given: This is the context or where the environment occurs
- When: The user performs a specific action
- Then: The behavior/outcome occurs
Scenario driven
Being able to think in terms of scenarios helps the team understand the full user journey and it shifts the conversation to outcomes rather than features. This improves team alignment, product knowledge and uncovers possible requirement gaps earlier in the process.
Consistency
Every product manager has their own style of writing or structuring stories. Following a set framework removes subjectivity and creates consistency across the product team. As developers and QA migrate between scrum teams, the consistent structure expedites the learning curve.
Case study: Traditional vs. Gherkin
In this made up situation, we are building a web application to calculate an accurate price for a particular good/service. One of the many attributes needed to calculate an accurate price is to collect the user’s address. The address collection screen will look something like this:
Traditional user story
User story: As a prospect, I want to quickly provide my address so I can get an accurate price.
Why? The user wants to get their price and they want to spend as little time as possible answering tedious repetitive questions.
Requirements
- Search and auto-populate address as the user is typing in their address (ie. Integrate with Smarty, Google maps or other)
- Once required fields are provided, continue button shall enable
- Required fields: address, city, state, zip
- City, State and Zip should be disabled and should not be allowed to be changed once address is populated from the auto search
Acceptance Criteria
- User shall select address from auto-search recommendations
- Once the address is selected, all the fields will auto fill and the user can’t change city, state or zip
- Once the address is complete, the continue button will enable
Gherkin user story
User story: As a prospect, I want to quickly provide my address so I can get an accurate price.
Why? The user wants to get their price and they want to spend as little time as possible answering tedious repetitive questions.
Scenario 1: Auto search address
Given: The user is on the address screen
When: They start typing in their address
Then: The address will auto suggest options after 3 characters are provided
Scenario 2: Populate address
Given: The user typed in 3 or more characters of their address
When: They select their address from the suggestion list
Then: All the address fields will auto-populate
AND: the user will not be able to manually change the city, state or zip
Scenario 3: Change address
Given: The user wants to change their address because they made a mistake
When: They delete a character from the first address line
Then: The address auto-suggest will appear so the user can select a new address
Critique of user stories
Conclusion
While the Gherkin framework doesn’t work for every single story type, when applied effectively, its impact can be tremendous. Since I switched, I’ve noticed more team alignment, reduction in confusing/missing requirements, and an improvement in product quality.
Have you tried this framework yet? If you are working in an agile environment that embraces change, I highly encourage you to write a few Gherkin model stories. Let me know how it goes.
