A team that I am coaching has settled on using BDD stories and scenarios for describing their requirements and specifications. They’ve also chosen cucumber as their acceptance testing tool. All well and good, but they are making very slow progress and seem to be really struggling with the change in workstyle. I think I’ve spotted the reason for this.
The feedback loop is missing. They view the stories as a spec that has been handed down. And they have not made the connection that spec writing is design work that is intended to clearly illustrates concepts in a domain. It is a form of writing code. But it’s just that this code is, maybe, non-executable.
Here’s my workflow and how I close the loop.
- write story and scenario
- Sketch a design if needed – helps when pairing to be on the same page.
- Start writing test for scenario
- ooops … test is getting complicated? stuck?
- maybe the domain is not understood enough? Dig deeper, improve scenario, design (as needed) and continue writing test
- or maybe the scenario was badly written? Ignore scenario structure, continue writing test. Refactor scenario later. We’re in deep discovery mode here.
- get test to pass
- refactor code
- refactor scenario
- … cycle the red-green-refactor until happy.
Acknowledging when you’re in discovery mode and knowing that you are allowed to refactor requirements is the trick. Nothing is cast in concrete. That’s why I like frequent feedback loops with tight turning circles.
No feedback loop, no progress.
BTW, I really don’t like explaining such things as flow-charts and sequences. You got to find your own style. It’s not a recipe or rules thing. The above is something that is about as close to what I do but it changes when the need arises. That’s also another key feature of being agile – adapt or die in the waterfall.