In our book Discover to Deliver: Agile Product Planning and Analysis we discuss the usefulness of the “Given-When-Then” technique to explore (discover) and confirm (validate) product options. Here we summarize the technique*, brainchild of Dan North.
What it Is
Given-When-Then (GWT) is a structured format for expressing scenarios with example data, including pre- and post-conditions.
GWT helps project stakeholders (business, customer and technology partners) communicate using business domain language. You can use GWT to explore product options and confirm selected options in a concrete, tangible way. Often called “specification by example,” GWT provides living documentation for your delivered product. It simultaneously specifies requirements while identifying acceptance tests, thereby streamlining discovery and delivery.
What You Need to Know
GWT pulls together the four functional dimensions of the 7 Product Dimensions: User, Action, Data, and Control (business rules). (For more on the 7 Product Dimensions, see our book Discover to Deliver, at the end of this Tip.)
Here’s how GWT works. For a specific story, scenario and business rule, you analyze three things, asking and answering these questions:
Given: What is the context of the system? What pre-condition must be true before the action is tested? What data is in the system?
When: What will be tested? What input data will be tested via the business rule when the action occurs?
Then: In response to the action, what is the observable outcome? What are the expected results? What is the post-condition (state) or output data observable by the user?
Stakeholders need efficient, precise ways to confirm requirements. The Given-When-Then structure guides the product partners as they define real examples to clarify requirements. That’s not all. You can also use the GWT format as a way to explore product options—taking a bottom up, concrete-first approach to elicit requirements.
Along the way the product partners learn from each other and often uncover incomplete, ambiguous, and misunderstood requirements—especially business rules and detailed data requirements.
We use GWTs in agile facilitated sessions. The product partners explore and evaluate product options and then confirm their understanding of requirements by defining GWTs for high-value scenarios. Sometimes we collaborate with a subset of the partners to define GWTs as pre-work for a work session. Then during the session, we dig into complex and edge cases.
Why not test the validity of your requirements before delivery? GWT allows you to avoid unpleasant surprises from post-delivery validation, or worse—finding out you delivered the wrong solution.
GWT is a way to validate your requirements—before the solution is delivered. Because the examples you use with GWT are “real,” they resonate with end users (or their surrogates). You test the acceptability of your requirements during discovery and before final delivery.
GWT in a Nutshell
You’ll find that Given-When-Then will help you save time, avoid costly rework, reduce requirements errors, and promote an atmosphere of joint responsibility (customer, business, and technology) for specifying detailed requirements.
Even if you aren’t using a software tool (see Note 3, below) to specify your requirements with GWT, or are not using agile practices, you can use GTW to enrich and structure your conversations.
You can also use data examples in a table to define inputs and outputs for a scenario (see Gottesdiener and Gorman, 2012).
Some teams we work with streamline the GWT format to create matrices for multiple examples with columns, rather than rows, for GWT elements with each row representing a single example. These matrices are built in collaboration with customers and become acceptance test cases (depending on testing platform).
In Sum: Doing Double Duty
All product partners benefit when we use efficient discovery practices to optimize each delivery. Given-When-Then does double duty: it allows us to both discover (explore) and validate (confirm).
Discovery is generative, innovative and open-ended. Scenarios (a key element for GWT) are exploratory, seeing what is possible.
When we confirm, we make sure the right product will be correctly delivered (known, respectively, as validation and verification in classic requirements engineering). The concrete examples we use in GWT serve to both validate and verify we’re delivering the next most important product options.
Try this powerful “two-for-one” technique in your structured conversations—soon.
* A shorter version of this blog post was published as an IIBA (International Association of Business Analysis) November 2012 Quick Tip.
- GWT began as a Behavior-Driven Development (BDD), from Dan North. Other names include: Acceptance Test Driven Development (ATDD) and Specification by Example (SbE).
- For more, see the Agile Extension to the BABOK® Guide, “Get Real Using Examples.”
- Tools that generate acceptance testing using GWT: Cucumber, Easyb, Robot, RSpec, Jbehave and more. For data table driven acceptance testing, check out FIT or FITness.
- For those of you familiar with the IIBA’s Business Analysis Body of Knowledge™ (BABOK): don’t assume that the Solution Assessment and Validation knowledge area tasks kick in only after your solution is delivered. Validating your solution before delivering it let’s you acquire knowledge that can help you eliminate waste and accelerate value, by learning what not to build.
For more information
Adzic, Gojko, Specification by Example: How Successful Teams Deliver the Right Software. Manning Publications, 2011.
Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis, EBG Consulting, 2012.
Matts, Chris, and Gojko Adzic. “Feature Injections: Three Steps to Success.” Available here.
North, Dan. “Introducing BDD.” Available here.Topics: Agile, Agile Business Analysis, Agile Business Analyst, Agile Workshops, Analysis, Business Analysis, Business Value, collaboration, Communication Skills, Discover to Deliver, Documentation, Elicitation, ellen gottesdiener, Facilitation, mary gorman, Product Partnership, requirements, Requirements Management, Scenarios, Specification by Example, Stakeholder Analysis, Structured Conversation
Tags: Agile, Agile Business Analysis, agile requirements, Documentation, product needs, Product Partnership, Product stakeholders, requirements, Requirements Management, Scenarios, Specification by Example, Stakeholder Analysis, Stakeholders, Structured Conversation