When does BDD help a team and when does it get in the way?

BDD helps when:

• Business analysts, product owners, or stakeholders actively participate in writing and reviewing scenarios — the living documentation is actually read.
• Features have complex rules that benefit from concrete examples (pricing tiers, permissions, state machines).
• The team practices 3-amigos or Example Mapping before sprint work begins.
• Feature files serve as the contract between business intent and test coverage.

BDD hurts when (red flags):

• Step definitions are essentially code with a Gherkin wrapper — no one from the business ever reads them.
• Scenarios are written after the code is done, making them documentation of what was built rather than specifications of what should be built.
• The Gherkin layer adds 30+ minutes to framework setup for straightforward CRUD screens.
• Teams copy-paste step definitions or use overly generic steps that match anything, killing the specificity that makes BDD valuable.
• API or unit-level tests get forced into Gherkin — Gherkin is suited for business behaviour, not low-level technical assertions.

A pragmatic view: BDD is valuable for the conversation and collaboration it forces, regardless of the tooling. If the conversation happens but the team chooses to implement it as plain JUnit tests, the BDD value is still captured. If the team uses Cucumber without the conversation, they get the overhead without the benefit.