Dima Kolodko — The BDD process is a natural workflow, consisting of the sequence of (1) write story’s acceptance criteria; (2) write Gherkin test scenarios to cover the acceptance criteria — usually about 3–10 scenarios per acceptance criteria; (3) have someone (e.g., a test expert and/or business analyst and/or tech lead) review the test scenarios, to ensure that there are enough error paths and edge cases; (4) code tests that implement the test scenarios; and finally (5) code the story. Some of these steps can occur in parallel — e.g., steps 4&5 — but one thing one does not want is for step 5 to be done before, say, step 2 has even started: one does not want the programmer sitting and waiting for the test program to be ready.
This is somewhat of a fit for kanban, but not entirely: someone has to be watching what people are working on, and making sure that things will be ready at the right time. It is not a pull process.
I know that some in the BDD community claim a simpler process, where the PO writes the Ghrekin, etc., but that does not work IME in most cases. In most cases, the PO is a manager who has operational responsibilities, and so they just don’t have time to write Gherkin at the level of detail that is needed to achieve high coverage. Nor do they have the required test mindset to think of all the edge cases and error paths; and there are often technical edge cases as well. And by the way, programmers tend to write terrible BDD test scenarios — horribly insufficient. It takes someone with a test mindset.
The problem with Scrum is that in a Scrum process, a story is treated as a single blob of work, and people self-organize around it. If you try to do that with BDD, you will find that people are often waiting for tests. Also, starting a story on day one of a sprint means that none of the above steps 2–5 were done before the sprint started — but to make BDD work well, you have to sequence things. When I see people shove BDD into Scrum, I tend to see “dead time” when some people are writing Gherkin, and others are pretending to be busy. A similar thing happens toward the end of the sprint.
Please see my five-part article series in LinkedIn for how I have seen BDD work well.
