製品バックログをプロジェクトのフレームワークに適合させる方法
まず、製品バックログを明確に定義しましょう。スクラムでは、プロジェクトをスプリントと呼ばれる一連の集中的な作業期間に編成します。各スプリントの期間は通常 2 週間です。スプリントの開始前に、チームとスクラム マスター (コーチのような存在) が、スプリント バックログを作成します。これは次のスプリントで達成しようとしている内容のリストです。
スプリント バックログは、規模のより大きい製品バックログから選択することになります。製品バックログは、製品に追加する必要のある機能をすべて網羅したリストです。製品オーナーが製品バックログの優先順位付けを担当します (また、製品オーナーは顧客やその他の関係者のニーズを代表し、開発チームの作業を指導します)。製品バックログは、最も重要なタスクが上に来るよう順番にランク付けされます。通常、スクラム チームが優先順位に基づきこのバックログから項目を選択します。製品バックログは、ユーザーの要求、ビジネス ニーズ、広範囲にわたる技術のトレンドに基づき、時間とともに変更を加え、進化させていきます。
また、製品バックログは、かんばんと呼ばれる別のアジャイル フレームワークで活用することもできます。かんばんは、期間の固定されたスプリント (スクラム) を使用せず、進行中の作業 (WIP) を限定することが基本となっていますが、この記事の情報はかんばんプロジェクトにも応用できます。
製品バックログを適切に構築することで、業務の生産性と価値を確保できます。また、製品が顧客のニーズに合致し、組織の目標とも一致するようになります。製品バックログは、個人の「To Do」リストと同様、継続的な管理が必要です。このプロセスは製品バックログの「改良」や「手入れ」と呼ばれることがよくあり、タスクが完了したり、アイデアが破棄されたりしたら優先順位を変更して更新します。このようにしてバックログの更新を行わなければ、内容が整理されず、予定通りの進行が困難になります。
最初の製品バックログを作成する
アジャイルの専門家の中には、製品バックログを作成する際は、まず製品ロードマップから始めることを推奨する人もいます。これは、製品の長期的な見通しを示す戦略的プランニングです。アジャイル製品管理のエキスパート トレーナーである Roman Pichler 氏は、製品オーナーとマネージャーが、ロードマップにおいて機能の詳細に注目しすぎて全体的なビジョンに注意が及ばないことが多いと言っています。同氏は、目標達成に必要な製品の目標と機能を重視した、目標指向のロードマップ テンプレートを開発しました。
ロードマップには複数のリリースの長期目標が含まれる場合がありますが、製品バックログでは次回リリースの作業をより詳細にリストすることに重点を置く必要があります。将来のリリースについてはより下位に配置し、詳細な記述は避けるようにします。次に、ロードマップから得た情報を、タスクと作業項目に置き換えます。
製品ごとに独自のバックログが必要です。製品の規模が非常に大きい場合、または相互に関連する製品スイートの一部である場合は、製品を構成する要素の判断が困難になる可能性があります。Innolution (イノリューション) のコンサルタントを務めるアジャイルの専門家、Kenneth Rubin 氏は、コンポーネントのチーム数とコンポーネントのバックログを最小限に抑えることが目標だと言っており、可能であれば使用するバックログを 1 つにすることを選びます。しかし、数十または数百のチームを抱える非常に大規模なプロジェクトの場合、これは現実的ではありません。そのような場合には、大規模な機能用のバックログを 1 つと、関連する作業領域ごとの個別のバックログを備えた、階層型バックログが役立ちます。
ユーザー ストーリーは製品バックログの中心
製品バックログの作業項目は、多くの場合ユーザー ストーリーと呼ばれます。これはユーザーの観点から機能がどのように動作するかを説明したものです。ユーザー ストーリーの規模は小さく、スプリント内で完了できる程度になっています。
Fidelity Investments (フィデリティ投信) でチームのトレーニングを担当したアジャイル コーチ、Chuck Kroll 氏は、ユーザー ストーリーに従来の公式を当てはめることを推奨しています。Kroll 氏によれば、「自分は (顧客などのユーザーのタイプ) として (この理由) により (この目標) が必要である」という形になります。「こうすることで、誰がその機能を使用するのか、その機能に何が必要か、それがどのようなビジネス価値をもたらすのかが明確になります」。
ユーザー ストーリーとユーザー エピックの比較: バックログ項目はどの程度詳細にすべきか
さらに規模の大きいストーリーは「エピック」と呼ばれ、達成するには複数のスプリントが必要になる場合があります。エピックは、作業開始前にストーリーに分割する必要があります。
アジャイルおよびスクラムのトレーニングを提供する Mountain Goat Software (マウンテン ゴート ソフトウェア) の創設者である Mike Cohn 氏は、エピックについてこのような例を提示しています。この例では、ホテルを経営するある企業で、同業他社の料金やシーズンなどの変数に従って客室の最高料金を決定するシステムが必要になっていました。「ホテルの運営担当として、ホテルの客室に最適な料金を設定したい」。これは、「ホテルの運営担当として、前年の価格設定に基づいて客室の最適な料金を設定したい」や「ホテルの運営担当として、自社と同等のホテルの料金設定に基づいて客室の最適な料金を設定したい」などのユーザー ストーリーに分割できます。
製品バックログのユーザー ストーリーを準備する際は、チームが正確に実行できるように、優先度の高い項目に詳細な内容を含める必要があります。この内容には、機能のワークフローを示す図やその細部の説明などが含まれます。
「これは見過ごされがちですが、最も重要なアドバイスは、製品バックログの項目すべてに同じレベルの詳細情報が必要なわけではないということです」と Cohn 氏は言います。「次のスプリントに関わる項目には、適度に詳細な説明が必要です。時間的に遠くなればなるほど詳細度を下げ、より大まかな情報にとどめます」。
次のようなユーザー ストーリーを考えてみましょう。「Web サイトの閲覧者として、第一希望または最寄りの空港で最安値の航空券を買えるようになりたい」。この内容は製品バックログの上位に近いため、ユーザー ストーリーに詳細を追加する必要があります。例えば、関数で半径 150 km 以内のすべての空港の運賃をチェックする、運賃を第一希望の空港からの距離と価格で並べ替える機能を提供する、といった作業が必要です。
Pichler 氏は、製品バックログをどの程度詳細にするかを決める際には、製品ライフサイクルを重視することを推奨しています。新しい製品の場合、バックログは短く、詳細度は低くするべきです。こうすることで、新しいアイデアを試行し、製品を頻繁に更新して、最適化できるようになります。一方、より古く、より安定した製品の場合は、バックログを詳細にすると製品がどのように進化するかをより正確に予測できるようになるため、より多くのメリットが得られるようになります。
製品バックログのもう 1 つの要素としてリリース サイクルがあります。新しいバージョンや大規模リリースの作業を開始すると、不明な点が増え、判明した内容によってバックログに大きな変更が生じる可能性があります。そのため、リリース サイクルの初期段階では、製品バックログを短く、詳細度の低いものにするのが合理的だと Pichler 氏は説明しています。
Industrial Logic Inc (インダストリアル ロジック) を顧客とするアジャイル コンサルタント、Bill Wake 氏は、優れたユーザー ストーリーの特性を考案しました。これは広く使われるモデルで、覚えやすいように頭文字を取って INVEST と呼ばれています。
I (Independent、独立性): ストーリーは重複するべきではなく、どのような順序であっても実装可能とするのが理想的である。
N (Negotiable、交渉可能): ストーリーは本質を抑えているが詳細までは含まない。詳細は参加者の合意を必要とする。
V (Valuable、価値を持つ): ストーリーは顧客に明確な価値を提供する。
E (Estimable、見積もり可能): 関係する労力を見積もることができる。この見積もりには時間単位か、ストーリー ポイントと呼ばれる、相対的な複雑さを評価する任意の測定単位 (XS/S/M/L/XL、1/2/4/8/16 など) を使用します。
S (Small、小規模): 「優れたストーリーは小さくなる傾向があります」と Wake 氏は言います。つまり、ストーリーは、専任の担当者が (最大でも) 週 40 時間の作業で数週間のうちに完成させるか、チーム メンバー間で分担する必要があります。
T (Testable、検証可能): IT 検証プラットフォーム ReQtest (リクテスト) の創設者兼製品オーナーである Ulf Eriksson 氏によれば、ユーザー ストーリーは、何らかの形で測定可能または実行可能である必要があります。
製品バックログに含まれるその他の項目
Cohn 氏は、バックログのすべての項目がユーザー ストーリーである必要はない、ということを強調しています。「すべての製品バックログ項目はユーザー ストーリーであるべきだ、と考えるチームに会うことがあります。ユーザー ストーリーは、ユーザーがいる場面では素晴らしいものになります。しかし、製品バックログに含まれるものの中には、必ずしも直接ユーザーに関係しないものもあります。こういった項目は、ユーザー ストーリーとして記述する必要はありません」。
このような項目には、バックエンドでの作業や、ユーザーから離れた場所で実行されるその他のタスクなどがあります。Cohn 氏は、このようなタスクをユーザー機能駆動開発 (FDD) の構文 (動詞、結果、目的語からなる構文。「ユーザーのパスワードを検証する」など) を使用して説明することを推奨しています。
スクラム バックログでは、機能、バグ、技術的作業、知識獲得の 4 種類の項目がよく見られます。通常、機能はユーザー ストーリーとして表現できますが、他の項目は表現できません。
まだ始めたばかりの場合でも心配は要りません。完璧な製品バックログでプロジェクトを開始する必要はないのです。必要なタスクについてブレインストーミングすることから始めると、最初のスプリントのために十分な情報が得られます。その後、製品、ユーザーのニーズ、フィードバックについての詳細が見えてくるのに合わせて、製品バックログを拡張できます。
「製品バックログに関する私からの主なアドバイスは、シンプルに保つことです。製品の構造を分解し、整理するだけでよいのです」と、オランダの企業 Xebia (ゼビア) のアジャイル コンサルタントを務める Laurens Bonnema 氏は言います。
C.J. Boat 氏は、保険マーケットプレイス Ensurem (エンスレム) のアジャイル チーム リーダーを務めていますが、同じ意見を持っています。「予測は合理的に行いましょう。バックログが大きくなりすぎたり、作業を適切に整理しなかったりすると、バックログとスプリントが混み合いすぎて、崩壊してしまう可能性がありますから」と彼は語っています。
製品バックログの優先順位付けと順序の設定
タスクを追加したら、製品バックログの整理に入ります。重要度の高い作業は、低い作業より優先させます。この作業は優先度の評価に基づいて実行します。優先度評価が同じ項目については、評価の判定方法に従って優先順位を付けます。
「バックログにタスクを追加する際には、最初の優先度を割り当ててください」と、英国の PMIS Consulting (PMIS コンサルティング) の主任プロジェクト管理コンサルタントを務める Kevin Lonergan 氏は言います。「優先順は、シンプルに 3 段階で十分です。1 - ビジネス目標の達成に不可欠、2 - 有用だが重要ではない、3 - 達成するとボーナスになる項目、といった優先順にします」。
一部の実践者は、リスク、ROI、費用対効果、MoSCoW 分析 (必須、推奨、可能、先送り) などのバケット モデル、あるストーリーが他のストーリーに与える影響、実装までの推定時間、依存関係など、他の基準でリストの順序付けを行う方がよいと主張しています。
Xebia の Bonnema 氏は、重み付けされた最短の作業から着手する (Weighted Shortest Job First、WSJF) 手法を好んでいます。これはドナルド・ライナートセン (Donald Reinertsen) が著書『The Principles of Product Development Flow (原題)』で発表し、スケーリングされたアジャイル フレームワークを作成した Dean Leffingwell 氏がさらに発展させた手法です。これは公式により、タスクの期間と遅延コストの重み付けに基づいて製品バックログに優先順位を付ける手法です。「あらゆるレベルでバックログを一貫して正確に優先順位付けできる方法としては、WSJF を超えるものを他に見たことがありません」と Bonnema 氏は言います。タスクは、完了するか、製品オーナーが不要であると判断するまで、製品バックログに残ります。
ユーザー ストーリーがいつ完了し、バックログから削除できるかを判定するために、チームは標準化された「完了の定義」を作成する必要があります。これは機能のための受け入れ基準で、すべてのチーム メンバーが、提供する業務に期待される内容を確実に把握できるようにするものです。『All About Agile (原題)』の著者、ケリー・ウォーターズ (Kelly Waters) は、 「完了」とは出荷可能であることを意味すると考えています。Scrum Inc. (スクラム) の CEO、Jeff Sutherland 氏は、「DONE-done (完全に完了)」というアジャイルでは有名なフレーズを使用しています。これは、スプリントの終了時にはコーディングが完了し、機能レベルでのソフトウェア テストがバグなしで終了していることを意味します。チームの完了の定義が満たされると、項目を製品バックログから完了の列に移動できます。
段階を追って: 製品バックログを作成する方法
製品バックログとは何か、また製品バックログに含めるべき内容と含めるべきではない内容について説明しましたので、ここで最初の製品バックログ作成のためのポイントをチェックしていきましょう。
- 製品オーナーが製品バックログの責任者になります。自分がオーナーである場合、製品バックログの作成を担当しますが、単独で担当する必要はありません。スクラム チームのメンバーやその他の関係者も参加できます。
- 製品バックログは、製品のすべてのユーザー ストーリーと、その他の作業項目を完全に網羅したリストであることを思い出してください。
- 考えられるすべてのタスクを書き出します。できるだけ具体的に記述し、組織内の関連するすべての部門からの意見や顧客からのフィードバックを取り入れます。
- ユーザーの視点からストーリーを作成し、アクションと理由を含めます。(～として～できるように～が欲しい/したい) の形で、あらゆるタイプのユーザーについて考えます。これらをインデックス カードに書き込むか、オンライン ツールを使用します。タグを適用して、計画されたリリース予定を明確にします。
- バグ修正、知識の獲得、技術的な作業を含めます。
- 製品オーナーとして、組織に対する各項目の重要性を、「非常に高い」から「非常に低い」などの方法で独自に評価します。ユーザーを対象とした調査を行うと、この判断の明確な根拠を得られることがあります。
- 各作業項目については、必要な労力の見積もりも提供します。
- 製品バックログのランク付けを行います。
- チームがスプリントに関わり、取り組む作業はスプリント バックログです。これは製品バックログとは別のものです。スプリント バックログはスプリント中には変更されません。項目は「完全に完了」して初めて「完了した」とみなされ、スプリントと製品バックログの両方から削除されます。
- 新しい作業が発生したら、製品バックログの適切な位置に追加します。フィードバックなどの新しい情報を収集すると、項目の削除や並べ替えが必要になる場合があります。
完了すると、次のようになります。
この時点で、最初の製品バックログのドラフトを無事に作成し、スクラム チームがスプリントで一連の貴重なユーザー ストーリーに取り組めるようになれば最高ですが、まだ作業が終わったわけではありません。
製品バックログを最新の状態に保つ
一度製品バックログを作成した後は、継続的に維持および更新する必要があります。このプロセスは、製品バックログの「手入れ」や「改良」とも呼ばれ、マーケットプレイス、ユーザー、製品チーム、組織の管理者からの情報に基づいてバックログを最新の状態に保つ作業です。バックログの手入れを常に適切に行うことで、開発チームが常に適切な作業に注力していること、次のスプリントの準備が整っていること、リソースを有効に活用して顧客に可能な限り最高の製品を提供していることを確認できます。
製品バックログを改良するための目的を記憶する簡単な方法として、「DEEP」という略語があります。製品バックログが常に「DEEP」であるようにするのが目標です。
D (Detailed、詳細): リストの上にある項目が下にある項目よりも詳細になるよう、適切な情報を提供します。
E (Estimated、見積もり): 各製品バックログ項目、または少なくとも次のリリースに関係する項目は、ストーリー ポイントまたは時間で見積もりを行う必要があります。チームがより多くの仕事をこなすにつれて、速度 (製品バックログの項目を完了する速度) がより明確になり、見積もりが容易になります。
E (Emergent、出現): これは、新たに出現する新しい項目または情報に製品バックログを適応させることを意味します。
P (Prioritized、優先順位): 製品バックログのすべての項目は、最も重要なものが先頭になるように順序付けます。
プロによる製品バックログ管理のベスト ヒント
製品バックログをスムーズに実行するために最大限の努力を払っても、不具合が発生することはあります。多くのチームやさまざまなプロジェクトに携わってきたアジャイルの専門家から、トラブルシューティングや問題回避に関するヒントを伺いました。
アジャイル コーチの Kroll 氏は、最もよく見られる問題は、日常的に関与する必要があるプロジェクト スポンサーの参加不足と、チームの実際のスループットに基づいていない時間目標を達成するようチームにプレッシャーをかける傾向から生じると述べています。解決法は、マネージャーが従来の「計画と実際を比較する」プロジェクト思考から、アジャイル アプローチに移行することです。
AndPlus (アンドプラス) のプロジェクト マネージャー兼スクラム マスターの Jonathan Roger 氏は、製品バックログの一番下にアイスボックスを用意して、そこに優先順位の付いていないアイデアや手入れされていないアイデアを置くことを推奨しています。「製品オーナーは、優先順を維持しなければならないというプレッシャーを感じることなく、長期的に望まれている機能を追跡できます。またチームも、製品オーナーがレビューを行う際に使えそうなアイデアを追加できます。これは、顧客や関係者からの機能リクエストの開始点として使うこともできます」。
PMIS Consulting の Lonergan 氏は、成功の鍵として、プロダクト オーナーを慎重に選択することを推奨しています。「製品オーナーの役割は、委員会ではなく、1 人の人間が担う必要があります」と彼は力説しています。「オーナーが製品バックログを所有します。必ず製品オーナーがバックログの開発を推進するようにしてください」。
「(失敗の) 第 1 位は、権限、該当分野の専門家、時間などが足りないという理由で、相応しくない人物を製品オーナーに任命してしまうことです」と Lonergan 氏は付け加えます。
Smartsheet で製品バックログを簡単に維持・管理
シンプルなタスク管理やプロジェクト プランニングから、複雑なリソース計画やポートフォリオ マネジメントまで、Smartsheet は共同作業の改善と作業速度の向上に役立ち、より多くの成果を上げるのに効果的です。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。