製品バックログがプロジェクトフレームワークにどのように組み込まれているか
まず、製品バックログを明確に定義しましょう。 ScrumはプロジェクトをSprintと呼ばれる一連の集中した作業期間に整理し、各Sprintは通常 2 週間続きます。 Sprintが開始前に、チームと Scrum Master (コーチとして機能する) は、次のSprintで達成しようとしていることを示すSprintバックログを作成します。
Sprint バックログは、製品に追加する必要があるすべての機能の完全なリストである、より大きな製品 バックログから作成されます。 製品所有者が製品 バックログの優先順位付けを担当します。 (製品所有者は、顧客や他の関係者のニーズを代表し、開発チームの作業をガイドします。) 製品バックログは垂直方向にランク付けされるため、最も重要なタスクが上部に表示され、Scrumチームは通常優先度に基づいてバックログから項目を選択します。 製品バックログは、ユーザーのリクエスト、ビジネスニーズ、広範なテクノロジートレンドに基づいて、時間の経過とともに変化し、進化していきます。
副次的なメモとして、Kanbanという別のAgileフレームワークで製品バックログを使用することもできます。 Kanbanは固定された長さのSprint (Scrum) を使用するのではなく、進行中の作業 (WIP) を制限することに基づいていますが、この記事の情報はKanbanプロジェクトにも適用できます。
しっかりと構築された製品バックログは、作業の生産性と価値、製品が顧客のニーズを満たし、組織の目標と一致していることを保証します。 個人の「To Do」リストと同様に、製品バックログも常に管理する必要があります。 このプロセスは、多くの場合、製品バックログの精緻化またはグルーミングと呼ばれています。 優先順位は変わり、タスクは達成され、アイデアは捨てられます。 バックログを更新しないと整理がつかず、仕事を順調に進めるのに役立ちません。
最初の製品バックログの作成
製品バックログの作成を始めるには、Agileの専門家の中には製品ロードマップの作成を推奨する人もいます。 これは、製品の長期的な見通しを提供する戦略計画です。Agile製品管理の専門家トレーナーを務める Roman Pichler氏は、多くの製品所有者とマネージャーはロードマップの機能の詳細に集中しすぎ、大きなビジョンに十分ではない、と語っています。 彼は、製品目標と目標を達成するために必要な機能を強調する目標指向ロードマップテンプレートを開発しました。
ロードマップには複数のリリースの長期目標が含まれる場合がありますが、製品バックログでは次のリリースに向けた作業をより詳細に記載することに重点を置く必要があります。 今後のリリースは、下位に配置し、より詳細に表現する必要があります。 そして、ロードマップから情報を取り出し、それをタスクや作業項目に変換します。
各製品には独自のバックログが必要です。 製品が非常に大きい場合、または相互に関連する一連の製品の一部である場合、製品を構成するものを判断するのに混乱を招く可能性があります。 Agileの専門家であり Innolution のコンサルタントである Kenneth Rubin氏は 、目標はコンポーネントチームとコンポーネントバックログの数を最小限に抑えることであり、可能な限り 1 つのバックログを使用することを好むという。 しかし、数十、数百のチームが参加する超大型プロジェクトでは、これは現実的ではなく、そのような場合には、大規模な機能については1つのバックログを、関連する作業領域についてはそれぞれ別のバックログを作成するという、階層型バックログを使用することができます。
ユーザーストーリーが製品バックログの核となる
製品 バックログの作業項目は、多くの場合、ユーザー ストーリーと呼ばれる機能をユーザーの視点から見た機能の動作に関する説明で表現されます。 ユーザーストーリーは、Sprint内で達成できるほど小さいものです。
Fidelity Investmentsでチームを訓練したAgileコーチ、Chuck Krollは、従来のユーザーストーリーの公式を推奨しています。「顧客のようなユーザーの種類) として、(目標) そう (理由) ようにしたい」と Kroll 氏は述べています。 「これにより、だれがこの機能を使用するのか、何が必要なのか、ビジネスバリューは何なのかが明確になります。」
ユーザーストーリー 対 ユーザー エピック： バックログ項目はどのように詳細にする必要がありますか?
大きなストーリーは「エピック」と呼ばれ、達成するためにいくつかのSprintを要します。 作業を開始する前に、エピックをストーリーに分割する必要があります。
AgileとScrumのトレーニングを提供するMountain Goat Software の創設者である Mike Cohn 氏は、次のエピックの例を提供しています： ホテル会社は、競合他社のレート、シーズンなどの変数に応じて、ホテルの部屋に対して請求できる量を最も多く評価するシステムを求めている。 「ホテルのオペレーターとして、ホテルの客室に最適な料金を設定したい。」 それは、「ホテル経営者として、前年の価格設定をもとに最適な客室料金を設定したい」、「ホテル経営者として、同業他社の料金設定をもとに最適な客室料金を設定したい」といったユーザーストーリーに集約されます。
製品バックログのユーザーストーリーを準備する際には、チームが正確に実行できるように、優先度の高い項目はより詳細な情報を持つ必要があります。 これには、フィーチャーのワークフローを示す図や、フィーチャーの詳細の説明などが含まれます。
「見落とされている最も重要なアドバイスは、製品バックログの項目すべてが同じレベルの詳細を必要としていないということです」と Cohn 氏は述べています。 「次のSprintに入ってくる項目は適度に詳細である必要があります。 さらに詳しい項目は、徐々に詳細にしなくてはいけません。」
次のユーザーストーリーを想像してみてください： ウェブサイト訪問者として、私は私の第一選択空港または近くの空港に提供された最も安い価格で飛行機のチケットを購入できるようにしたいと考えています。 これは製品バックログの一番上に近いため、次のような詳細をユーザーストーリーに追加する必要があります： 機能は、100マイル内のすべての空港の料金を確認する必要があります。 それは私に第一選択空港からの距離だけでなく、価格で料金をソートする機能を与える必要があります。
Pichler は、製品バックログを作成する方法をどの程度細かくするか決定する際には、製品ライフサイクルが重要であると推奨しています。 新しい製品には、より短く、より詳細でないバックログがあり、新しいアイデアを試し、製品を頻繁に変更して最適化できるようにする必要があります。 一方で、より古い安定した製品では、製品がどのように進化するかを予測できるため、より詳細なバックログが得られるというメリットがあります。
リリース サイクルは、製品 バックログのもう 1 つの要因です。 新しいバージョンや大きなリリースに取り組み始めると、未知の情報が増え、何を学ぶことでバックログが大きく変更される可能性もあります。 したがって、製品バックログを短く、あまり詳細に記述しないことが、リリースサイクルの初期に意味を持つと、Pichler氏は説明しています。
現在Industrial Logic Inc社で働くAgileコンサルタントのBill Wake氏は、良いユーザーストーリーの特徴を表す広く使われているモデルとニーモニックをINVESTという頭文字を使って考え出しました。
I - 独立 - ストーリーはオーバーラップするべきではありませんし、理想的には任意の順序で実装できます。
N - 交渉可能 - ストーリーは、参加者によって合意された詳細ではなく、本質をキャプチャします。
V - 価値ある - ストーリーは顧客に明確な価値を提供します。
E - 評価可能 - 関連する取り組みを評価できます。 時間見積り、またはストーリーポイントと呼ばれる、相対的な複雑さを示す任意の測定単位 (XS、S、M、L、X、1、2、4、8、16) を見積ります。
S - Small - 「良いストーリーは小さな傾向があります」と Wake 氏は述べています。 つまり、ストーリーは 1 人の専任者から 40 時間の労働時間で (せいぜい) 達成するか、チームメンバーに分ける必要があります。
T - Testable - IT テスト プラットフォーム ReQtest の創設者兼製品所有者である Ulf Eriksson 氏によると、ユーザーストーリーは何らかの形で測定可能または実行可能である必要があります。
製品 バックログに属するその他の項目
Cohn 氏は、バックログのすべての項目がユーザーストーリーである必要はないことを強調しました。 「すべての製品バックログ項目をユーザーストーリーにするべきだと考えているチームに会っています。 ユーザーストーリーは、周りにユーザーがいる場合に非常に素晴らしいおのです。 しかし、製品バックログに属するものの中には、必ずしも直接ユーザー向けとは限らないものもあります。 これらの項目をユーザー ストーリーとして記述する必要はありません。」
これには、バックエンドでの作業や、ユーザーから遠いその他のタスクが含まれます。 Cohn 氏は、機能主導型開発 (SMARTD) 構文 (動詞 + result + object など) を使ってこれらのタスクを説明することを推奨しています。 「ユーザーのパスワードを検証する”)。
Scrumバックログでよく見られるアイテムの 4 種類は、機能、バグ、技術的作業、知識獲得です。 フィーチャーは通常、ユーザーストーリーとして表現するのに役立ちますが、他のアイテムは表示されません。
まだ始めたばかりであれば、心配はいりません： 完璧な製品バックログでプロジェクトを開始する必要はありません。 最初に必要なタスクのブレインストーミングを行えば、最初のSprintに十分な情報が得られます。 次に、製品、ユーザーのニーズ、フィードバックの詳細を知るにつれて、製品バックログを拡大できます。
「製品バックログに関する私の主なヒントは、シンプルにしておくことです。 これは単なる順序付き製品分解構成図です」と、オランダの Xebia のAgileコンサルタント、ローレンス・ボンナマは述べています。
保険市場 EnsuremのAgile チーム リーダーであるC.J. Boat は合意しました。 「合理的な期待をする! バックログが大量になったり、仕事、バックログ、Sprintを適切に整理しなかったりすると、混同されてしまい、ばらばらになってしまいます」と彼は言いました。
製品バックログの優先順位付けと注文
タスクを追加したら、次は製品バックログを注文します。 重要度の高い仕事を重要度の低い仕事の上に置く。 これは、優先度の評価に基づき、同じ優先度評価の項目をランク付けする方法を判断することで行えます。
「ブリテンズPMIS コンサルティングのプリンシパル プロジェクト管理 コンサルタント、カエルロネルガン氏は、「バックログにタスクを追加する際に、最初の優先度評価を割り当てます。 「シンプルな 3 つのレベルの優先順位は次のようになります： 1 - ビジネス目標を達成するために重要、2 - 役に立つけれども重要ではない、3 - これらの項目が完了した場合、ボーナスになります。」
一部の実務担当者は、リスク、ROI、コスト便益、MoSCoW のようなバケットモデル (あるストーリーが別のストーリーに与える影響、実装予定時間、依存関係など) に関するリストを注文する方がよいと言います。
Xebia のBonnemaは、Donald Reinertsen 氏が「製品開発フローの原則」で執筆し、拡張Agileフレームワークの作成者である Dean Leffingwell 氏によってさらに開発された、重み付け最短ジョブファースト (WSJF) 手法を採用しています。 タスクの期間と遅延コストの重み付けに基づいて、製品バックログに優先順位を付ける公式です。 「私は、WSJF よりもすべてのレベルでバックログを正しく優先順位付けし一貫して行う良い方法を見つけていない」と Bonneno 氏は述べています。 タスクは、完了するまで、または製品所有者が不要になったと判断するまで、製品バックログに残ります。
ユーザーストーリーが完了し、バックログから削除できるタイミングを決定するには、標準化された「完了の定義」を作成する必要があります。 これはフィーチャーの受け入れ基準であり、チームメンバー全員が自分が提供する作業に何が期待されているのかを把握できます。 「All About Agile （Agileのすべて）」の著者であるKelly Waters 氏は、「完了」は出荷可能という意味を持つべきだと考えています。 スクラム社のCEOであるJeff Sutherlandは、 アジャイルでよく使われる言葉「done done」を使い、スプリント終了時に、コーディングが完了し、ソフトウェアテストがバグなしで機能レベルで終了していることを意味します。 チームの完了の定義が満たされると、項目を製品バックログから完全な列に移動できます。
ステップバイステップ： 製品バックログの作成方法
製品バックログとは何か、そのバックログには何が含まれるのか、何が属するのかがわかったら、最初の製品バックログを作成するためのチェックリストを次に示します：
- 製品所有者が製品 バックログを担当します。 これがあなたであれば、製品バックログの作成を担当しますが、関与する唯一の人物である必要はありません。 Scrumチームのメンバーや他の関係者も参加できます。
- 製品バックログは、製品のすべてのユーザーストーリーとその他の作業項目の完全なリストであることを覚えておきます。
- できるすべてのタスクを思い出し、それを書き留めます。 可能な限り具体的に情報を提供し、組織のすべての関連する部分や顧客からのフィードバックを求めます。
- ユーザーの視点からストーリーを作成し、アクションと理由を含めます。 (______として、私は______できるように______を望んでいます。) すべてのユーザーについて考えてみてください。 インデックス カードにこれらを書くか、オンライン ツールを使用します。 タグを適用して、予定されているリリースを明確にします。
- バグ修正、知識獲得、技術的作業などが含まれます。
- 製品所有者は、各項目の重要性を非常に高いから非常に低い、またはその他の方法まで、組織全体に対して評価します。 ユーザーに調査を行い、これらの決定にしっかりとした根拠を持つことができます。
- 作業項目ごとに、工数の見積りも指定します。
- 製品バックログをランク付け します。
- チームがSprintで取り組む作業はSprintバックログであり、これは製品バックログとは別のものです。 SprintバックログはSprint中に変更されません。 項目は完了と見なされ、「完了」されるとSprintと製品バックログの両方から削除されます。」
- 新しい仕事が入ったら、それを適切な位置の製品バックログに追加します。 フィードバックなどの新しい情報を収集すると、アイテムを削除したり並べ替えたりすることができます。
完了したら、次のような終わりを迎える必要があります：
この時点で、最初の製品バックログの作成に成功し、ScrumチームがSprintで貴重なユーザーストーリーのバッチに取り組んでもらえば、おめでとうございます。 しかし、それはまだリラックスするためのかなりの時間ではありません。
製品バックログを最新の状態に保つ
製品 バックログを作成したら、継続的に維持および更新する必要があります。 このプロセスは、製品バックロググルーミングやリファインメントとも呼ばれ、市場、ユーザー、製品チーム、組織の経営陣からの情報に基づいてバックログを最新の状態に保ちます。 バックロググルーミングを常に重視することで、開発チームが常に適切な作業に取り組み、次のSprintに向けて準備が整い、リソースをうまく活用して最高の製品を顧客に提供できるようになります。
製品バックログのリファインメントプロセスの目的を覚えやすいのが、DEEP という頭文字です。 目標は、製品バックログが常に DEEP であることを確認することです：
D - リストの一番上にある項目が下部にある項目よりも詳細になるように、適切に詳細にします。
E- 見積り - 各製品 バックログ項目、または少なくとも次のリリースに関わる人は、ストーリー ポイントまたは時間で見積もる必要があります。 チームの作業量が増えるにつれ、 速度 (製品バックログから項目を完了する速度) がより明確になり、見積りが容易になります。
E- Emergent -製品バックログが新しいアイテムや情報に適応していることを意味します。
P - 優先度設定 -製品バックログのすべての項目が最も重要なものを頂点として並べられます。
製品バックログの管理に関するメリットのベストヒント
製品バックログをスムーズに進めるために最善を尽くしても、問題が発生する可能性があります。 多くのチームやさまざまなプロジェクトで作業を行ったAgileの専門家は、トラブルシューティングや問題の回避に関するヒントを持っています。
Agileコーチの Kroll 氏は、最もよくある問題は、プロジェクトスポンサーの参加不足や、日常的に関与する必要がある問題、そしてチームの実際のスループットによって引き起こされていない時間目標を達成するようチームに迫られる傾向にあると述べた。 この解決策は、マネージャーが従来の「計画済み」プロジェクトと実際のプロジェクトの考え方からAgileアプローチに移行することです。
AndPlusのプロジェクトマネージャーでScrum マスターのJonathan Roger氏は、製品バックログの下部に「アイスボックス」を残しておくことをお勧めします。 「製品所有者は、優先度を維持するというプレッシャーをかけずに、長期的に望まれる機能を追跡でき、チームは製品所有者によるレビューのためにアイデアを追加できます。 また、顧客や関係者からの機能リクエストの出発点としても役立ちます。」
PMIS Consulting のロネルガン氏は、成功のカギとして製品所有者を慎重に選択することをお勧めしています。 「一人が委員会ではなく、製品所有者の役割を遂行しなければならない」と彼は強調した。 「彼らは製品バックログを所有しています。 製品所有者がバックログの開発を推進していることを確認します。」
「第一 (の間違い) は、権限の欠如、ドメインの知識、時間の不足などにより、間違った人を製品所有者として間違って任命することです」と、Lonergan 氏は付け加えました。
Smartsheetで製品バックログを簡単に維持および管理
シンプルなタスク管理やプロジェクト プランニングから、複雑なリソース計画やポートフォリオ マネジメントまで、Smartsheet は共同作業の改善と作業速度の向上に役立ち、より多くの成果を上げるのに効果的です。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。