いくつものチャネルのさまざまなチームがプロダクトに関与している場合，エピックの管理や追跡はどのように行えばよいのだろうか？ Sntio LLC創業者のひとりであるKaren Deer氏は先日のブログで，複数のチャネルにわたるエピックの管理について論じている。
氏が例として挙げたのは，複数のワークストリームと技術チーム，販売担当チームを，ひとりのプロダクトオーナが管理するプロジェクトだ。それぞれのチームは独自のワークフローやタイムラインを持ち，ステークホルダたちからの入力とフィードバック，支援を別々に得ている。
複数のチャネルにわたるプロダクト開発には困難が伴います。その一方で，クラウドによってますますネットワーク化される世界では，ユーザの希望するプロダクト – 携帯電話やタブレット，ウェアラブルデバイスを対象とする製品の提供が不可欠です。
このようなタイプのソリューションを管理するために，氏はいくつかの戦略を挙げる。
- エピックのレベルで可能な限り詳細を把握し，全体像を獲得しておくこと。チャネル間の重複を避けるためには，より多くの情報を収集しておくことが重要です。
- 依存性の計画を立てておくこと。複数のチームで作業を同期する必要があるのならば，各チームのバックログを整理して，チーム間の依存関係と整合性を持たせるようにしてください。
- 他チームからのストーリ取り入れを排除あるいは最小限にすること – 結果的にすべての機能要件を達成できなくなる可能性が常に存在します。一方のチームは順調であっても，別のチームは他の作業に掛かりきりかも知れません。これは，難しい決定を下さなければならないシナリオです。 どのようなトレードオフを取るべきなのか，データやマーケットリサーチが教えてくれるでしょう。
Jira Agile 6.3には，複数のプロジェクトにわたるエピックの管理機能がある。Atlassianのシニア・アジャイルエバンジェリストであるDan Radigan氏は自身のブログ記事“Project portfolio management with JIRA Agile”にこのシナリオを説明している。
あなたのエピックに，複数のJIRAプロジェクトからのイシューはありますか？ もしそうならば，プログラムマネージャは，カンバンボードで使っているものと同じJQL文の"シャドー"スクラムボードを用意する必要があります。このスクラムボードからのエピックレポートを，すべてのプロジェクトからのイシューを含むものとして使用してください。ひとつのプロジェクトに限定された"チームの"スクラムボードを使用しているのであれば，エピックレポートにはそのプロジェクトのイシューしか含まれません。
いくつかのスクラムボードのエピックを横断的に管理する機能を持ったツールは，他にもいくつかある。スクラムボードをひとつのワークフロー専用にすることができればよいのだ。YouTrackは，ボードに関連するすべてのプロジェクトのエピックを生成可能なツールだ。エピック用のボードを用意して，‘Epic’タイプのイシューで定義されたスイムレーンを設定する方法もある。そうすることでエピックがマネージャボードの最上位レベルに配置されると，氏のブログ記事 ”Multi-Level Agile Boards or How We Support Epics“には説明されている。
GE Softwareでアジャイルリーダを務めるTom Looy氏は“The Great Wall”として，マルチチームプロジェクトへのアジャイルのスケールアップについて述べている。
このGreat Wallは最初，ソリューションのユーザエクスペリエンスマップ(User Experience Map)を物理的な壁に貼り出すところから始めます。最初のマップはユーザの視点で構成して，ユーザストーリをマップの左から右に向かって読むことで，ユーザのストーリを把握できるようにします。その後，マップ上のユーザストーリの優先度をベースにして，MVP(Minimal Viable Product)に階層化するのです。この階層がそれぞれ，製品のリリースに対応します。
Great Wallの構築，すなわち，物理的なユーザストーリマップとプロジェクト管理のツールを全チームがアクセスできる重要な場所に設置することは，氏が述べたような状況通知と管理のためのツールであると同時に，デリバリを最適化する手段としても優れている。