Probably one of the harder elements of Agile that teams struggle with is the art of collaboration. Our experiences over the years have taught us to treat functional groups such as BA's, Devs and QA as separate entities each with their own perspective and each distrustful of the others abilities to deliver. How many times in QA do we hear the phrase 'Just toss it over to QA and let them deal with it'.
We forget so easily that what we deliver for a customer is the sum total of our efforts, not just of individuals. The Chicago Bulls were a good team with just Michael Jordan, but only when they were able to blend ALL of the skills of the team were they able to win championships. Scrum is about team.
Getting your Scrum team to actually work as a team is one of the key efforts that everyone needs to make and BDD is a way that can help teams work collaboratively to build what I call contextually rich user stories.
You can't rely on just one or two people to write user stories and acceptance criteria as there is a limit to the context of what any one person can know. With ever growing complexity in business and technology the more people who can collaborate the more context that is captured in the story.
Does it sound like heavy overhead? It shouldn't. I'm sure you have all spent hours pouring over Business or Product Development documents trying to glean enough information to build a design that will work for the next 6 months (which we know doesn't happen on any planet in this solar system). We've always spent time trying to understand what is being asked for but in Agile we spend smaller increments of time on writing details that matter.
The most successful teams I've worked with have adopted this type of approach for building out BDD acceptance criteria:
- Start of Sprint -
- During the first two days of the Sprint the QA lead and Product Owner work together to develop (and or complete) BDD acceptance criteria for the next upcoming sprint.
- By day three the development team should start delivering stories to QA for testing. Additionally QA can begin their automation efforts via BDD examples with tools such as Cucumber, Fitnesse, Capybara....
- The engineering team needs to plan to complete all of the story development so that the last two days are open for them to review the acceptance criteria and make changes/suggestions to the PO. The team is also completing their designs for the upcoming sprint during the last two days and fixing any bugs that are discovered in testing.
The key to this process is that before the team commits to the sprint they must all review and agree to the scope of the BDD acceptance test examples. Without this discipline, the scope of the story and sprint will not be as precise.
As I've told my teams in the past, moving to writing BDD acceptance criteria is a mind shift in how you view both requirements and testing. Both Development and QA can consume them for their individual efforts, but in the end, if they work against what is defined in the BDD they will both be on the same page functionally.
BDD takes the guess work out of what is being developed and that's a good thing. For Sprints to go quickly and with high quality, teams have to understand exactly what they are doing. To steal from one of my favorite phrases from Bull Durham 'Don't think, it only hurts the ball club'.
BDD provides clarity for the entire team and makes demos go smoothly.
Ensuring that the team provides input, review and commitment to BDD acceptance criteria keeps everyone focused on doing just what is needed.