Acceptance Test Driven Planning and How BDD Builds on It

Acceptance test driven planning is the practice of agreeing the acceptance tests for a piece of work before that work is estimated and scheduled, rather than after it is specified or after it is built.

Dan North names it explicitly when describing what behaviour driven development is: an evolution in the thinking behind test driven development and acceptance test driven planning, brought together into one practice.

What moves when the tests come first

The usual sequence is describe, estimate, schedule, build, then write acceptance tests. Each step in that chain interprets the one before it, and by the time the tests are written the interpretation has happened four times.

Putting the tests at the front collapses the chain. The concrete cases become the description, so there is nothing to interpret, and the estimate is made against them rather than against a sentence.

Why estimates improve

An estimate against a description is an estimate against whatever the estimator pictured. Two developers reading customers should not be able to overdraw will picture different amounts of work, and neither is wrong, because the sentence does not contain the answer.

Agreeing the cases first removes most of that variance. It also reliably reveals that some work is really two pieces: the moment the cases are enumerated, one of them turns out to need a decision nobody has made, and it can be separated rather than discovered mid-sprint.

The planning conversation is the same conversation

In practice acceptance test driven planning and the BDD conversation are the same meeting held for two purposes. The examples that come out of it serve as the acceptance criteria, the specification and, once automated, the regression suite, and they also serve as the basis for the estimate.

This is why the distinction between ATDD, acceptance test driven planning and BDD is largely one of lineage. The mechanics converge. What BDD adds on top is the insistence on the vocabulary: the examples have to be written in words the business already uses, or the audience that was supposed to check them cannot.

Where it does not fit

Work whose shape genuinely cannot be known until some of it is done, such as an investigation or a spike, has no acceptance tests to agree, and forcing some into existence produces tests that describe a guess. The honest move there is to time-box the investigation and plan the real work afterwards, when there is something to write examples against.

It also fits badly where the person who can answer the questions is unavailable. The practice assumes somebody in the room can settle what should happen at the boundary. Where that person is a committee, or is booked three weeks out, the team either waits or guesses, and a guess written as an acceptance test is worse than an open question because it looks settled.

What it changes about scheduling

Two things, and the second is the one teams notice.

Estimates get tighter, because the variance that came from differing mental pictures is gone. That is the expected benefit.

Less expected: the order of work changes. Once the cases are on the table it often becomes obvious that one of them is worth delivering on its own and the rest can wait, or that a piece everyone assumed was small contains the only genuinely difficult decision in the release. Neither is visible from a one-line description, and both change what gets built first.

A note on who writes them

Whoever is in the conversation, jointly, and not the tester alone. Acceptance tests written by one role are that role’s understanding of the work, which is precisely the artefact the practice is trying to replace.

How it interacts with estimation practice

Teams that estimate in points rather than time sometimes assume this changes nothing, since points are meant to capture uncertainty already. In practice it changes the conversation underneath the number.

An estimate made against a description is partly an estimate of how much is unknown. Once the cases are written, that component shrinks, and what remains is closer to a judgement about implementation effort. The number gets more stable, and more usefully, the residual disagreement between two estimators becomes a specific technical question rather than a difference in imagination.

The second effect is on scope negotiation. A stakeholder looking at eight concrete cases can say which three matter for the first release, which is a conversation that cannot happen against a single sentence. Work gets smaller far more often than it gets bigger.

The failure mode to watch for

Writing the acceptance tests as a deliverable rather than as a conversation. Where a business analyst produces them alone and circulates them for sign-off, the artefacts look identical and none of the value is present, because the misunderstanding they exist to surface was never given the chance to appear. The signature of this is sign-off arriving quickly and without questions.