アジャイルソフトウェア開発マニフェストは「包括的なドキュメントよりも動くソフトウェア」に価値を置いている。そうだとすると、どんな種類のドキュメントが、いつどれだけ必要なのだろうか？
Jonathan Berger氏はブログ記事、Minimum Viable Deliverableにおいて、設計判断を伝えることについて書いている。ドキュメントの利用について彼は次のように考えている。
アジャイルマニフェストは「包括的なドキュメントよりも動くソフトウェア」を推奨していますが、なぜ設計者はユーザが見ることのない中間生成物に時間をかけているのでしょうか？ アジャイルはムダを最小限にしようとしているので、論理的に突き詰めれば、あらゆるドキュメントはムダになります。このことは、ドキュメントを完全になくせる（あるいは、なくすべきである）ことを意味するのではありません。（ある程度の規模の）チームが機能するには、ドキュメントは必要です。しかしながら、ドキュメントを最小限にすることは良いことであり、設計者はできるだけ最小の作業で設計判断を伝えるべきだということを示唆しています。
どうすればドキュメントを最小限にできるのか、Jonathan氏は以下のように提案している。
1) チーム内に「中間生成物は少なければ少ないほど良い」という考えを広める
2) 今必要な最小限の成果物は何だろうか？と常に問いかける
Ashish Sharma氏はアジャイルの必要不可欠な、価値のある、タイムリーなドキュメントにおけるドキュメントと議論のバランスについてこう書いている。
アジャイルの目標は、ドキュメントと議論の適切なバランスを見つけることであるべきです。アジャイルであろうがなかろうが、ドキュメントはあらゆるシステムにおいて重要なところですが、包括的なドキュメントはプロジェクトの成功を保証するものではありません。実際のところ、失敗する可能性は高くなります。
そして、どれくらいドキュメントを書くべきか、いつ書くべきかを決めるのに使える3つの基準について述べている。
必要不可欠な: 必要十分なだけの詳細を含むようにドキュメントを書く。
価値のある: 欲しいときではなく、実際に必要なときだけドキュメントを書く。
タイムリーな: ドキュメントは必要なときに、ちょうど間に合わなくてはならない。
Michael Nygard氏はドキュメントに対するプロセスの観点について説明している。彼は目標を想像することから始めるよう提案する。
顧客不在のプロセスをよく見かけます。これはまったくのムダです。文字通り、だれもそのアウトプットを使っていないのに、作った人はそれを実感していないのです。
Michael氏が言うように、プロセスはインプットとアウトプット含めて、顧客視点で記述されるべきだろう。彼はそのために使える質問について説明している。
- 顧客はだれですか？
- 顧客は何を必要としていますか？
- あなたは顧客にそれをどうやって届けますか？
- あなたは顧客がその準備ができたときをどうやって知るのですか？
- あなたはそれをどうやって作るのですか？
- あなたがそれを作るのに必要なインプットは何ですか？
Tom de Lancey氏は2013年前半にLinkedInで、Emergent Documentation: One way that agile is very different from waterfallというディスカッションを始めた。
多くの人は、これまで使われてきた馴染みのあるドキュメントを捨て去るのを、非常に不安に思っています。システム要求、システム設計、ビジョンとスコープ、ユースケース、スキーマ、ワークフロー図、ラショナル統一プロセスの中間生成物などなど。すべてのドキュメントを5センテンスのストーリーに要約することに、多くの人は折り合いをつけることができません。
彼は「創発的ドキュメンテーション（Emergent Documentation）」と呼ぶドキュメントのアプローチについて説明した。
(…) どうすべきかまだわかっていないものをドキュメント化するのにムダな時間と労力を費やしたくありません。やろうと思っていることではなく、実際にやったことだけをドキュメントにするのです。
Tom氏はこの「創発的ドキュメンテーション」のメリットの1つをこう説明している。
ドキュメントは別のアクティビティではなく開発プロセスの一部になります。ドキュメントは実際に役に立つため、チーム全員がドキュメントの保守に関心を持つようになります。各ストーリーは個別のタスクを持ち、WIKI（各ストーリーに結びついたSharePointのサイト）で更新されます。
Mario Moreira氏はアジャイルの世界における適正な規模のドキュメントに関する記事を書いている。ソフトウェアプロジェクトが抱えていた、あるいは抱えている大量のドキュメントに対して、その適正な規模を次のように説明している。
適正な規模とは、ドキュメントを書いて保守するのにかかる労力に書かれたドキュメントの価値を加味したものが、その情報がすぐに使えないとき（すなわち、情報を再構築するのにかかる労力とその情報がなかったときに現在の判断へのインパクト）よりも投資利益（ROI）が大きいことを意味しています。。
この記事は適正な規模のドキュメントに関する指針となる。彼の提案をいくつか挙げておこう。
- ドキュメントは共同作業にすべきです。完全に一人が書いたものを他人にシェアするべきではありません。そうするのではなく、ドラフトのうちに頻繁にシェアしてインプットを得るべきです。
- ちょうど必要十分なだけのドキュメントにフォーカスしましょう。やる前から詳細に入り込むのは避けましょう。たいていの場合、これは多くの想定とムダな時間を意味します。ちょうど必要十分なだけとは、現在わかっていることをドキュメントにすることを意味します。
- ドキュメントはさまざまな形をとります。Wordだけでなく、Wikiやアジャイル計画ツール、コード中のコメントなど、いろいろなところにあります。
どのようにアジャイルでドキュメントを書いているだろうか？ どれくらい？いつ？