バックログはこれまでかなりの期間、批判にさらされている。リーンでは目録であり無駄であるとみなされている。Mary Poppendieck氏(リンク)は、もし求められる目的にそぐわないであれば、プロダクトバックログは排除するべきである(参考記事・英語)とまで言っている。同様の方向性でJeff Patton氏(リンク)は、フラットなバックログはシステムの高いレベルのビューを伝えるのに失敗していると述べた。彼は代わりにストーリーマップを使うこと(リンク)を提案している。
Jeff氏の意見では、アジャイルチームが直面する最も一般的な問題の一つは、すぐに全体像を見失ってしまうことである。その理由は、構築中のシステムを完全に無視してストーリーがアレンジされるというやり方にある。Jeff氏は興味深い例え話を引用した。
「私たちは多くの時間をかけて顧客と一緒に作業をします。私たちは彼らの目標やユーザ、そして私たちが構築可能なシステムの主要な部分について理解するために一生懸命働きます。そして私たちは最後に、詳細 - 私たちが構築したいと思っている機能の断片 - に取り掛かるのです。私の頭の中には木が見えていて、幹はシステムを駆動する目標あるいは望ましい利益で構成されます；大きな枝はユーザです；細い枝や小枝は必要とされる性能です；そして最後に葉っぱは、開発のイテレーションに入れられるくらい小さなユーザ・ストーリーです。」 「私たちは多くの時間をかけて顧客と一緒に作業をします。私たちは彼らの目標やユーザ、そして私たちが構築可能なシステムの主要な部分について理解するために一生懸命働きます。そして私たちは最後に、詳細 - 私たちが構築したいと思っている機能の断片 - に取り掛かるのです。私の頭の中には木が見えていて、幹はシステムを駆動する目標あるいは望ましい利益で構成されます；大きな枝はユーザです；細い枝や小枝は必要とされる性能です。そして最後に葉っぱは、開発のイテレーションに入れられるくらい小さなユーザ・ストーリーです。」
「その作業の後で、共通の認識がすべて確立された後で、私達は木から全ての葉を取り去って袋につめるような気がします - それから木を切り倒すのです。」
「これが私にとってのフラットなバックログです。コンテキストのない覆いのバッグです。」
Jeff氏はバックログの代わりにストーリーマップを使うことを提案した。ストーリーマップは次のようなものである。
マップの一番上には大きなストーリーかアクティビティがあり、それはユーザがシステムと対話するときに行うことである。アクティビティの並び順はユーザがシステムと対話する順番である。アクティビティの下にはユーザ・タスクがある。これらはユーザがアクティビティを達成するために行うタスクのコレクションである。例えば、Eメールの管理がアクティビティの場合、「メッセージを送信する」、「メッセージを読む」、「メッセージを削除する」、「メッセージをスパムとしてマークする」等がユーザ・タスクである。
Jeff氏は、マップ上のアクティビティはシステムの背骨でありタスクはあばら骨である、とつけ加えた。この考えは、背骨を優先的に扱わないというものである。なぜなら、それは基盤でありシステムはそれにかかっているからである。しかし、ストーリーには優先順位をつけなければならない。全ての計画は背骨に基づいて行われなければならないし、それはあばら骨を成すユーザタスクの優先順位を決めるのに役立つ。
ストーリーマップを用いるメリットは、全体像が中心的なテーマとなることである。これは別として、その他のメリットとしてJeff氏が述べたのは、
私はユーザやステークホルダ、あるいは開発者とともに最初から最後までマップをたどり、システムのユーザに関する話や彼らが行っていることについて話すことができます。マップの一番上に沿ってざっと目を通すことができ、ハイライトだけに触れます。詳細を議論するため、マップを掘り下げることも出来ます。
ユーザやその他の人たちとマップを使って話すことによって、見落としていたことに気付きます。これを行っていると私はよくユーザから「ここで２～３のステップ見落としていますよ」と言われます。
マップには苦痛を感じる点や機会について注釈をつけることができます。私はマップを通してユーザと話をすると、よくこう言われます。「まさにここが今のシステムで問題となっていることです。」
このように、ストーリーマップはチームが構築中の製品に常に集中するのに役立つ。マップは、チームが木を見て森を見ず、とならないように支援する。
原文はこちらです：http://www.infoq.com/news/2009/02/backlog-lacks-backbone