Most Agile teams say they practise Behaviour-Driven Development. Fewer can clearly point to where the behaviour was actually agreed.
That usually comes down to discovery.
Discovery is the point where teams are supposed to align on what a system should do before development starts. It’s also the stage that quietly gets rushed, diluted, or pushed aside when delivery pressure kicks in. When that happens, BDD loses its value long before any scenarios are written.
This article looks at what discovery really involves in BDD, why it often breaks down in Jira-based teams, and why keeping discovery visible inside Jira makes a material difference.
Discovery Is About Agreement, Not Artefacts
Discovery in BDD is not about producing documentation. It’s about getting alignment.
Product owners, developers, and testers need to leave the conversation with the same understanding of how something should behave. That includes the obvious paths, the edge cases, and the things that should not happen. When that alignment exists, later stages of BDD tend to flow naturally.
When it doesn’t, teams spend the rest of the sprint revisiting decisions they thought had already been made.
Discovery is where those decisions should be surfaced and tested through examples, not deferred until testing or automation.
Where Discovery Commonly Goes Wrong
In practice, discovery often happens informally and leaves little trace.
Teams talk through behaviour in refinement sessions, agree things verbally, and move on. Acceptance criteria are written quickly, sometimes as a checklist, and scenarios are left for later. By the time development starts, the original intent has already started to blur.
Typical symptoms include:
-
Behaviour discussed but never captured clearly
-
Acceptance criteria that are open to interpretation
-
Examples living in documents or chat threads
-
Decisions lost once the Jira ticket moves forward
None of this is unusual. It’s what happens when discovery is treated as a conversation rather than a delivery activity that needs to persist.
Why Discovery Needs to Live in Jira
Jira is where work is tracked, prioritised, and delivered. When discovery outputs live outside Jira, they tend to be treated as secondary.
Keeping discovery inside Jira means:
-
Behaviour remains visible throughout delivery
-
Product owners can see what was actually agreed
-
Testers don’t inherit assumptions second-hand
-
Developers have clearer intent to work from
More importantly, it creates a single place where behaviour can be revisited when questions inevitably arise. That matters far more than producing perfectly worded artefacts.
Supporting Discovery Natively with AssertThat
AssertThat supports BDD discovery by allowing teams to capture and explore behaviour directly alongside Jira user stories.
Rather than pushing discovery into separate documents or tools, teams can:
-
Link features and scenarios directly to stories
-
Capture examples and expected behaviour as part of delivery
-
Keep discovery visible to everyone involved
This doesn’t force teams into a rigid process. It simply makes discovery harder to lose once it has happened.
Human-in-the-Loop Support During Discovery
AI can assist with discovery, but it cannot replace it.
In practice, AI may help by drafting initial examples or highlighting areas worth exploring based on similar behaviour. That can be useful, particularly when teams are short on time.
What it cannot do is decide what behaviour is correct. Discovery still relies on human judgement and discussion. Any AI-generated content needs to be reviewed, challenged, and validated by the team before it carries any weight.
Discovery remains a human-in-the-loop activity, regardless of tooling.
Why Discovery Sets the Direction for BDD
Teams often focus on scenarios and automation when talking about BDD. In reality, the quality of discovery determines how effective everything else will be.
When discovery is done well:
-
Scenarios are easier to write and review
-
Validation aligns more closely with intent
-
Automation supports behaviour rather than redefining it
When discovery is weak, later stages are spent compensating for missing clarity.
Final Thoughts
Discovery is where BDD either earns its value or quietly fails.
Treating discovery as a deliberate activity, keeping it visible in Jira, and ensuring that behaviour is agreed before delivery begins creates a much stronger foundation for everything that follows. It reduces rework, limits ambiguity, and makes BDD feel purposeful rather than performative.
