BDD & Agile Requirements

Do it right!

The world is not the same anymore… Everything changed in last few years… So why do we pretend to use methods and tools from the past century?

What has changed in the last 20 years in IT?

For sure Technology is an area where we a huge progress has been made. 20 years ago I have get my first Personal Computer. Two years later I have been finally connected to the Internet. That was a change! 56Kbits/s modem which allow me to connect with the entire world. And… waiting few hours to download mp3 of my favorite bands… and sleepless nights… and nightmares when modem suddenly disconnect during downloading.

Around 15 years ago I have designed and published my first website. It was pure HTML with frames. It was awesome! Thanks to computer I have finally started creation process and I heave shared my products with others. Look at the web apps right now, have you ever thought twenty years ago that the world would look like it looks right now?

Second thing which has been changed in last 20 years are customers or users of the software which we are creating. Two decades ago there were maybe just few percent of people around the world who have opportunity to use software of any kind. Right now software is everywhere and almost everyone all around the globe is using it one way or another. We are living in the world of software.

Because of that another change happen or need to happen. Relations between customers, users (let call it business) and technology (let call it software development) needs to change.

And it is not the end. The world is changing all the time. Change is inevitable. And users of our software need changes all the time cause their world is changing too. We used to manage software development using Project Management approach. But project by definition is something which has it starting point, end date or deadline, more or less fixed but defined scope, and limited budget. How many of you could tell that they are working on Software Projects right now? How many of you could tell when you will finish working on your product? Could you give a particular date of the end?

This is one of the reason why Agile and Behavior Driven Development became more and more popular.

Three aspects of Behavior Driven Development and Agile Requirements

Firs of all Requirements is something different than product specification. Requirement is something which is required by some people. Not just any people but specific people who I would like to call Stakeholders.

Stakeholder is someone who has some business in solving some problems. And yes — it could be a user of our software too. Users are using 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 know why the product need to do some particular things.

Functional Specification is more detailed than requirements. The goal of functional specification is to describe what product could do to solve particular problems and meet Stakeholders requirements.

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

Requirements could be written down in User Stories format. Or not just “written down” but User Stories could help us discover what the requirements are.

A great way describe functional specification of the product is using some examples or use cases. It is also easy to write automated Acceptance Tests which will automatically check if our business objectives are fulfilled.

And finally Technical Specification — probably the best way to assure that this part is actual during infinite software development process is using Unit Tests. And probably the best way to write Unit Tests is use Test-Driven Development.

Requirements

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

Standard User Story format looks like that:

As an <user role>
I wan <some action>
So <goal>

Unfortunately so often User Stories looks like that:

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

It looks awful, and it is stupid. Is there any value in describing requirements in the way like that? Or is it just a waste of time. Of course this example is trivial and using User Stories for that is a wast of time at all, but it shows the most common mistake in User Stories usage which I have noticed so many times in many different teams.

The format which I am recommending to my times 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 purpose of doing something could eliminate many ridicules requirements. Yes! Eliminating requirements, or decreasing amount of them. It is the best way to keep our products clear and easier to maintain.

Secondly I have change regular user perspective to a Stakeholder perspective. That way I am focused on the real value, not just addin some fancy features. Of course users are often the stakeholders too.

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

Putting this visible changes in the software at the end of the User Story makes it an option. So when I start working on User Story by defining a goal and the Stakeholder for whom this goal is important I could generate many different options which could cover this requirement. This opened composition increase the creativity process.

Functional Specification

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

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

Technical Specification

When we have such a test written we could go into Test-Driven Development loop and write a code by adding test first and refactor everything in every loop.

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

When to use Behavior Driven Development?

People often claim that they wasting to much time when using BDD for everything what they are doing. Especially for some trivial stuff which need to be done. So I recommend you to use BDD only when you are dealing with things which are not obvious — especially not obvious for you.

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 card and write some User Stories down.

Other 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 amount of acceptance testing to totally needed minimum which will cover the most important and valuable functionality of your product. We also want to have crucial functionality described in our documentation.

Next Step

The next step could be a Continuous Delivery. But first it is good to create some habits like doing only one thing at a time. It is called Single Bath Flow. I mean implement only one User Story at a time and do not start other until the first one is not completely done. Thanks that it will be much more easier to implement Continuous Delivery.

Continuous Delivery does not mean that you have to deliver every piece of software to production. It means that your product could be production ready whenever you asks for it.

Implementing Continuous Delivery in already existing product is not trivial. It is not only about adding some automated tests, writing deployment scripts and setup testing environments. Often you need to redesign you system so it will be completely testable, configurable and deploy-able by pushing only one button. It is obviously much more easier to start a product with Continuous Delivery from scratch.

If we succeed in implementing Continuous Delivery then we could boost our business effectiveness by giving them a toll for creating safety to fail experiments.

That way IT became a partner for business not just a supplier who only translate specification into working functionality. Thanks to User Stories innovation often emerge in development teams.