User story Development

BDD Adoption - Taking time to get it right

Recently I've had the opportunity to speak with a broad range of Agile coaches and consultants who have consistently told me that they have not seen any organization successfully adopt BDD as part of their standard process of elaborating their User Stories. Luckily I have had the opportunity to work with several organizations that were able to successful adopt BDD and believe strongly in how this process can transform how you build and bake quality into your products.

I think most people hear the word BDD and they immediately think that it is an automation centric effort, though that is a great value add for BDD, leveraging BDD without automation can also lead to improved testing and quality.

Adopting BDD is so much more than automation (which I wrote about here) it's really about clearly defining the expected behavior of your system.

Why is this so important? Because as humans we all interact differently with the systems that we encounter.  As people who develop these systems we deliver based upon our experiences and understanding of the system we are building.

Language (Business Requirements) has been the manner and method that we have used to convey what we want a system to do to.  However with an international work force we don't all have a shared language.  In addition to this constraint we also interpret what we read differently based upon our primary language, life experiences and culture.  Given this, it's not surprising that when we build a system, it has many different interpretations attached to it, which negatively impacts both the functionality AND quality of our system.

BDD is a way to talk about how your system should behave not what it should do.  Yes we want our systems to have specific functions and features, but talking about how each of these will behave brings about a much richer conversation of what can happen in many functional situations the system and the people will encounter, not just the happy path.

There are two primary components of BDD:

  1. The Given/When/Then test setup
  2. The Example Table

Getting the first part of your BDD is the most important component because it defines the size and scope of what the User Story.  We do that by decomposing an individual user story into Test Scenarios.  One quick way to determine if your user story is perhaps to large or complicated is to evaluate the number of Test Scenarios you can define.  Keep your Test Scenarios to under 4 per each individual User Story so that you can more easily understand the expected behavior for that part of your feature or functionality.

Keeping the number of test scenarios small is also important once you translate your BDD into test automation which will keep your tests small so when something breaks it is much easier to find out where you need to address a fix.  Remember development teams should be consistently refactoring their code to improve code quality.  With high levels of automation we can quickly catch when refactoring unexpectedly changes the underlying behavior of our system.  This is where Quality is kept front and center in our organization.

The second part of building effective BDD is the Example table.  My training focuses on getting the first part clear and clean because the example table is an easier effort of filling in the expected results in each of your parameter columns.  As with the first section you can use the number of parameter columns as a means of determining if your test scenario is too large.  Try to keep the number of parameters to between 4-8, anymore will result in more brittle tests and more time debugging your automation code.

Adopting BDD as your primary means of decomposing stories may on the surface seem like a lot of work, but remember that you are only doing this level of detail for each 2 week sprint so the number of stories that you build out context driven BDD is relatively small.  Doing it every sprint means you get better at it every time and you will refine your ability to generate BDD much more quickly.

We should also remember that this is a TEAM oriented approach, don't relegate this to your QA team, you will miss getting all of the context needed to delivery high quality code and functionality.

BDD - Breaking down stories

One of the areas that many teams struggle with is getting user stories to the right level of context.  For me context IS everything in user stories.

 Yes a story is a placeholder for a conversation, but with large complex systems and organizations, the need to build out (and document) context has many benefits for teams and the organization.
Over the years I've seen some consistent elements fall out of BDD that can provide teams with an understanding of when a User Story may need to be broken down.
As you begin to build your test scenarios for your user story ensure that the story has no more than 3-4 scenarios.  If the number of scenarios is large, getting a clear contextual understanding of the story becomes much harder.  Additionally if automation is part of the equation then you end up with a larger code base for a single story and it can make trouble shooting failures harder.  Smaller stories mean less complicated acceptance criteria and more manageable and scalable automation code.
Once you have identified your test scenarios and begin writing the supporting BDD acceptance criteria look for some of these elements as queues to potentially break down your stories:
  1. Large set of parameters- If you see that you have more than 7-8 parameters in an individual test scenario consider breaking the test into additional scenario(s) or another story.  As I've taught my teams, if you see your example table stretching off the page you probably need to break it down.
  2. Large set of examples - If you see your test has more than 12-15 examples in an individual example table, you should consider breaking it down into additional scenario(s) or another story.
Keeping your stories and test examples small ensures that the team can more accurately estimate, deliver and demo their work consistently.
Teams should strive to break stories down so that they are small enough to be completed (Dev and Test) within 2-3 days.  This level of granularity provides clear visibility during Standups if the team is on track to deliver on their commitment.
Many teams suffer from what I call 'pushing a river down a creek' syndrome.  Meaning that they don't perform sufficient planning and story breakdown which leads them to continue to push their work out into future Sprints.  This leads to a lack of visibility as to when 'it will be done/delivered'
Breaking down stories effectively also leads teams to have stable velocities which leads to predictable delivery.  All of this feeds improved Program and Project management across the organization.
Organizations that need to scale Agile need to understand that this level of discipline isn't easy, but we shouldn't shy away from something just because it's hard.
BDD story breakdown leads to vastly improved feature definition, scalable automation suites and a strong automated regression.
Member Login
Welcome, (First Name)!

Forgot? Show
Log In
Enter Member Area
My Profile Not a member? Sign up. Log Out