Skip to main content
Seb Rose
Co-author of The BDD Books
View all authors

How does BDD affect traceability?

Seb Rose
Co-author of The BDD Books

Recently my colleague, Theo England, broadcast a question:

We're thinking about running a … one-day class [about BDD] designed for business execs. Tell us the questions we must answer for it to be useful.

We received 60 responses, including some very good questions.

As well as providing valuable input into the design of our upcoming course, BDD for busy people, we felt that we should answer some of the questions in a public forum. This is the second in the series.

“Where does the sign-off of requirements happen – and how is it documented? Can we have full traceability?”

Better requirements by harnessing the power of examples

Seb Rose
Co-author of The BDD Books

Writing good requirements is a challenge, especially if they’re intended to be understood by someone other than their author. The more complicated a project gets, the harder it is to communicate the requirements in an unambiguous way. It’s easier to ask someone to cut the grass than it is to describe a design for a flower bed.

By the time we get to designing software systems, the complexity is such that requirements are a collaborative effort that need to be recorded in a structured way. During the 20th century, various formal and semi-formal approaches were integrated into a waterfall model – where each project had distinct, gated phases and each phase had defined outputs, such as “requirements specification”. These approaches to requirements management did not remove the risk of project failure, while adding considerable upfront costs that were often unjustified in the rapidly changing business environment.

What's the ROI of BDD?

Seb Rose
Co-author of The BDD Books

Recently my colleague, Theo England, broadcast a question:

We're thinking about running a … half-day class [about BDD] designed for business execs. Tell us the questions we must answer for it to be useful.

We received 60 responses, including some very good questions.

As well as providing valuable input into the design of our upcoming course, BDD for busy people, we felt that we should answer some of the questions in a public forum. This is the first in the series.

“How do I convince Business Partners/Stakeholders/Product Managers that there is extreme value in BDD despite the start-up costs/learning curve?”

BDD builds momentum

Seb Rose
Co-author of The BDD Books

Last week Elisabeth Hendrickson published a blog post called Momentum > Urgency. Please go read it if you haven’t already. In the post she shared a list of observations that she had made when teams achieved a sense of momentum:

  • Everyone on the team has a shared understanding of the big picture and what “good” looks like so they don’t burn cycles on unnecessary or non-useful work.
  • The team breaks the work into small pieces (a couple days of work at most) that still represent incremental business value (even if not user-facing features).
  • The team embraces the technical practices necessary to ensure that the code they deliver does what they intended it to do.
  • There’s an engaged and responsive product manager* who is considered part of the team, and who does hands-on acceptance of the work.
  • When the work is “accepted,” it’s done. The entire team can stop thinking about it.
  • The work, and the status of the work, is visible to everyone.
  • The team as a whole has a strong sense of partnership and trust, so the visibility never becomes a mechanism for micromanagement.

Reading the list, I realised that these were very similar to observations that we have made of teams that practiced BDD successfully.

Eviscerating the Test Automation Pyramid

Seb Rose
Co-author of The BDD Books

The Test Automation Pyramid was popularised by Mike Cohn in his book, Succeeding with Agile.

https://martinfowler.com/articles/practical-test-pyramid.html

Over the years it has been rendered in dozens of different ways.

It has been applied, misapplied, discussed, dismissed, and repurposed. Through all it’s many changes, it remains just as useful at starting heated discussions as it ever was. In this article I add fuel to the fire by revisiting the eviscerated triangle that I first published in 2015.

User stories and BDD (part #4) - features are not stories

Seb Rose
Co-author of The BDD Books

Previously…

  1. Origins and evolution of the user story
  2. Discovery-discovery/?utm_source=userstories4&utm_medium=blogpost&utm_campaign=User-stories-4-BP)
  3. Small or far away?

This is the fourth in a series of articles digging into user stories, what they're used for, and how they interact with a BDD approach to software development. This post is the last in this series, but certainly not the last time I'll be talking about user stories. However, since it brings the current narrative arc to a close, it is perhaps the end of the beginning.

User stories and BDD (part #3) - small or far away?

Seb Rose
Co-author of The BDD Books

This is the third in a series of articles digging into user stories, what they're used for, and how they interact with a BDD approach to software development. You could say that this is a story about user stories. And like every good story, there's a beginning, a middle, and an end. This post is a continuation of the middle.

User stories and BDD (part #2) - Discovery

Seb Rose
Co-author of The BDD Books

This is the second in a series of articles digging into user stories, what they're used for, and how they interact with a BDD approach to software development. You could say that this is a story about user stories. And like every good story, there's a beginning, a middle, and an end. Welcome to the middle!

User stories and BDD (part #1) the origins and evolution of the user story

Seb Rose
Co-author of The BDD Books

This is the first in a series of articles that will take a look at user stories, what they're used for, and how they interact with a BDD approach to software development. You could say that this is a story about user stories. And like every other story, it's important to choose where to begin – because, contrary to the advice given in the Sound of Music, it's not always a good idea to "start at the very beginning".

Who should formulate the scenarios?

Seb Rose
Co-author of The BDD Books

This was extracted from BDD Books 2 - Formulation by Seb Rose & Gáspár Nagy.

Over the past few years, there has been a growing recognition that BDD is an approach made up of three practices.

During Discovery, the team will capture concrete examples of how the system is expected to behave. While doing this, they will also uncover important business terminology. Formulation is the process of transforming the concrete examples into business-readable specifications that will guide development and document the product for its whole lifetime.

Who should formulate the scenarios?