How to write a spike when using BDD?

Question

If Gherkin is used to write regular development user stories in the Scrum process, should Gherkin be used to write a spike as well? If so, given that often there is a lot of unknown information to be filled in, how can a spike be written as BDD?

Answer 1

Generally speaking, no.

More to the point, you should not expect a spike to be described in Gherkin. The primary purpose of BDD is to focus coding efforts toward a clear goal. When working a spike, your goal is a sort of validated exploration of a problem, so the BDD approach is overly limiting to the point that it works against the purpose of the spike.

Answer 2

TL;DR

Spikes optimize for learning. Unless behavior-driven development is integral to what you're trying to learn, don't follow the pattern slavishly. I often follow light TDD/BDD in story spikes when exploring code because it's a good way to develop code, not because it's required or necessary. For other things where it just gets in the way, I focus on the learning rather than techniques that just get in the way.

Below, I explain how to write a good story spike, and how to measure it. BDD isn't orthogonal to spikes, but it isn't inherent to the process either. You'll have to use your judgement!

More About Story Spikes

Spikes Aren't Always Executable Code

A well-written spike has clearly-defined success or exit criteria, but is not necessarily a good candidate for executable testing. Instead, you will generally want to define a measurable goal and a time box.

Defining Goals

For example, on one recent project I wrote a spike that said:

As a DevOps engineer with a two-day time box to explore,
identify three ways I can migrate a Docker container between pipeline stages
so that the team can reuse unmodified Docker images and reduce configuration drift.

The team agreed on a suitable size for the time box, which was written into the story. The measurable outcome of success was whether the spike resulted in any number of options (but no more than three) for migrating Docker containers between Development, QA, Staging, and Production. The context provided some scoping for the exercise.

Optimize Learning, Not Features

While I'm a big believer in demoing the result of spikes, TDD & BDD are really techniques for emergent design and iterative development. A spike isn't intended to deliver a maintainable (or even a working) feature. Instead, a spike delivers knowledge or reduces uncertainty related to some aspect of the project.

If your spike is about whether you can embiggen a widget, you may or may not choose to follow TDD/BDD development practices. In fact, for such spikes I'd actually recommend using the Mikado Method instead for this type of spike. Even with code, you're trying to answer the question "can it be done?" or "how can we do it?" rather than building something that can be immediately integrated.

However, in a more general sense, you're trying to learn something. Learning should have a goal, it should be measurable, and it should be time-boxed. It may even be demonstrable. Unfortunately, it is unlikely to be executable.

BDD is About Development and Behavior

Behavior-Driven Development is about both behavior and development. If your spike's outcome can be measured through executable behavioral tests, then using BDD isn't necessarily an anti-pattern. However, BDD is also about development, so if you're trying to learn something rather than build something, BDD may not be a natural fit.

Consider the two following questions a spike might try to answer:

1. Can our current API ensmallen a whatsit?
2. Which JavaScript framework makes it easiest to embiggen a widget?

The first example might benefit from a test-driven framework because you're trying to validate an idea that can be tested as executable code. However, the second question is broader, and while you could spend a ton of time writing test harnesses to validate each of 20 frameworks across a number of dimensions, the question is actually qualitative rather than red/green. Qualitative questions are less answerable by BDD frameworks.

Which is which, and when to use either, is more of an art form than a science. However, BDD isn't a hammer and all problems aren't nails. Determine what your spike is trying to accomplish, and then determine whether BDD or some other approach is more likely to result in validated learning. Then follow the validated learning approach!

Answer 3

There are spikes and spikes.

I would say that if the spike is to develop a proof of concept feature or piece of software, then yes, it will have requirements and require tests. You should write those tests in whatever way you normally do and often those "proof of concept" spikes make it to production anyway, so you will be glad you did!

However, spikes are sometimes more along the lines of. "I've heard about a new software product that might be faster/better/helpful. can you go learn it and check out what it can do?" In this case there aren't any requirements, at least around the end product. The spike is a learning/training exercise.

Perhaps you have a "measure how fast this is compared to our current database" requirement or a "Determine if this will work on that OS" requirement, but they are more one off tests which might not fit with your usual "ensure the features all work as designed" style of BDD tests. So it would be foolish to insist they follow the same process.