ソフトウェアプロセス、設計プラクティスなどについて、多くの感情的な議論を見かけます。ソフトウェア業界は、ソフトウェア開発の有効性の基本的な要素を測定する能力を欠いているため、これらの議論の多くは解決不可能です。特に、生産性を合理的に測定する方法がありません。

5ポンドの袋に10ポンドの糞を入れることはできません

— 試したことがある人なら誰でも

ケントと私が『エクストリームプログラミング計画』を書いたとき、計画の本質を理解するのに役立つ、この風変わりな引用句を含めました。

多くの人は、アジャイルプロジェクトで固定価格契約を行うことはできないと考えています。アジャイルプロセスのポイントは将来を予測できないことであるため、これは不合理な推測ではありません。しかし、これは固定価格のアジャイル契約を結べないという意味ではありません。実際には、固定範囲の契約を結べないという意味です。

多くの企業は、範囲と価格を固定する契約を締結するという考えが好きです。なぜなら、それがリスクを軽減すると考えているからです。蜃気楼は、彼らの財政的義務が取引価格で固定されていると言っています。満足のいくソフトウェアが得られなくても、費用はかかりません。

理想時間は、初期のエクストリームプログラミングで使用されていた、工数の見積もりに役立つ用語です。ストーリーポイントまたはストーリーカウントに取って代わられています。

アジャイルソフトウェア開発に初めて関わったのは、エクストリームプログラミングの黎明期にケント・ベックと仕事をしたときでした。そのプロジェクトで感銘を受けたことの1つは、私たちが計画を進める方法でした。これには、軽量でありながら、私がそれまで見たものよりも効果的な見積もりアプローチが含まれていました。10年以上が経過した現在、経験豊富なアジャイリストの間で、見積もりの価値があるかどうか、あるいは実際に有害かどうかについて議論があります。この質問に答えるには、見積もりがどのような目的に使用されるかを検討する必要があると思います。

時間制限のあるイテレーションにおける一般的なアプローチは、関係するスタッフの利用率を最大化するために、可能な限り多くのユーザーストーリーを各イテレーションに割り当てることです。余裕とは、ストーリーに割り当てられていない時間を意図的に残し、その時間を計画外の作業に使用するポリシーです。非効率的に見えるかもしれませんが、通常、チームの生産性が大幅に向上します。

最近、エクストリームプログラミングの計画アプローチを使用する複数のチームで標準的なストーリーポイントメカニズムを考案することについて、いくつかの質問を受けました。複数のチームが同等のストーリーポイントを使用することを期待しており、あるチームの3ストーリーポイントの労力は、他のチームの3ストーリーポイントと同じになります。

これは、せいぜい限定的な価値しかなく、最悪の場合危険です。

ストーリーカウントは、計画と見積もりの手法です。ストーリーポイントと同様に、XPベロシティを使用して、一定期間に配信できるストーリーの数を把握するのに役立ちます。ただし、時間単位あたりのストーリー数だけを考慮し（ほとんどの場合）、それらの相対的なサイズは無視するという点が異なります。

ストーリーポイントは、アジャイルプロジェクトでストーリーのサイズを決定するための一般的な名称です。XPベロシティと組み合わせることで、ストーリーがいつ完了できるかの予測を提供し、計画を支援する手法となります。

XPスタイルの計画を使用している場合、開発者から迅速に合意の見積もりを取得する必要があります。見積もりを「投げる」ことで、開発者が見積もりについて同様の見解を持っているかどうか（したがって、それを記録して先に進むことができます）、または意見の相違があるかどうか（ユーザーストーリーについてさらに詳しく話し合う必要がある場合）を迅速に判断できます。

ベロシティは、工数の広範な記述を経過時間に結び付けることで計画を調整するのに役立つ概念です。ベロシティとは、チーム（または個人のベロシティの場合は個人）が一定期間にどれだけ多くの作業を完了するかを示すものです。昨日の天気の原則に従って、過去の期間にどれだけ多くの作業が完了したかを測定することで、通常はベロシティを決定する必要があります。一般的なアプローチとしては、過去3期間のベロシティを平均して、将来の期間のベロシティを決定します。ベロシティはもともとエクストリームプログラミングの一部として形成されましたが、それ以来広まり、現在ではあらゆる種類のアジャイルソフトウェア開発で広く使用されています。

これは、今日完了する作業量は昨日完了した作業量と同じになるという原則です。イテレーティブなプロジェクトでは、今回のイテレーションで前回のイテレーションと同じくらいの作業を計画する必要があることを示しています。この用語は、エクストリームプログラミングコミュニティから来ています。