Using BDD to move (a bit of) the BBC to Salford

Published on 17 February 2011 in , , , ,

At some point in December I took over as product manager of the Connected Homepage project at BBC Red Button as the previous product manager had another project that was taking up too much of his time.

Big Red Button

Photo by Reverend Aviator. Creative Commons licensed.

The Connected Homepage is the version of the BBC Red Button homepage that appears if you have a set top box or TV which is connected to the internet, meaning we can link to internet delivered TV applications such as BBC iPlayer. The project delivered its first release to Freesat last year, and work has been building up ready for a Freeview HD release this spring.

That I took over the project is nothing special in itself; such things happen all the time. Any changes in a team are preferably to be avoided, however they can’t always be avoided. In this case the transition was pretty smooth and pain free thanks to me joining a very mature team who knew what they needed to do and were (and still are) doing it well.

However such transitions can never be totally pain free. For me one of the issues was understanding the work “backlog”.

Within BBC Red Button, as in many parts of the BBC, tend to use agile software development methodologies, namely a hybrid mixture of SCRUM with a hint of Kanban. Each project has a “backlog” of work which is basically a prioritised list of requirements (known as “items”) which the product manager owns and which is used to work out what the team should be building next.

There are many ways of writing backlog items, and most projects define them as user stories, in the format

As a [role], I want [something] so that [benefit]

So an example from BBC iPlayer (the Freeview, Freesat and BT Vision versions of which I also product manage) may read:

As a viewer, I want to be able to pause video, so that I can pop out to answer the doorbell which just rang

The idea of a user story is that it clearly communicates to everyone what’s involved in a task, who wants it, and why. Here, the user wants to be able to pause video, and why (well one reason why – to be honest, we usually drop the benefit bit in examples like that!)

Not all user stories are quite so easy to explain outside the team, and teams sometimes get in to the habit of writing stories in a way that they understand but no one else does, which inadvertantly turns out like the kind of secret code that kids may write in.

Generally this doesn’t bother anyone; well until someone new joins the team anyway. And you can imagine me reading this story on the backlog, which everyone else understood, and getting rather confused:

As a viewer I want to connect to the connected homepage to have a valid connected homepage

Thankfully most of the backlog wasn’t written in such incomprehensible lingo, but my arrival gave the team a useful reminder that everyone needs to be able to understand what a backlog item means.

Now that kind of niggling thing often happens in a handover, however that’s generally fine as there’s usually a period of dual running so you can pick the brains of your predecessor.

Except that won’t be easy for BBC Red Button. This summer BBC Red Button moves to Salford, and staff will either be making the move (many have already gone) or leaving (including myself.)

Whilst some projects will be running over the transition, it’s not practical to do that with every project so it was decided to park development on the Connected Homepage at the end of the current current phase, to be picked up again some point in the future by a brand new team and with (probably) next to no handover.

That is not an ideal situation. My backlog has plenty of important outstanding requirements that I really didn’t want to get lost. I knew from past experience that picking up a parked project is often painful. The user stories often make no sense to the new team so the old requirements just get thrown away because no one knows what they mean.

My initial thought was to attach two items to every story – requestor and reason. Requestor is hopefully self explanatory. Who asked for this requirement to be done. The user story doesn’t always offer that information – my boss might ask for a feature, however it may be a feature the user probably wants. Reason was just a bit more detail about why it had been requested – a paragraph or so. More than would usually be put in a story.

Combing through the backlog I went through each item and added the data. If I couldn’t find a requestor or reason, the story was given a low priority.

But it still didn’t get to the crux of communicating those requirements for me. There was still scope for misunderstanding by the new team. Even the best written story may be interpreted in a completely different way by someone who didn’t write it.

Now I could have written one pagers on everything, to try and pass on that information, but it would be a lot of work that I didn’t have time to do.

By chance it was about that time that a colleague organised a workshop on trying to find new ways to work better, and it was here that I learned about Behavior Driven Development, or BDD.

Explaining BDD is not something I’ll do here because I’m not an expert and don’t know enough about it. Someone else can do that. However at its core is the desire to make acceptance criteria between stakeholders and different team members, clear and understandable. It suggests writing them in a simple “Given/When/Then” format, like this stock control system based one taken from Wikipedia’s page on BDD:

Given a customer previously bought a black sweater from me

and I currently have three black sweaters left in stock

when he returns the sweater for a refund

then I should have four black sweaters in stock

Hopefully that’s pretty understandable. If you have three sweaters in stock and someone returns one they’ve bought, you’ve got four. Doddle.

BBC Red Button connected homepage

Now there’s a lot more to doing BDD properly, however it struck me straight away that here was a little bit that I could use which may help in the Salford transistion. Writing a few, I felt like I was getting somewhere. For example, this (relatively simply) story of

As a Service Delivery Manager I want to be able to schedule channel specific links to the IP Bridge on Freesat and Freeview

could be argumented with:

Scenario 1:

Given a programme is on (say) BBC Three

and it has red button content associated with it

and the programme team want a “press red” icon to point out the content exists

when the user tunes to that channel

then a prompt appears inviting them to launch the red button content

Scenario 2:

Given a programme is on (say) BBC Three

and it has red button content associated with it

and the programme team want a “press red” icon to point out the content exists

when the user tunes to a different BBC channel

then no “press red” icon appears.

Now, no matter what I do, there’s still scope for confusion and misunderstanding when the new team finally pick up the project at whatever point in the future. (Hey, it might all be scrapped and started again!)

True test for all this will only come when I’m long gone. I may never find out how well all this works. All I can do in this is make a stab at trying to make the transition as smooth as possible. And hopefully this limited usage of BDD will make its mark. Certainly as a way of helping me think about communicating my requirements, it’s been very useful. I hope someone in Salford in nine months time, agrees.


  • Darren says:

    I bet they will, I’ve found that people appreciate if you can take functionality and break it out into a BDD form that they can read.
    The only question is if other developers will maintain it, but I wouldn’t use that to judge the strength of BDD.

  • Andrew Bowden says:

    When you’re effectively replacing half your staff (which we are), here’s an inevitability that some processes, systems and ideas will just disappear and get lost – especially ones we’ve only just started to embrace like BDD. Our test team in particular are very keen to start adopting it more widely, however the people pushing that the most are also the ones who will be leaving.
    Maybe whoever takes my job will read this in a years time and let me know how it went 🙂