Learning Objectives
By the end of this lesson you will be able to:
- Place BDD activities correctly on a typical SDLC timeline
- Explain why writing scenarios before development starts changes outcomes
- Recognize the anti-pattern of writing Gherkin scenarios only after a feature ships
Before Code Exists
The highest-value moment for a Gherkin scenario is before a single line of code is written. During refinement or grooming, the three amigos turn a vague requirement into concrete examples: "what happens with a $0 order?", "what if the discount code is expired?" Each answer becomes a scenario. Ambiguities that would otherwise surface as bugs three weeks later get resolved in a 20-minute conversation instead.
This is the single biggest reason BDD outperforms writing tests after the fact — the scenarios shape the implementation, rather than merely checking it afterward.
During Development
As developers implement the feature, the scenarios act as an acceptance checklist they can self-verify against, without waiting for QA to write test cases from scratch. A developer who reads "Given an expired discount code, When applied, Then the system rejects it with a clear error" knows exactly what edge case to handle — no guessing, no re-reading the original ticket for buried details.
During QA and Review
QA doesn't start from zero either. The scenarios already exist; the job becomes execution, exploration around the scenarios' edges, and confirming nothing was missed — rather than reverse-engineering test cases from a finished feature.
The Anti-Pattern: Scenarios Written After the Fact
Some teams write Gherkin scenarios after a feature ships, purely to "have documentation." This captures none of the collaborative value — the conversation that would have caught ambiguity never happened, because the feature was already built by the time anyone wrote a scenario. What's left is a description of whatever got shipped, bugs included, dressed up as if it were intentional.
A Simple Timeline
Requirement drafted → Three Amigos conversation → Scenarios written
→ Development (scenarios guide implementation)
→ QA execution / exploration
→ Scenarios remain as Living Documentation post-release
Pro Tip: If your team currently writes acceptance criteria during refinement, you already have the right timing — the only change is writing those criteria as Given/When/Then examples instead of a bulleted checklist.
Key Takeaways
- Scenarios deliver the most value when written before development starts, during refinement
- They give developers a self-check and QA a starting point instead of a blank page
- Writing scenarios after a feature ships loses the collaborative, ambiguity-catching benefit
- The right timing usually already exists in your process — it's the format that needs to shift to Given/When/Then