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.

Baking In Quality with Agile

One of the things that I love about Agile and especially the related techniques of BDD and Test Automation is that if done correctly your teams are essentially baking Quality into your products AS they develop, not after. Traditional SDLC (read waterfall) took a very linear approach to project delivery which in turn translated into a similar approach to how we developed and delivered our software products.

In our traditional delivery methods, quality was not 'baked' in but tested out and we never ever got to the point where we are able to test out all of the 'defects' that are found, instead we create a bug database where 'bugs' go to die.  Every organization typically has some form of a bug database with bugs that were 'found' sometimes years ago and were never fixed (of course begging the question were they ever bugs in the first place?)  In Agile we really don't want to see a bug database because we should be instilling a zero defect policy for each sprint, meaning that we should never be introducing new tech debt into our product.

As I progressed on my Agile journey I came to realize that there are actually two types of 'bugs' that we encounter when we develop software:

1. Bugs as Missed or Undefined Requirements
2. Bugs as True Bugs

-- Bugs as Missed or Undefined Requirements - I will argue (and in a book that I am starting to write about this topic) that a majority of the bugs that we find and document aren't really bugs at all, but rather functionality that has been misinterpreted based upon the requirements definition that comes out of segregated development processes, ie Write Requirements, Develop Software, Test Software and Deploy Software.

Language is such an imprecise way of communicating that it almost virtually guarantees that if you have more than 1 person developing the software for your product you will get different interpretations of how to implement the requirement functionally.

Remember the old 'The System Shall' statement? that is commonly used in writing Business Requirements documents?  I always thought that this missed the scope of the requirement, what about what the System Shall Not Do?.  We focus so much on happy path for our functional development that we miss large segments of functionality based upon what an application shouldn't be allowed to do.

Let's take an example of an English word to convey what I'm meaning:

What do you think of when you see the word - BASS

Do you think of this:

OR this?

