How We Use Gherkin to Deliver Better on Customer Expectations
A challenge for any development team is to deliver on the vision of the product owner—a vision based on customer input. We’ve all seen instances where deliverables fall short of achieving the intended result, which means customers are also being let down. How can this be avoided?
In Agile Development, it all comes down to the user stories—and within them, the acceptance criteria. Acceptance criteria can be written in many ways, and herein lies the problem: they can vary in format and specificity, creating miscommunications within teams as well as between teams and product owners.
Solving this communication issue is imperative for agile organizations to ensure they deliver worthy innovations to their customers. And as with any improvement to the development lifecycle, it can require implementing a new technology to facilitate a process improvement.
Improving Agile Development with Gherkin
As an example, what we’ve found in teams at Compuware is that using the Gherkin language can provide the uniformity and focus they may lack. Gherkin is all about behavior-driven development, which focuses on the specific behaviors you wish to achieve with changes without detailing how the behavior is implemented. Gherkin is based on a simple template:
Feature: a use case that describes a specific function of the software being tested
Scenario: a flow of events through the feature being described
Given: a context
When: a specific action is performed
Then: an expected result
To help you better understand the benefits of this, we’ll give you two perspectives: one from a product owner, one from a Scrum master.
Mark’s Experience as a Product Owner
As a product owner, you want to make sure that your vision is carried out by Development. You also want to have Development be as productive as possible, so you need to eliminate waste and inefficiencies.
Where Gherkin comes in is that it provides focus to really spell out what is needed in the enhancement you envision. As a product owner/product manager, I’ve found that it really forces me to walk through the user experience, and in so doing I’ve found problems.
It’s so much better to catch problems at an early stage before coding has begun. Laying out the desired behavior before refinement avoids misunderstandings.
Does it take me longer to do it this way? Honestly, yes; but only because I now take the time to really walk through the scenarios. While Gherkin gives a good definition of when the work is complete, the most important thing is that it enables the necessary conversation to get to the real problem that needs to be solved.
Matt’s Experience as a Scrum Master
Prior to using Gherkin, I saw that in backlog refinement meetings, we often found ourselves reviewing a story and continually asking questions like, “What if this happens?” or “How do we handle this situation?”
This could at times take up a large amount of the session and the team’s time. Phrasing stories in the “Given-When-Then” format with Gherkin helps us to think about some of those behaviors ahead of time so that we have better-defined requirements going into our backlog refinement.
You can also use Cucumber, a software tool for testing, together with Gherkin to automatically generate test outlines based on your story definitions. In this way, behavior-driven development is an extension of test-driven development. Your tests can be generated from your descriptions of how you want your application to behave. This gives the developers a starting point to create the tests that they will then go on to do their coding against, which in turn promotes better testing habits.
Combining these two things can lead to a much better outcome at the end of the Agile sprint. The team goes in with a much more clearly defined objective as well as producing code that is better tested with tests that are targeted at the key behaviors of the application.
Enable Your Agile Development Teams—Help Your Customers
If your agile development teams are struggling to deliver on the vision of your product owners, there’s a high likelihood what’s being delivered is also falling short of customer expectations.
Using the Gherkin format in your acceptance criteria will allow for uniform test cases with clearly defined outcomes. Using a common language across all stories, there will be agreement within your teams and the desired behaviors will be clearly understood.
This will help your agile development teams do a better job delivering on the visions of product managers—and the expectations of customers.
For more on what kinds of technologies you should be providing your agile development teams, check out our blog on 10 DevOps tools you need today.
Mark Schettenhelm and Matt Kramer
Latest posts by Mark Schettenhelm and Matt Kramer (see all)
- In Agile Sprint Planning, Less Is More - January 21, 2019
- Discovering the Value of Pride in Agile Sprint Reviews - June 14, 2018
- The Value of Combining Teams for Agile Sprint Reviews - May 22, 2018