This is the second part of my original where to start with BDD post, which can be found here: https://thoughtsontest.wordpress.com/2017/03/22/where-to-start/
Alright so now our team is a bit more collaborative. We have a multifunctional team, with some developers, a tester and a BA. We are also visualizing our work, and limiting it so there is work being finished and not just started. Now we are in a position to introduce BDD.
So at this point we should have some form of KanBan board. Work starts in the “To Do” lane and continues to the “In Progress” lane. Something interesting to think about, are there many bugs being found in the testing lane? In the last post I talked about developers not picking up new work until all the bugs found in the testing lane are fixed. But how can we try to prevent those bugs in the first place?
This is where BDD fits in nicely. For those that don’t know, it stands for behaviour driven development. I have previously talked about what it is and why I love it. It allows for a conversation before any code is written. Personally I have found most bugs come from missing or misunderstood requirements. So if we can agree on acceptance criteria together then there will be less confusion in requirements and less bugs.
The easiest way to start is by adding a new lane to your board. After “To Do” and before “In Progress” add “Discuss”. So what happens in this new lane? The answer is simply a conversation. This is where the 3 amigos fit in. A tester, a business analyst and the developer who has just picked up the story. The most important aspect of BDD is this conversation. We can now talk about the requirements, and the expected behaviour of the software. This conversation should remove confusion in what the value of the story is.
This is easier if we just start with a user story and no acceptance criteria. The AC will be written as a group. Each person will bring their own unique viewpoint, if there is already acceptance criteria then confirmation bias can make us miss something. As it is easier to just not think and accept was is already written down.
What I have found works is specification by example. So start by trying to capture the behaviour using examples. John Ferguson Smart recently ran a workshop in which he talked about example mapping. I loved it and his ideas can be found here: https://johnfergusonsmart.com/feature-mapping-a-simpler-path-from-stories-to-executable-acceptance-criteria/
Using examples can also be a great judge of story size. Usually if there are more than 4 examples I recommend splitting the story. Keeping stories nice and small reduces complexity and helps get fast feedback as they take less time to get to the customer.
BOOM we now have examples. Now its time to add a new lane, call it “Distil”. This is where we turn our examples into automatable acceptance criteria. The examples become “Given, When, Then” steps. These can then be automated as failing tests. The story can then progress into the development lane and can be started on.
To make this a little more clear, in my next post, I am going to go through a practice story.
So like Led Zeppelin famously sung we don’t want any “communication breakdown” driving us insane. Give this a try and let me know how you get on.