Joelに対するAviDのコメント/質問への回答：
したがって、次のバージョンで10個の新機能が登場し、各機能を実装するために5つのタスクが必要な場合は、10個のリリースを作成することをお勧めしますか？そして、これらが次のリリースに含まれる予定の機能/「リリース」であることをどのように定義しますか？
開発プロセスでこの特定の問題にどのように対処したかを次に示します。
- まず、定期的なリリーススケジュールを作成しました。月次の内部リリースと四半期ごとの外部リリースです。このスケジュールは変更されませんが、タスクの割り当て/機能の完了は変更されます。これは、人間間のコミュニケーションを簡素化するという点で非常に重要です。カレンダーについて議論しようとしないでください。
- 主要な機能（例では「10個の新機能」）がケースに変換されます（例：ケース101からケース110）。
- 主要な機能のサブコンポーネントである各タスクも、この作業のチャンクを全体像の重要な部分にする理由の説明を含むサブケースとして作成されます。以前、Fogbugz 6では、テキストを検索できるようにすることで「関連項目」機能を使用していました（たとえば、「これはケース101のサブコンポーネントです」）。これは事実上同じことでしたが、美的ではありませんでした。
- 作業を最高レベルの有用性に分解したので、実際の開発者を議論に参加させます。各タスクと主要な機能は、特定の開発者に個別に割り当てられます。
- 開発者は、コミットできると思われる適切な内部リリース日を選択することにより、割り当てられた作業をいつ完了できるかを決定します。
- この時点で、各リリースで何が行われるかについての大まかなスケッチがあります。働く人々が実際に仕事をするのに必要な時間を見積もり、証拠に基づくスケジューリングなどを可能にするにつれて、さらなる改良が続けられます。
ただし、AviDの質問については、上記の手順5でリリース割り当ての問題を解決する必要があります。
ただし、ポイント6が最も興味深いと思います。それは、実際に確実なスケジュールが得られる場所だからです。たとえば、開発者がより大きなタスクを見積もるのに問題がある場合、開発者はそれをさらにサブケースに分割します。「最高レベルの有用性」の私の評価が、実際に仕事を成し遂げる必要のある人と（おそらく大きく）異なる可能性があることに注意してください。
これは、開発者が他の誰かに連絡して「これのほとんどはできるが、Xさんがこの小さなピースYを手伝ってくれると本当に助かる」と言うことができる時期でもあります。これは実際に私が開発タスクのほとんどを行う場所です。私はこのプロセス中に、大規模な計画会議から他の誰もする時間がない少し厄介なタスクまで、個人的に複数の場所に座っています。
PS：この回答をジョエルの回答よりも高く評価することを個人的な目標にしています...;-)
PPS：Fogbugz 7には素敵なサブタスクがあるので、私の元の応答はイベントによって克服されました。プログラムマネージャーはこれらのレポートが大好きです。