Two cautionary tales
We’ve all been there, delivering an important piece of work under pressure.
Working under pressure causes errors.
In important projects, even small errors can have an outsize impact.
Here’s a six billion dollar example: an Analyst at an investment firm was working on a risk model in an Excel spreadsheet. At one point in the model he intended to take an average of two numbers, but a typo caused the model to divide one of the numbers by the other instead. A relatively minor oversight in the grand scheme of things? Maybe, if the analyst’s work had been checked thoroughly. But time was tight and the model was rushed through without double checking and used to drive decision making on real trades.
The oversight was eventually found and fixed - but only after the investment bank lost $6 billion.
Or here’s another one: engineers were building a bridge between Germany and Switzerland. The two countries measure sea level differently: the Germans measure to the level of the North Sea, while the Swiss measure to the level of the Mediterranean. So when they started building the bridge from both sides, they built the height difference (27cm) into the calculations to make sure it would meet in the middle. So far so good. But then one of the people calculating the correction made an error, doubling the height gap rather than removing it.
Again, the error was eventually discovered - when construction was under way and someone calculated a projected 54cm gap where the two sides would meet. One side of the bridge had the be rebuilt, and the engineers suffered a degree of embarrassment.
What do these two scenarios share? Employees were working in the best interests of the organisation, under high stakes situations, and they did almost everything right. Both could seriously have benefited from a double-check from a fresh pair of eyes.
Double-checking for digital
Fresh pairs of eyes are no less essential when you’re developing a new digital asset. You’ll already be doing some form of double-checking with code reviews, pair programming, and getting new people to look at outputs (if you aren’t, you should be).
But what happens further down the line? How can you ensure a new feature, visual change, or update won’t break everything already built?
Enter Behaviour-Driven Development (BDD).
What is BDD and how can it help me?
BDD is a methodology and a way of working. Once implemented it becomes central to the development workflow. Most importantly, it gives a common language for all project stakeholders to communicate by removing business (and technical) jargon, given a common hymn sheet from which everyone can sing.
One way to look at this benefit of BDD is like this. Throughout a project there might be different interpretations among your team on how certain features should behave. Should that button spin once clicked? Does the next screen slide in from the top, side, or bottom? The way in which a Customer Experience expert thinks about a feature will often be different to the way in which the product Product Owner thinks about it - and a Business Analyst, User Experience expert, User Interface expert, or Developer will each have their own ways of thinking.
In other words, in the life of a digital project there are multiple requirement inputs: customer experience research, business service design sessions, user experience and design, business analysis sessions, and multiple conversations and meetings. That can be a lot to digest, and tricky to follow.
BDD lets you keep track of all of these inputs and approaches, surfacing requirements towards the start of a project. That lets you deliver your project with assurance that quality, reliability, and testability remain intact throughout.
Here’s how it works: BDD breaks a user story into small chunks of specific behaviour. It starts with a scenario which acts as a header, then adds some context, and specifies an event in that context and an outcome from the event.
Take this example.
Scenario: Open personal details from settings
Given I am logged into the online service
And I am viewing the “settings” page
When I click on the about me button
Then I am taken to the “personal details” page
And I see my first name, last name, email address
You should be able to read this user story from start to finish as a continuous sentence. Let’s break it down.
- There’s a scenario heading, so people know what the story refers to.
- The “given” and “and” act as context for the reader, getting everyone on the same page.
- The “when” signifies a user taking a specific action.
- The “then” and final “and” specify a precise outcome for the user’s taking that specific action.
This process is repeated until every. single. event. is accounted for.
That’s how BDD removes any ambiguity (and, hopefully, disputes) on how a digital asset is meant to function.
The process is iterative. A new requirement has been surfaced? Great, add it in! A UX change has been made to the digital asset? Great, make the required amends!
At this point you have granular documentation for your digital asset which can be used to align all project stakeholders and useful acceptance criteria.
BDD scenarios also allow the development of automated tests. These tests run prior to a new release going live, checking that each individual element of your digital asset is working as intended. It’s pretty cool to see in action, and gives you an automated second pair of eyes to enable fast development with a safety net.
To hear more about BDD and how it can be useful for your digital asset, get in touch.