Rajesh Velliyatt氏には、それなりに経験のあるスクラムチームを2つ持っている。ひとつは米国に、もうひとつはインドにだ。時差があるのでテレビ会議に全員集まることはできない。交互に訪れるだけの出張費もない。そこで彼はこう尋ねた。このような場合、リリース計画はどうすればよいのだろうか？
Don MacIntyre氏は各チームに自分のバックログとゴールを与え、別々に計画することを提案している。PO（プロダクトオーナー）が遅かれ早かれ訪れて、それぞれのチームと会うことになる。しかし、最初のうちは対面のコミュニケーションの方が望ましいと彼は言う。
Vikrama Dhiman氏は次のようにしてうまく機能しているチームを見たことがあると言う。
1. チーム間の依存関係を最小化する。言うは易く、行うは難しだ。レガシーなアーキテクチャであれば、なおさらだ。
2. インドと米国のチームでオーバーラップする時間があるかチェックする（インドのチームを適切に配置する）。
3. 社内Wikiやメーリングリスト、マイクロブログといったコミュニケーションチャンネルを用意し、習慣を共有する。これには、日々のスプリントバーンダウンチャート（ホワイトボードのキャプチャ画像）や社内ポッドキャスト／ビデオ共有（および記録）アプリのような細部まで含まれる。もう一度言っておく: あらゆるところで習慣を共有しよう。
4. 両方のチームを安定させる。頻繁に変えてはいけない。
彼はまた、フレックスタイムと在宅勤務を考えると、これはオフショア化したチームだけの問題ではないと述べている。
Ted St.Clair氏も同じ問題に直面していた。チームにはひとつのバックログがあり、ひとりのPOがいる。1週間のスプリント作業には、毎週、バックロググルーミングセッションがある。グルーミングセッションには、POとともに米国とインドの両方からメンバが参加する。米国チームはインドにもメンバがひとりいて、その人がコーディネイター役を果たす。このコーディネイターと米国のスクラムマスターは、インド側の計画とふりかえりに参加する。結局のところ、リリース計画の間に、彼らは完成までひとつのチームで取り組めるような大作を確認しようとする。
Hubert Smits氏の経験では、各チームがそれ自体フィーチャチームになっており、お互いに独立した重要な仕事をしているときに最もうまく機能するようだ。しかし、彼は一緒に依存関係を見つけて問題を解決するのが、やはり一番よいと思っている。
実際にやってみると、Eric Lefevre氏は、Webカムとテレビ電話会議を自分のチームにセットアップするのはあまりに面倒だとわかったそうだ。結局、チームはそれを使うのをやめてしまった。
個人的意見: 計画を作ることの明らかな利点とは別に、リリース計画には別の目的もある。: チームメンバ間の信頼を築くこと（新しいチームや分散したチームには実際の問題だ）と、共通理解を築くことだ。この報告者にとって、これらの提案のいずれかがこの2つのポイントにどう貢献するかはわからない。
InfoQの以前の記事: 事例研究：Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト, Agile Distributed Development Done Right Using Fully Distributed Scrum and sPlanning and Maintaining the Rhythm of Distributed Scrum