Speclr Logo

Shift-Left with BDD: The Full Journey

Most teams try BDD and drop it. Not because it doesn't work - because they started in the middle. This course follows one feature from first conversation to production - twice. Same team, same codebase, same deadline. Once without BDD, once with. You'll see exactly where the two paths split, what each decision costs, and why the gap between them isn't about testing - it's about when your team starts talking to each other. By the end, you'll know how to run the conversation that makes the rest of the work cheaper.

Jonas
intermediate
12 Modules
223 min read
33 Exercises
Behavior-Driven DevelopmentRequirements EngineeringAgile
Shift-Left with BDD: The Full Journey
Practitioner courses for individuals and teams that build better software. Simple pricing, no surprises.
Billed AnnuallySave up to 44%

Solo

Perfect for individual learners.

Save $240 with annual - 5 months free

  • Start learning with
  • Access to all current courses
  • Hands-on exercises with real-time feedback
  • Free updates and access to new courses
  • Progress tracking per lesson

Team

For teams learning together.

Save $744 vs. 5 solo annual licenses

  • Everything in Solo +
  • Up to 5 team members
  • Shared team experience
  • Progress overview for all members
Module 0
18 min read

Meet Fieldr: The Team That Ships and Still Fails

This module introduces Fieldr - a B2B SaaS product under delivery pressure - and follows three consecutive sprint failures, all tracing back to one root cause: the team never reached explicit shared agreement on what they were building before they started. Through three lessons you will recognize the Semantic Gap pattern (same ticket, different concepts in every reader's head), the Invisible Decision pattern (a spec gap filled alone under time pressure, with no one else knowing), and the Silent Dependency pattern (finished, signed-off work breaking because an implicit coupling was never made explicit).

The Story That Looked Clear

You can identify the specific moment where "done" and "done correctly" diverge, and explain why a well-written ticket and green tests don't guarantee shared meaning.

The Decision Nobody Logged

You can recognize the "invisible decision" pattern: the moment a spec gap gets filled alone, under pressure, without anyone else knowing it happened.

The Feature That Broke What Was Already Done

You can name the concrete cost of implicit assumptions - broken work that was already finished - and explain why no amount of individual discipline prevents it.

Module 1
15 min read
2 exercises

BDD Is Not What You Think

This module explains how that happens. It traces how a collaboration tool became a testing framework, why each role maps BDD to its own most familiar pain, and why the market has decided the conversation layer (the part that would have prevented Fieldr's sprint failures) is not what gets taught. Then: three behavioral signals that tell you which version of BDD a team is actually practicing, before a single line of code exists. By the end, you can name the difference and spot it in a running sprint.

The Tool That Ate the Practice
What BDD Was Actually Designed to Solve

You can explain the original intent of BDD in terms of the specific problem it was designed to solve - and articulate why a scenario is a commitment record, not a test script.

Recognizing Which BDD Your Team Is Doing

You can assess whether a team is practicing communication-process BDD or testing-tool BDD by observing specific, visible behaviors - before a single line of code is written.

Module 2
20 min read
3 exercises

The Three Amigos: Before Anyone Writes a Line

This module runs through three attempts at the same session. The first one misses the perspective that costs. The second changes when Tom drops the acceptance-criteria framing and asks for a concrete example instead: name a dispatcher, name the jobs, walk me through it. The room starts finding things the bullet points had been hiding. The third session shows what prepared looks like, and why it shifts what the conversation turns up, not just how fast it moves. By the end you can read a Three Amigos attendee list and know what's missing, steer a session toward concrete situations when it drifts abstract, and think through what each role should bring before anyone sits down.

Who Belongs in the Room

You can identify which perspectives are required for a Three Amigos conversation on a specific story - and explain what goes missing when any one of them is absent.

Speaking the Language of Examples

You can reframe a Three Amigos conversation from "what are the acceptance criteria?" to "give me a concrete example" - and explain why the second question surfaces shared understanding that the first one systematically misses.

What Each Amigo Brings

You can prepare a Three Amigos session so that each perspective contributes its most valuable input from the start - and explain why an unprepared session produces the examples in the room's short-term memory, not the examples that matter most.

Module 3
21 min read
3 exercises

Example Mapping: From Conversation to Structure

This module introduces Example Mapping - Matt Wynne's four-card structure for making gaps visible rather than leaving them to chance. By the end, you can build a complete map for a concrete story, use red cards to park genuine open questions instead of closing them with assumptions, and read the finished map against three criteria to decide whether it's ready for Gherkin.

The Map, Not the Conversation

You can explain why unstructured example generation produces diminishing returns - and use the four-card structure of Example Mapping to make missing examples structurally visible rather than discoverable by chance.

Red Cards Are Not Blockers

You can identify which open questions in a discovery session must be parked as red cards - and explain why answering them immediately with in-room information produces invisible decisions rather than traceable ones.

Ready for Gherkin? Reading the Map

You can assess a completed Example Map against three concrete readiness criteria - and give a clear Ready-for-Gherkin verdict with the reasoning that makes it actionable.

Module 4
16 min read
3 exercises

The Shift-Left Argument: What's Real, What's Folklore

Alex looks at the clock after the first complete Example Mapping session: forty minutes per story, eight stories in the sprint. That's five-plus hours before a line of code gets written. Tom's question goes into the team channel: "Is this actually worth it?" This module answers that directly. The 100x defect cost claim traces to a 1981 IBM training document that cites nothing verifiable. The Menzies 2016 study found no consistent delayed-issue effect in modern software projects. You come out of this module able to make the practitioner case in an architecture review without citing anything that collapses when someone Googles the source.

The Number Tom Found

You can trace common shift-left cost claims to their sources and classify each as defensible with evidence, directionally sound but unverified as stated, or folklore - so you know which parts of the argument to keep and which to replace.

What the Research Actually Shows

You can summarize what the shift-left cost research actually shows - Boehm's real findings, Bossavit's critique of the sources, and the Menzies 2016 empirical result - accurately enough to use the summary in front of a skeptical senior engineer.

The Argument That Holds

You can make the honest practitioner case for BDD as a shift-left practice - without invented cost multipliers, grounded in the Verification vs. Validation distinction, and anchored in your own team's evidence rather than in a figure you can't source.

Module 5
20 min read
3 exercises

Formulation: From Examples to Gherkin

Tom has the Bulk Assignment Example Map on his laptop. Thumb vote: passed. He opens VS Code, types urgency_filter.feature, and the cursor blinks. The map is done. The Feature File hasn't started. This module covers that gap: translating a completed Example Map into Given-When-Then scenarios, what each keyword is for, and the two anti-patterns that show up in every first draft. UI coupling ties scenarios to screen elements that change when the interface changes, not when the behavior changes. Compound Whens stack multiple actions into one scenario; when it fails, you can't tell which behavior broke. You end the module with the Urgency Filter Feature File v1.0 - three declarative, structurally sound scenarios.

When to Put Down the Cards

You can translate a completed Example Map into a first draft of Given-When-Then scenarios - and explain why Formulation starts with the map, not with a blank Feature File.

The Scenario That Describes a Clickpath

You can identify UI-coupled Gherkin and rewrite it at the behavior level - and explain why UI coupling is the fastest way to turn living documentation into a maintenance burden.

One When. One Behavior. One Scenario.

You can identify GWT structural misuse - compound Whens, process-based Thens, behaviors that don't belong in the same scenario - and produce the correct split without losing any of the original behavioral coverage.

Module 6
15 min read
3 exercises

Writing Scenarios That Mean Something

The Urgency Filter Feature File v1.0 arrives with seven scenarios and a quiet problem: three of the titles use capability language. "Dispatcher can filter" is a capability claim - it describes what the system is able to do, not what it will do. That distinction matters when a stakeholder in a sprint review asks what shipped. Lesson 6.1 fixes the titles and gives you a diagnostic for every scenario title you write. Lesson 6.2 applies Scenario Outline to the SLA threshold classification rule - and explains why the "unclassified" edge case belongs in its own scenario, not a table row. Lesson 6.3 runs a nine-criteria quality checklist across the finished Feature File. One scenario gets red-carded for a follow-up conversation. By the end, you have a checked Feature File and a reusable checklist your team can apply to any Feature File before it travels.

The Scenario That Speaks for Itself

You can identify capability language in scenario titles and rewrite it as a declarative behavioral commitment - so that a non-technical stakeholder can read the title and know exactly what behavior is guaranteed.

What a Table Is For

You can apply Scenario Outline to parameterize data variation within a single behavioral rule - and identify when scenarios should stay separate because they represent different rules, not different data.

The Three Jobs Every Scenario Has

You can evaluate a scenario against three simultaneous criteria - communication artifact, Definition of Done, and regression protection - and produce the Scenario Quality Checklist as a reusable artefact for your team's Feature File reviews.

Module 7
12 min read
3 exercises

Shifting Left for Real: QA in the Room

Maya asking failure-path questions in sprint planning, before anyone opens VS Code — that's what shift-left looks like when it's actually working. Lesson 7.1 follows her into the room: five questions that the developer's task breakdown hadn't modeled, and the cost difference between hearing them on day one versus finding them in sprint review. Lesson 7.2 is about a distinction worth taking seriously. A scenario written before the code is a contract. Written after, it's documentation of decisions already made — accurate, probably consistent with the implementation, and contractually worthless. Both artifacts look the same in a Feature File. They don't produce the same results. Lesson 7.3 maps what changed in the Fieldr sprint after all of this clicked: same ten days, different ordering of specification, implementation, and verification. It also covers the specific way teams get this wrong — they schedule the Three Amigos session, write the scenarios, and still find four issues late, because the session was a process step, not a conversation.

The Perspective Nobody Else Has

You can explain why QA involvement before design starts is structurally different from QA review after code is written - and identify the failure paths a developer perspective alone won't surface.

The Contract Before the Work

You can run a Three-Amigos session that produces a scenario-first Feature File - and explain why writing scenarios before code is the only ordering that delivers the contract benefit of BDD.

How the Sprint Changed

You can map the before/after cadence of a sprint that has genuinely shifted left - and produce the Sprint Cadence Shift Map as a reusable artifact for showing stakeholders what changed and why.

Module 8
17 min read
3 exercises

Automation Without Losing the Plot

Tom generates the first empty step definition stubs for the Job Reassignment scenarios and immediately asks Maya the wrong question. Lesson 8.1 is about that gap: who owns which translation decision, where UI knowledge belongs, and why putting element IDs in step definitions is always the wrong call. Lesson 8.2 follows the mistake Tom makes anyway. Everything inline, element IDs in every step method. One UI rename breaks five places. Thin steps and a driver class fix it. The next rename is one change, not a Tuesday afternoon. Lesson 8.3 is what happens after all three scenarios go green and Priya opens the Serenity report. Green is not done. The report is a direct record of the decisions made upstream in Formulation and in the step definition layer. The Living Documentation Assessment Checklist gives you five questions to ask before month eight, when the suite is too large to fix without pain.

The Translation Layer

You can identify which decisions in a BDD step definition require technical translation - and explain why those decisions are Tom's to make, not Maya's.

Thin Steps

You can refactor a fat step definition suite into thin steps backed by a driver layer - and predict exactly what breaks when the UI changes, and why.

Green Is Not Done

You can apply the Living Documentation Assessment Checklist to a BDD automation stack and determine whether it produces readable living documentation or green technical noise - and identify the specific decisions that determine which.

Module 9
19 min read
3 exercises

BDD Anti-Patterns: How Good Teams Still Fail

Tom searches Slack for the Urgency Filter thread from three months ago. He finds the red card, Priya's "I'll check with ops" reply, and nothing after. Lesson 9.1 names what he found: two failure modes - Oral Decision and Orphaned Red Card - that start at different points in the pipeline but produce the same symptom. Lesson 9.2 is a catalog. Five collaboration-layer anti-patterns: BDD Theater, Solo Authorship, Oral Decision, Orphaned Red Card, Scenario Rot. Each has a pipeline position, recognition signals, and a root cause. Two patterns from Module 05 look similar but live in the formulation layer - the catalog draws that line. Lesson 9.3 fixes the one the team found. They write the missing scenario now, with Deepa in the room. The Anti-Pattern Triage Guide gives the diagnostic a structure: three questions that name the active pattern and point to the minimum intervention.

The Trace

You can identify the specific point in the BDD pipeline where a decision failed to become an artifact - and name it as a pattern rather than as a team failure.

The Catalog

You can identify which of the five BDD collaboration-layer anti-patterns is active in a given feature file or sprint history - and trace each one back to its specific failure point in the BDD pipeline.

The Minimum Intervention

You can apply the Anti-Pattern Triage Guide to a live feature file, identify the active pattern, and determine the minimum intervention required - without rebuilding the BDD suite.

Module 10
19 min read
3 exercises

Living Documentation: Earning It

Deepa has been on the team for four weeks. She opens the Serenity report: forty-seven scenarios, twelve feature files. Twenty minutes later she messages Tom - she can't find Job Reassignment. Tom navigates the suite himself and realizes he hasn't opened most of these files in months. Not because they were wrong. Because nobody was reading them. Lesson 10.1 names what happened: Feature File Explosion, the structural consequence of accumulation without curation. Every scenario added was a correct decision at the time. The aggregate is a problem nobody scheduled. Lesson 10.2 follows Tom onboarding Mihail. A step reads "When the technician status update is received." Tom knows what it means. He opens the codebase - the method is processTechnicianEventCallback. He checks Slack - Priya called it "going offline." Three names, one concept. Jonas makes the case: when scenario vocabulary matches domain vocabulary, it becomes the only place in a software project where business language and code actually use the same words. Not by convention. Because that's the thing everyone reads. Lesson 10.3 designs the maintenance system. The urgency threshold changed - the scenarios still show the old value, still green. Nobody flagged it. The fix is fast. The system to prevent it happening again is not. Ownership, trigger, cadence, vocabulary review - five decisions most teams never explicitly make. This lesson makes them explicit.

Two Thousand Scenarios and Nobody Reads Them

You can identify the structural signature of Feature File Explosion in an existing scenario suite - and reorganize the file structure on a feature-based principle that makes the suite navigable without rebuilding any scenario.

Written for the Runner, Not the Reader

You can identify Runner Vocabulary in an existing scenario suite - language that passes the Outsider Test but connects to neither the business vocabulary nor the codebase - and rewrite it in the domain language the business actually uses.

Earning It: The Maintenance System

You can design a Living Documentation Maintenance System for a real team - specifying ownership, triggers, cadence, vocabulary review cadence, and organization principle - as a complete, deployable system rather than a set of good intentions.

Module 11
31 min read
4 exercises

BDD as Source of Truth: Sprints, Milestones, Promises

Sprint Planning Monday. Alex is carrying a debt from last week. The AM asked which features were actually committed. Alex said "accurate documentation." He didn't name anything. He knows it. Priya has twelve stories on the board. Tom asks something he has never asked in ten sprints: "Which of these are we actually committing to?" Alex picks up a marker. Two columns. Scenario-ready. Not scenario-ready. Six stories have Feature Files - green in Serenity. The others have AC bullets, a Slack thread, good intentions. "These six," he says. "The others, we can intend to do them. We can try. We can't commit." Three days in, a Slack message: the AM wants a mobile notification toggle. Two days max. Tom opens the scenario suite. No results. "Show me the scenario." There isn't one. "Then it's not in scope. We committed to what's in the suite." Thirty seconds. In the old Fieldr, that conversation ran three days. Lesson 11.3 is where the team stops improvising governance. Jonas names four categories - scope, implementation, architecture and non-functional requirements, scenario change - and tells you who owns each one. He is direct: this is his recommendation from watching teams lose sprints to invisible decision-making. Not a BDD rule. A choice you make on purpose, because the alternative is whoever argues longest wins. Six sprints: 62%, 68%, 71%. Then 83%, 87%, 91%. The turn happens in Sprint 4 - the first sprint where every committed story had a scenario. Jonas closes the loop on the three Module 00 symptoms: what caused each one, and what fixed it. The Urgency Filter Feature File is on screen. Scenario 3. Green. Alex sends the Customer Promise Document. The ops lead opens the link. It wasn't the testing that made the difference. It was the conversation before.

Scenario-Ready or Not

You can assess each story in a sprint backlog for scenario-readiness and translate scenario-ready features into a one-sentence benefit statement that communicates the same commitment in stakeholder language.

Scope That Can't Creep

You can express a software release as a versioned scenario set — and demonstrate why scope that is invisible in a feature list becomes a nameable, visible event the moment it's expressed in scenarios.

Who Owns the Scenario

You can classify any decision that arises during a sprint into the correct ownership category — scope, implementation, architecture, or scenario change — apply the right process for each, and explain why a running scenario can only be amended through Three Amigos, not corrected in place.

Back to the Beginning

You can trace a team's improvement in delivery reliability back to specific BDD practices — and articulate why each of the three failure patterns from Module 00 has a structural answer in the BDD process this course has built.