Want to improve delivery — try BDD

It’s not just about the testing

Greg Zealley
UK Hydrographic Office
3 min readAug 5, 2019

--

To many people BDD simply equates to testing — a way of producing Given-When-Then scenarios that can be used to create automated tests. But to think of BDD in this way is to miss the main advantage, that of team collaboration.

The first line of the Wikipedia page sums it up perfectly:

In software engineering, behaviour-driven development (BDD) is an Agile software development process that encourages collaboration between developers, QA and non-technical or business participants in a software project.

Photo by Mimi Thian on Unsplash

The benefits of representatives of the key areas of a development team — Product Owner, developers and testers — reviewing and refining requirements before development activity begins are huge… and I’ve witnessed the benefits first hand.

A struggling development team

I worked alongside a team where there was discord, and this effected the team’s morale and hence its delivery. Output varied widely from sprint to sprint, Scrum events were dreaded as they were heated and could consume an entire day. The key reason for this struggle was a disjointed view of what the team should be delivering. The backlog was managed solely by the PO. When it came to delivery, the PO would want one thing, the development team would implement another, and the tester was stuck in the middle not knowing what to verify functionality against!

The problem

The process of creating a user story was that the PO discussed requirements with stakeholders and converted this into a story, with either no acceptance criteria, or added themselves. The first time the team would see this story was refinement or even planning. As a result, when the story was presented there would be confusion, a great deal of questioning and even anger. The story would be updated as best it could in difficult sessions and then played. During development there would inevitably be more questions and development would often have to pivot midway through, sometimes at a huge cost. Result — slow delivery, a PO that felt isolated and an unhappy team.

Solution — BDD (i.e. Collaboration!)

I worked with the team to introduce BDD as a way to overcome these problems. My hope was that if we could get stories better refined and understood by more members of the team then this would reduce discord. I also wanted to create a “safe” event where the PO could be challenged, to avoid the often authority-questioning challenging that was occurring in front of the entire team at Scrum events. These ways of working were introduced:

  • Stories would continue to be added to the backlog by the PO
  • These would then be discussed at a Three Amigos session (see below)
  • Acceptance Criteria either completed then, or shortly after by a tester or developer
  • The stories would then be brought to refinement in a better refined and understood state

The Three Amigos session was an hour a week where the story could be discussed with the PO, a developer and a tester. The story could be suitably refined:

  • What is the desired outcome
  • What is the scope
  • Do we have the right information, and enough of it to play
  • Is the language used unambiguous
  • What are the acceptance criteria

The result of this were refined stories, that had criteria, and most importantly, were understood by several members of the team. This meant at refinement there was harmony and an immediate shared understanding. Sometimes we learnt that we didn’t know enough about a story and more questions were required, but we learnt that that’s OK too.

And the results..

After using BDD for a number of sprints, and embedding this way of working the results were remarkable:

  • Refinement and planning sessions became focussed discussions to share and finalise a story
  • The lack of heated debate resulted in vastly improved relations within the team
  • A PO that was no longer isolated and on the defensive, and instead became integral to the team
  • A notable increase in delivery

BDD is far more than testing, the benefits of collaboration within a team can directly affect their output, which is surely what every stakeholder desires!

Links

https://en.wikipedia.org/wiki/Behavior-driven_development
https://en.wikipedia.org/wiki/Behavior-driven_development#The_Three_Amigos

--

--

Greg Zealley
UK Hydrographic Office

Lead Test Engineer at the UK Hydrographic Office. Advocate of test automation done properly.