Using “Given-When-Then” to Discover and Validate Requirements
By Mary Gorman and Ellen Gottesdiener
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.
Usefulness
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?
Example
Collaborative Discovery
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.
Timely Validation
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.
Alternative Techniques
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.
Notes:
- 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.
I am trying to see how this is different (better?) than a use case. I know getting a good example for a technique is hard, but the rule in the example certainly implies a variation and an additional item for the “Then”.
Thanks for your question David.
GWT specifies a discrete test for a scenario. That scenario is associated with a story, providing context for the very discrete test. From a validation perspective, each scenario in scope for your current delivery cycle will align to objectives and values for the product.
Use cases are at a much higher level of granularity than GWT. You can choose to have use cases serve as your anchor for a set of GWTs….once you have narrowed the many possible scenarios possible for your use cases.
For agile projects, where you work in small batches and focus on delivering high-value chunks of the product as quickly as possible, a typical use case is “too big” for what we call the Now-View (current iteration or work-in-progress). We want to work on very small, well-defined slices of the product. This is not to say you can’t start with a use case, just be sure to explore its scenarios and slice those scenario options to the highest value ones.
GWT can be valuable to any project, regardless of method or favorite user requirements model (e.g., stories or use cases). GWT ‘makes it real’ and helps you both elicit and valid your requirements and deepens conversations about the customer, business and technology stakeholders.
And yes! The rule indeed is a variation (using use case terminology). Each use case variation and exception would need its own GWT – testing each discrete business rule.
I love this as an elicitation / validation tool.
When we’re interviewing stakeholders, without this tool, we’re really presented with two options – (a) force them to think in terms of our artifacts, or (b) have an unstructured conversation and hope we catch everything.
In a way, it is a Rosetta stone that allows the stakeholders to think critically (the way we need them to) without asking them to learn the language of the artifacts we turn around and deliver to developers and testers.
To David’s point – I wouldn’t use this as the container for my requirements, I’d keep those as use cases or stories (and diagrams where appropriate), when communicating with the implementation team. I’d only use GWT to validate what I think I already know – and I wouldn’t exhaustively walk through everything with this technique, only when I felt there was significant risk that what I understood was incorrect (I’m still learning, one or more of the G,W,T is complex or nuanced, the cost of being wrong is high, etc).
Admin (Ellen, Mary, whomever 🙂 – I’ve been effectively doing this with a “poor man’s state transition diagram” on the whiteboard in my conversations. Essentially, this feels like articulating the transitions in a state machine. The “use a real example” technique is one of the best ways I’ve found to validate – and PARTICULARLY to uncover nuances and hidden rules / requirements – requirements and rules that embody policy.
This GWT container (in prose) helps with requirements correctness, but doesn’t help me with completeness (other than the discovery that comes from the conversation) – which is where drawing the diagram helps me. Showing decision tables (truth tables, essentially) and decision trees helps with that.
Have you explored other containers / visualizations of the GWT information? The presentation in this article is definitely discrete and effective (for a single GWT). I wonder if some other visual / layout might be more engaging during a session, and possibly help bring the stakeholders into the “completeness” part of the validation. Basically something halfway between the structure above and the ad-hoc / spatial approach I’ve used.
Scott and all,
Completeness for a given scope is a major issue, it is one of the main benefits I and my colleagues provide to clients.
I also should have been more precise, and referred to a “business” use case, or a “business activity” that is described using a use case format. We find this artifact works well with business people. You have pre-conditions and triggers, a stated goal/post-condition, and one or more paths using information to reach (or not reach) that goal. And we ensure completeness by first discovering the activities within the context of an overall process, and by capturing every alternate path within an activity.
So when I look at GWT (hopefully without blinders on), I see a business use case without the steps/paths. … And that’s OK, I believe projects should use the techniques they need that lead to success, I just want to understand a new one when I see it, to see if it would be a useful addition to the ones I am already using I am not sure how it might fit into the kind of elicitation I do, but validation techniques after elicitation are always handy to have available.
Scott, thanks for your feedback.
Glad you find GWT a powerful tool as well!
And yes! Indeed, we find state diagrams and decision tables or trees powerful, both to elicit and confirm requirements. (Examples of all three are in our new book, Discover to Deliver). We have found that structured conversations incorporating state diagrams (lightweight, tested with scenarios) always yield new knowledge about actions, data and business rules.
You make an important point about selectively using GWTs. It’s quality over quantity – you don’t want to be awash in GWTs and waste time defining lots of acceptance tests for simple, clearly understood requirements. GWT are especially valuable when analyzing risky and complex requirements.
As far as “visualizations” of the GWT information, in particular the pre- and post-conditions, we use a state diagram, business process diagram, dependency diagram, or a story map.
And for containers of GWT information something we found that works well, that is business friendly, and accelerates validation conversations is to organize GWT in a table (with columns for each element: Given, When Then) so that each test is a row with sub-rows for compound GWTs. Some teams we work use one of the ATDD/BDD tools as part of elicitation so they can seamlessly link to automated testing.
~ ellen and mary
Hi David:
Thanks for your clarification.
Yes, we agree that each project needs to intentionally select techniques that lead to success! To that end, we created an “action meta model” to visualize the options for defining business activity and their possible relationships. (In our new book Discover To Deliver, we include meta models for each of the 7 Product Dimensions.) As part of the team’s planning, they select a set of appropriate action options.
As noted in the meta model, a scenario may be related to any action – from process down through story. That said, we find that GWT is typically used to validate a scenario of a story.
BTW, when appropriate, we use pre- and post-conditions for any of the action options.
~ ellen and mary
Thanks, Ellen and Mary!
In the diagram in your reply to David, if I remember from reading Discover to Deliver, we’re on the same conceptual page but use slightly different jargon. I think of a capability (help me do my taxes) as having use cases / stories (I want to get credit for all my deductions), which drives having requirements (ability to enter a mortgage deduction, or depreciation, etc). And I think of features as a description of the product (organizes deductions for filing via the proper form, accounts for income-level phase-out of deductions, etc). As long as I map my conception of “capability” to the place in the object model that you label as “feature” then we’re all good. 🙂
Hello Scott:
Ah, “capability”! 😉
One person’s capability is another’s feature, process, MMF, activity, use case, story….
Context, culture, chief work activities, education, and reading background all influence how a concept is understood and used.
Indeed, Scott, we’ve grappled with reconciling various definitions, interpretations and relationships for these requirements-related concepts. For that reason, we use industry-standard terms and well-known publications (e.g., IEEE, ISO, and published book terminology, Ellen’s Software Requirements Memory Jogger and Karl Wiegers’ S/W Requirements books). And that’s also the reason we developed the meta models and Glossary (along with examples) in Discover to Deliver.
In the Discover To Deliver‘s Glossary, after much research and testing with examples, we define capability as “the ability to do something”.
Depending on your perspective, that could be used for many levels within a hierarchy of Action options. We define a feature as “a cohesive bundle of externally visible functionality that aligns with business goals and objectives”.
Using your examples, Scott, (in lieu of definitions), we would map your use of “capability” to our “feature”.
Bests,
~ ellen and mary
[…] https://www.ebgconsulting.com/blog/using-given-when-then-to-discover-and-validate-requirements-2/ […]
Thanks for your article and reference to our blog post.
[…] acceptance criteria. Cucumber, FitNesse, and other automation tools, many of which employ the Given-When-Then structure, can help create executable […]