These have the same spelling in the English language yet they have two entirely different meanings. Our life experiences become a prism for how we interpret what we read and how we react to it. (PS, I'm a musician so I think of the instrument before the fish)

Teams that rely on written requirements documents that are reviewed and worked on independently, meaning developers develop the code/functionality and then pass it on to testers will inherently have issues/bugs related to how something was interpreted and then developed.  In the above example the developers may have thought they were delivering a bass guitar, but the testers were expecting a bass fish (yeah extreme I know) but I believe this is the root of many of our issues when trying to deliver what the business expected in the first place.

-- Bugs as True Bugs - I believe that true bugs are more technical than functional (or should be).  Bugs related to how integration happens are very common because although we can describe the behavior of our feature we can't always anticipate issues related to how independent systems will work together.  Many 'true' bugs in Agile are caught in the moment and fixed before they ever make their way to production.  For the Finance people out there this is a tremendous cost saving that has been proven time and again.  ROI is greatly enhanced when you deal with tech debt up front rather over time.  And please don't ever think really that it is more important to get 'something' to production over making sure that the product is operationally sound.

So what to do?

To address the  inherent limitations with our  communication, we need to abstract our thinking into more concrete descriptions of behavior over broad-based statements such as the System Shall.

User Stories and the corresponding BDD acceptance criteria are a great way to do this as a BDD example table clearly defines the behavior of our product functionality via outcome based upon inputs.  The 'language' of BDD is unique so that everyone can begin to have a shared understanding of what the story and behavior of the product(aka system) will do.  BDD abstracts our communication and removes individual interpretation.

In Agile we start by ensuring that the teams understand that they OWN the quality of their delivery. One of the things that I absolutely love about high performing Agile team is that there is no finger-pointing, if a Sprint fails to deliver what the team committed to then everyone shares the blame, not just an individual or functional group.

How we bake quality into our products is by understanding how to write User Stories that provide context without the ability to misinterpret the meaning of the requirements.

To do this we must first ensure that we have a well written user story, what does that look like?

A good user story needs to identify the What and then the Value statement.  Many teams that I have worked with start to write stories that only identify the actor and What but leave out the value statement, which is really the proof that what we are working on is of sufficient value to devote our resources to.  A good user story should never have any Creative or Technical design conveyed, I know that many people like to show their technical knowledge by writing stories that convey what they think the design or system will need to utilize, but all that does is start the team down a path before exploring all options.

Behavior over language interpretation is what you are striving for when writing contextually rich user stories.

BDD with its accompanied Example statements takes an otherwise basic user story and brings it to life.  Much like we do when we take basic ingredients for cookies and then bring them together in the right amounts to deliver awesomeness every time.

Software quality is much like baking, you need:

• The right ingredients - Good individual team members, honest communication, commitment to quality
• The right process - Write good user stories, add quality BDD acceptance criteria, code and test in parallel and then deliver, involve the entire team in writing BDD, involve the entire team in the estimation process.

By taking the time to build contextually rich user stories and define the story with BDD acceptance you move towards a shared understanding of the 'behavior of your product' over one that is driven by functional requirements.  Requirements tend to convey to little of behavior and focus more on the big win that is being conveyed to Sr. Management regarding what is being delivered.

Agile is a very disciplined delivery process and in order to bake the quality into your product you need to develop efficient processes that keep the User Story/BDD train running smoothly.  If you are entering a sprint and then writing your BDD then you are already behind, you need to develop a process by which teams are working on current sprint development AND building context for the next one.  It can be done and when it is you get what I call progressive regression with the automation that comes out of your BDD work.

Agile is very disciplined and to think that going Agile will make your current life easier, well guess again.  What Agile will do is highlight EVERY current weakness you have in your current product delivery process and then focus your attention on finding ways of improving on them.

For those of you looking for workshops regarding User Story/BDD techniques, please reach out to me at soundagile@gmail.com.

BDD - Step by Step Process Tutorial

As you might tell from some of my blog topics I'm a huge believer in BDD, not just as a means to automation but more importantly as a process that helps us define requirements more accurately. When we move into an Agile delivery model, many individuals struggle to understand how they are supposed to document everything that they used to put in their Product Requirements documents (or a whole host of other acronyms).  These documents formed the basis of our engagement with the business and with the teams that would ultimately deliver what the business thought they were asking for in the PRD.

There is an interesting game that has many flavors such as Social Telephone game, that for me, makes clear the issue with large documents that multiple groups need to review.  Each of us is individually focused on the things that we think are important and we often have different interpretations of the written word.  And as such as we work to deliver in our silos we move towards an uncommon understanding of what is being built.  I would argue that many 'defects' that are found are actually poorly interpreted requirements.

For those of you in highly regulated industries you know what I'm talking about.  The endless hours spent reading a single paragraph trying to derive the real intent and meaning behind the written word is exhausting and fraught with peril because if we get it wrong there are penalties and mad scrambles to implement a hack to make it work the 'right' way.

Software development is made hard because of these communication differences, be they cultural, language or other, they exist and they make it difficult to come to a collective understanding of what is being asked for.

User stories help break down this barrier as they define small pieces of a larger whole and place a value statement so that we understand WHY what we are being asked to build is important.  Many teams writing user stories leave off that important 'so that' statement.  Leaving off 'so that' leads to so what?

Behavior Driven Development, for me, changed the way that I looked at defining requirements because it removed the business language of things such as the business requires this, or the feature shall do that.  The statements sound powerful yet deliver little in real context for the teams to work from.

Breaking down user stories with BDD still leaves the team to work with a non-technical domain language and then provides a clear method of defining the behavior (positive and negative) for the teams to work from.

The power of context with the respective speed and quality it delivers can't be denied.  However don't be fooled that this is easy, it isn't.  Agile is extremely disciplined, something many miss on their way to the Agile party.  Done right it can take your delivery processes to new heights, done wrong it becomes just another new fangled process that doesn't work.

Below is a BDD tutorial that can get you started on your way to learning how to build contextually rich user stories.  Good luck and have fun!

BDD Training

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.

BDD - A team oriented activity

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 -

1. 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.
2. 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....
3. 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.

Behavior Driven Development is more than Automation

Recently while working with an organization going through a large Agile adoption I had the opportunity to work with a team that was open to adopting BDD acceptance criteria story development.  One of the key differences for this team was that this was the first time that they had experienced a collaborative story development effort.  Prior to this most teams in the organization looked to the Product Owner to write all of the stories, which led to stories that were not contextually rich, had little to no acceptance criteria and were difficult to demo at the end of the sprint.

As I discussed the success of the teams use of BDD I was surprised to hear feedback that indicated the organization wasn't ready for the heavy lift of using BDD and that I hadn't moved the team into BDD because their final work wasn't automated.

If that is your position then I think you are missing the point of BDD.  Yes BDD is great in that when you right acceptance criteria in the Given/When/Then format and build your example tables correctly you can obtain automation fairly easily with tools such as Cucumber, Fitnesse and a whole host of tools that have been developed to support this very successful way to build out what I call 'contextually rich' user stories.

However even if you don't automate your BDD acceptance criteria, the value you get from understanding the behavior of the features you are going to build is invaluable.

BDD came about because Dan North realized that TDD and really great code meant nothing if it didn't deliver the value or functionality that the stakeholder needed.  This concept was clearly illustrated for me at one organization I worked for when the Development Manager was lamenting about a Product his team was enhancing was pulled from the market because they didn't deliver on time in order for the organization to stay competitive in the market.  He said 'If only they could see all of the cool code that we've written'....To which I said 'Business doesn't care about code they care about delivery" no matter how great your product is from a code perspective it matters not at all if you don't deliver it when your customer needs it.

For those of you who are exploring the use of BDD with your Scrum teams understand that there are essentially two separate efforts that effective teams are working on:

1. Team collaboration - Successful teams using BDD understand that they all need to be involved when building out user story context with Given/When/Then.  In fact I would argue that this is the most important element that drives a clear understanding of what we are building and guidance to when a user story is done.

2. Automation - One of key components of successful Agile teams is the development and maintenance of an effective automation suite.  Utilizing BDD provides an effective way for teams to obtain high levels of automation and do so within the Sprint that they are working in.  A common mistake of newer Agile teams is to develop in one sprint and test in the next and sometimes automate in the third.  Using BDD automation tools such as Cucumber with well written acceptance criteria (I'll provide examples of well written BDD in my next blog post)

A third benefit of BDD is that a Scrum Team builds a clear understanding of the scope of the story.  Since everyone participates in the development of the acceptance criteria, if a scenario is missed, it's a shared miss - No finger pointing, just manage the new scope with a new story and prioritize it in the backlog.

I've helped a number of organizations implement BDD effectively,  one of which did not have any automation at all.  The use of BDD acceptance criteria writing almost immediately improved the understanding of the features being developed and helped my QA team write significantly more test cases than they had been doing.  This effort led to a measurable improvement in Quality even before we added the automation suite later.

Having come from a waterfall world many years ago I can tell you that when you 'get' BDD,  it changes the way that you look at requirements and provides you with a mental framework that you can quickly use to model what is going to be built.

After a few months of using this format at Disney the Product Owners were uniform in their agreement that there simply was no other way that they would want to work with their teams.

Automation IS our goal, but it is not what defines BDD.