Agile Requirements & Behavior Driven Development (BDD)

Three aspects of Behavior Driven Development and Agile Requirements

There are many methodologies on how to manage software product development as a professional software development vendor. Agile and Behavior Driven Development became more and more popular recently so it would be good to discuss more this topic.

First of all, Requirements are not the same as a product specifications. A requirement is something which is required by some people. Not just some people, but specific people – the Stakeholders.

A Stakeholder is someone who has some business in solving some problems. And yes, it could be a user of our software product too. Users are using the software because it helps them to solve some particular problems. It means that they have some business in using it. We could assume that in requirements we mostly want to answer the question of why the product needs to do some particular things for our Stakeholders?

Functional Specification is more detailed than requirements. The goal for the functional specification is to describe what the product will do to solve particular problems and meet Stakeholders’ requirements.

And there is a third, the bottom level – Technical Specification. Here we want to describe how the product will do that functionality described in Functional Specification.

You may write the requirements in the User Stories format. User Stories could help us discover what are the requirements.

And for the Functional Specification of the product, you may use Scenarios, Examples, or Use Cases. There is even a specific pseudo-language designed to do that in a proper way – it is called Gherkin. Thanks to that it is also easy to write automated Acceptance Tests based on the functional specification. In that case, tests became the specification, or specifications became tests.

And finally Technical Specification. Probably the best way to assure that the technical specification is always up to date during the infinite software development process is to use Unit Tests for that. And probably the best way to write Unit Tests is to use Test-Driven Development.

The Agile Requirements

User Stories became more and more popular as a tool to write requirements down.

Standard User Story format looks like that:

As a [user role]
I want [some action]
So [goal]

Unfortunately so often User Stories looks like that:

As a user
I want to log in into the application
So I will be logged in.

It looks awful, and it is ridiculous. If you write users stories like that try to think if you are not wasting time for that. Is there any value in describing requirements in a way like that? Of course, this example is trivial, and using User Stories for such simple requirements as authentication is a waste of time, but it shows the most common mistake which I have observed in many teams starting their adventure with BDD or Agile Requirements.

The format that I am recommending to my teams is a little bit different. I prefer to write User Stories like that:

In order to [business goal]
As a [stakeholder]
I would like to [visible change in software behavior]

First of all, I am starting with a goal because discovering the purpose of doing something could eliminate many ridiculous requirements. Yes! Eliminating requirements, or decreasing the amount of them. It is the best way to keep our products clear and easier to maintain. Not even talking about making the product easier to use.

Secondly, I have change the regular user perspective to a Stakeholder perspective. That way I am focused on the real value, not just adding some fancy features. Of course, users are often the stakeholders too, but there are also other stakeholders for our products like some law regulations, business owners, administrators, back-office users, etc.

And last but not least, the “visible change in the software behavior” is what I want. Only visible changes in the functionality could add some value to the product. Everything else is just a waste of time.

And there is a reason behind placing “visible changes in the software” at the end of the User Story. This order opens the options list. So when I start working on User Story by defining a goal and then describing who is the Stakeholder for whom this goal is important now I could generate few different options which could cover this requirement. This opened User Stories format foster the creative process.

The Functional Specification

When we already have User Story and we chose one (or more) option we could focus on what the product could do to cover this requirement.

This is the moment where we can go into the BDD loop. Start with writing some examples. You may use Gherkin – Given/When/Then convention. Where you define Context, Tested Action, and Assertions for our use case/example. This way we can create very independent and clear automated Acceptance Tests.

An example BDD Scenario might look like that:

GIVEN user logged in as admin
WHEN user adds an expensive product to the basket
THEN proper discount is added to the total order value

The Technical Specification

After we finally have such functional test written, we could go into Test-Driven Development loop and write a code by adding one test after another and refactor everything in each TDD loop. Unit Test written in a  Test-Driven Development way will create a nice technical specification for our product. By browsing such tests every developer could answer the question of how things work.

That way we could combine Requirements, Functional Specification, and Technical Specification. Have you noticed that there are no additional costs behind that approach? Automated Tests and documentation came for free.

When to use Behavior Driven Development?

People often claim that they are wasting to much time when using BDD for everything that they are doing. Especially for some trivial stuff.
BDD is good to be used only when you are dealing with things that are not obvious. Especially not obvious for you and your team.

Every time when we have to deal with something which is unknown and we do not have experience in doing such a thing it is a good time to use BDD and User Stories.

Every time when we are not sure if we understand the purpose of creating some feature it is a good time to take index cards and write some User Stories down.

Another problem which I have noticed is that so often people are writing to many acceptance tests and they are trying to cover every functionality by such a tests. It is very important to limit the amount of the acceptance tests to the absolute minimum. We also want to only have the crucial functionality described in our documentation.

Behavior Driven Development, Agile Requirements and Cynefin

Behavior Driven Development is just one of the tools that professional development team may use if needed. Using Behavior Driven Development for all requirements is usually a waste of time.

I love to explain when to use Behavior Driven Development by explaining Cynefin Framework concept.

You have five areas/categories of problems/categories of requirements for your product: Obvious, Complicated, Complex, Chaos and Disorder.

5 Levels of Ignorance

In this article, Liz Keogh described 5 levels of ignorance for software requirements. You can map this levels at the Cynefin Framework:

• 1st level at Obvious – Everyone knows how this requirement should be implemented
• 2nd level between Obvious and Complicated – some people in our team knows how it should be implemented.
• 3rd level in the top right corner of Complicated – there are some experts in our organization, who already know how it should work and what should it do, but there are only a few of them.
• 4th level of ignorance, somewhere between Complicated and Complex – someone, somewhere already did that but not in our organization, so we do not know how should it work.
• 5th level in the top-left corner, in Complex zone – none have ever done this before.

When I am working with our teams usually we are starting with requirements classification. We do that to chose the proper method and tools to implement them. The process starts with mapping the backlog at the Cynefin and those 5 levels of ignorance.

3rd Level of Ignorance – a good place to start with BDD

Things that are at 1st and 2nd level of ignorance usually do not need to be specified and clarified so we do not waste our time to write user stories and scenarios in gherkin for them. Most of the team members know what need to be done at this levels so they should not have any problems with understanding requirements and communication around them.. (Beware that Obvious is close to Chaos and if those type of requirements is not managed at all, it will soon become chaotic and problematic.)

3rd Level of Ignorance – where we have limited access to the domain experts knowledge about how things should work is a perfect place to use Behavior Driven Development. Here the value is highest and BDD costs (no BDD doesn’t come for free) are justified by the benefits. Behavior Driven Development as a communication tool works perfectly when we are aiming for fast knowledge sharing and common requirements understanding.

Levels 5th and sometimes 4th – using Behavior Driven Development here is more like guessing. We do not know how should it work and we do not know if it is even possible to implement particular requirements in a way we describe it in our User Stories and Scenarios/Examples. For this kind of requirements first, we are doing some Research & Development or Reverse Engineering work. By creating some prototypes or spikes we are discovering how requirements could be done. What really happens after R&D is that by prototyping and experimenting we gain the knowledge and few experts (former researchers) appears in our organization. So the requirements are moving from 4th and 5th level to the 3rd level where we could successfully re-implement them using Behavior Driven Development.

Using Behavior Driven Development at the 5th and 4th level is often confusing. Using it at 1st and 2nd level is a waste of time because it is simply not needed there.