Behaviour Driven Development – How to actually BDD! No tech skills required :)

What is your approach to creating acceptance criteria ?

How do you describe the expected behaviour of the requirements you capture?

Maybe your a business type who complains that IT ‘don’t make things work the way you wanted it to’ or  a business analyst who finds its hard to best describe what ‘stuff’ should do.

Or maybe you’re a developer who’s writing code and you’re constantly having to go back and make changes because the AC isn’t what you ‘thought’ it was.

Before I go on, let me put it out there from now –

People will always misinterpret things. Interpretation is an individual way of processing information & so there is always a chance of people seeing things differently -even though their looking/listening/experiencing the same thing. The only thing we can do is reduce the likely-hood of misinterpretation – not eradicate it!

So maybe the real question is…

How do we explicitly explain what the business want to help developers get it to as close to what the business want – as humanly possible!

How?

Its called BDD.

Behaviour driven development.

BDD is more than an approach to acceptance criteria writing – its a technique that was introduced to deliver (to quote the creator Dan North) ‘well crafted software’. There are a few facets to BDD but I’ll be focusing on the acceptance criteria part in this blog. So lets get some specification by example going.

First, we need a case study for us to example on.

So lets say that a company  (Sky maybe) wanted to stream the olympics from a smart phone app but want to ensure that users streaming the live Olympic event were informed on the TV Licensing laws to actually watch Live TV from their phones. Lets first knock up a story for this requirement:

Here’s an example: 

#Story 1

Title:  Customer with TV Licence

As customer with a TV Licence

I want to view Live video items

So that I can watch the Olympics

Great we have our story. Now this story could have a few behaviours. Lets look at modelling the first scenario, for those users who do have a TV Licence, or at least say they do 😉

Scenario: 1

Given I have selected a live video Item

When the pop up box appears

And I select

|Watch Now|

Then Launch the selected Video

There it is.

Given, When, Then.

This is a very powerful approach to describing behaviour. When a developer picks up this user story and spins the card round, he/she has a pretty good idea of what the expected behaviour is for customers who do have a TV License. Lets create another story for those customers who do not have a TV License:

#Story 2

Title: Customer with no TV Licence

As customer with no TV Licence

I want to view Live video items

So that I can get a TV Licence to view Live TV via the I-Player

Scenario :1

Given I have selected a live vide item

When the pop up box appears

And I select

| I don’t have a TV Licence|

Then take me to the below URL:

http://www.tvlicensing.co.uk

Hope the examples inspire you to try it out 🙂

 

Try removing your QA section to get MORE done!

So this was the problem we were seeing:

Look familiar?

QA field jam packed with stories?

Finding out about issues (stories created during sprint) at the end of the sprint?

Seeing hangover at the end of your sprint?

Why?

Maybe your QA got sick.

Maybe your QA was more busy than normal with support requests.

Maybe your QA was spending time writing acceptance criteria with the PO for the next sprints set of stories.

Or, maybe we need to stop thinking as the QA as the only person who can QA work.

Acting as teams, not individuals 

Scrum is about teams & that means we ultimately need to think about what WE as teams are trying to accomplish. Team goals should be the most important thing in any Scrum team.

That’s what makes Scrum so powerful, you got this disciplined timebox with a specific focus, a goal, which a team work together to deliver.

When we focus on our individual goals over the team goal the Sprint goal suffers.

Delivering the message

When I saw the QA bottlenecks, I asked at the stand-up:

Looking at the board this morning, we need to ask ourselves that question. What can we possibly get through to Done today?

It was my way of hinting that there is plenty in the QA section available to be tested.

By EVERYONE.

The bread and butter of any optimised approach to delivery is focusing on whats in progress to increase throughput.

Something that Kanban principles push hard.

So we can ask the team to focus on getting ‘In Progress’ cards delivered first before picking up new Sprint backlog items.

Developers can QA each others work, so checkout the QA section first to bring down that bottleneck & get stuff into Done.

But we can still reinforce this message to create the right behaviour!

How to visually bring the message home

Change your board.

Remove your QA section.

Here’s one I prepared earlier:

Now when a developers done with his user story, he/she can push it just a notch to the right which means the story is STILL ‘In Progress’.

That is a subtle but powerful visual representation which says “Hey just cause we have done our part developing stories, the stories are still In ‘Progress’.