プロダクトバックログの体系化は，ユーザストーリの概要を把握し，全体像を見るためには有効な方法だ。Shrikant Vashishtha氏のブログ記事 ストーリマッピングとプロセスマップ (story mapping and/vs process maps) には，ユーザストーリをプロセスマップにマッピングするための方法が説明されている。その記事で氏は，ユーザストーリを体系化するための方法としてのプロセスマッピングアプローチを，Jeff Patton氏の提唱するストーリマッピングと比較してみせている。
スクラムでのプロダクトバックログは，プロダクトに対するニーズを管理するために使用するものだ。 大規模なプロダクトの場合には，バックログに多数のユーザストーリが登録される可能性がある。そうなると概要をまとめたり，全体を把握する作業が困難になる。さらにはユーザストーリの数が多くことによって，チームのスプリントバックログにも同じようなことが起きる可能性もある。
(...) 何回も壁の掲示板 (スクラムボード) を見るのですが，状況はちっともクリアになりません。ToDo，進行中，完了というステータスを書き込んだユーザストーリで埋められて，まるで網目のようです。しかも重要な問題の中には，ユーザストーリを見るだけでは答が得られないものもあるのです。
プロダクトバックログの体系化とユーザストーリの視覚化を行う手段としてVashishtha氏が提案するのは，プロセスマッピングの実施だ。
ビジネスフロー全体をプロセスマップとして図示して，その中にユーザストーリ (実施すべき仕事) を関連付けてみてはどうでしょう？
プロセスマップにはユーザストーリのIDを記入する。このIDは，プロセスの各部分を実装するために使用されるものだ。プロセスマップを見れば，ビジネスフローに必要なユーザストーリを確認することができる。色分けをすることで，ビジネスフローの進捗を可視化することも可能だ。
大規模なプロダクトバックログを体系化するもうひとつのアプローチはストーリマッピングだ。Jeff Patton氏の2008年の記事 新たなユーザストーリバックログとしてのマップ (the new user story backlog is a map) にその説明がある。
実施順に並べられたユーザストーリは，システムの目的を第３者に説明するための役には立ちません。"開発中のシステムは何をするものですか？” と関係者やユーザから質問されたときは，ユーザストーリバックログを彼らに渡してみてください。私の考えでは，システムを – システム全体を理解しようとすることは，ソフトウェア開発の困難な部分のひとつです。アジャイルチームでもっともよく聞かれる苦情のひとつは，全体像を見失ってしまう，という点です – 最初に全体像が見えていたならば，という条件はありますが。
氏は全体像を伝える手段として，ストーリマッピングがいかに有効かを説明する。
情報の拡散手段として張り出されたストーリマップが，開発しているプロダクトを議論する上での出発点として利用できることに気付いたのです。プロジェクト進行中は，スプリントやイテレーションの計画ボードとしても使えます。次のイテレーションで開発するストーリをマップ上で確認したり，チェックを入れたりするのです。イテレーション中は，現在行っているストーリをタスク表に移動して，開発管理を行います。その時にもストーリマップは計画表に残っていますので，全体像や現在の位置を確認することができるのです。
InfoQでは以前にも，ストーリマップがプロダクトバックログの体型化に役立つというテーマで，ストーリー・マッピングによるユーザ・ストーリーへのコンテキスト付与 という記事を書いている。
ストーリー・マップは2次元であり，ストーリーの優先度に加え，ストーリー間の関係やユーザのより大きなゴールとの関係も表しています。このマップは，いかにストーリーを組み合わせてリリース可能な製品を形成するか，チームが理解するのに有効です。
Shrikant Vashishtha氏は，プロセスマッピングの効果を説明した ストーリマップとプロセスマップ (story mapping and/vs process maps) の後，プロセスマッピングとストーリマッピングを比較した記事を自身のブログに載せている。その中で氏は，プロダクトバックログがストーリマッピングによってどのようになるか，次のように述べている。
ストーリマッピングのアイデアは，プロダクトバックログをマップ上の "ビッグストーリ" ("ユーザアクティビティ"，エピック，フィーチャなどとも呼ばれる) で表現する，というものです。ビッグストーリはさらに，ユーザタスク (誰かが達成すべき何か) に分割されます。
ストーリマップを使用した経験から，氏はいくつかの欠点を指摘する。
ストーリマップは優れた情報拡散手段ですが，リリース全体のストーリを表すとなると，必要なスペースが大きくなりすぎるかも知れません。またストーリ間の関係や，ビジネス上の目標を達成するためにエピック/ストーリ全体がどのような編成になっているか，といった情報については，必ずしも表現することができないのです。
ストーリマップでは全体像を把握することが難しいほど複雑な場合は，プロセスマップの助けを借りるとよい，と氏は指摘する。プロセスマップではすべての詳細部分を示していないからだ。
すべてのストーリをボードに置く代わりに，プロセスマップの大きなポスターを貼りだして，ユーザストーリのIDを配置するのです。プロセスマップ自体が背景図の役割も果たして，皆で同じページを参照したい場合には役立つでしょう。
結論として述べられているのは，大規模なプロダクトバックログの体系化にはプロセスマップとストーリマップのいずれも利用可能である，ということだ。
(...) プロセスマップとストーリマップは，同じ問題を解決するためのまったく違うコンセプトに思えるかも知れません。しかし，そうではないのです。どちらもボードを明確にするためのツールであり，コンテキストに対応して，お互いを補完し合うものとして利用できます。
ユーザストーリマッピング - 目標駆動バックログ開発 (user story mapping―goal-driven backlog development) と題したブログ記事には，Scott Sehlhorst氏によるストーリマッピングの概要説明がある。最初に氏が示しているのは，その目的だ。
ユーザストーリマッピングは，リリースあるいはイテレーション毎に製品が確実によくなることを保証するためのテクニックです。(...) ユーザストーリマッピングには，問題解決のためにユーザが実行している，あるいは実行しようとしているプロセスと，ユーザが目標を達成するためのバリューチェーンやワークフローの明確な理解が必要です。
さらに氏は，ストーリマッピングを行う方法と，それによるメリットについて説明する。
ユーザストーリマッピングによって，グループが実行するユーザストーリあるいはタスクを組織化し，価値提供のために実行すべき要件全般を特定することが可能になります。要件の 網羅性 を評価する上で，これは強力なテクニックです。さらに，ユーザが問題を解決，ないしはより効率的に解決可能にすることにより，各リリースあるいはイテレーションが価値を付加することを保証するためのツールにもなります - 問題の解決半ばでの提供を防止できるのです。
読者はストーリマップ，あるいはプロセスマップを使ったプロダクトバックログの体系化を行っているだろうか？それらは概要を把握し，全体像を見る上で役に立っているだろうか？