アジャイルは我々にとって，事前の正確な要件定義という呪縛から解放して，もっと小さな目標に対して作業できるように支援してくれる。それでもなお，たとえ短いスプリントであっても，プロセスの終盤には多数の発見と誤解が生まれ，多くの無駄が発生する – Matt Wynne氏は先頃，BDD (Behavior-Driven Developmen, 振る舞い駆動開発) を要約する中で，このようなことを述べている。
Cucumber (オープンソースのBDDツール) の開発リーダでもある氏は，さらに説明する – BDDが改善を試みる最大の課題は，問題領域とソリューション領域で働く人々の間のコミュニケーションである。この２つの領域の間に共通理解領域を作り出して発展させることで，共通の言語，すなわちDDD (Domain-Driven Design, ドメイン駆動設計) の定義する遍在的な言語を生み出すものなのだ。
ユーザストーリ (User Story) は，要求機能記述を支援するアジャイルツールである。実装に先立ってストーリをより深く理解するため，BDDでは具体的な例を使用して，その機能がどのように使用される予定なのかを説明する。それはまた，修正に多くの費用を必要とする後半ではなく，より初期の段階において境界条件を発見するための安価な方法でもある。
問題領域探索のために事例に注目するというBDDによって得られるアドバンテージは，ユーザやステークホルダから開発者やテスタに至るまで，誰もが作業に関与できることである。事例とするのはテクニカルな内容に限らない。基本的にはペンや紙といったものがあればよいのだ。
ソリューション領域に目を移すと，氏が体験したことは，プロジェクトの発展に伴ってコードベースに変更を取り入れることがますます困難になることが多い，という事実だ。氏はここで，コードベースをキッチンとを比較して見せる – 整理されて清潔なキッチンならば，品質の高い料理を作るのは簡単なことだ。そのようにキッチンを清潔に保つには，食器洗いや片付けなどをいつも行わなければならない。プロフェッショナルの作業環境にも，これと同じ戦略が必要だ。コードベースにおいて，キッチンの食器洗いに相当するのがリファクタリング – 動作に影響を与えずに設計を変更する – である。コードベースが多少整理される上，理解や変更も少しやりやすくなる。
リファクタリングで動作が変わっていないことを確認するためには，自動テストが必要となる。例えばテスト駆動開発(Test-Driven Development, TDD) やBDDでは，どちらも要件を明確化する手段として例を使用している。
コードがクリーンでなければ，もはやアジャイルではない
BDDは2006年頃，Dan North氏によって開発された。氏はBDDを紹介する文書や，BDDの立場から見たストーリについて記事を書いている。
さらに，BDDとも深く関連した例示による仕様(Specification by Example)という仕様定義手法もある。
CucumberはBDDのためのオープンソースツールで，JVMベースの言語を含む９つのプログラム言語に移植されている。企業向けの新バージョンであるCucumber Proがリリースされたばかりだ。