製品バックログには、特定の時点で対処しなければならない項目が含まれているため、組織のアジャイル製品開発の主要コンポーネントです。
新しい製品の作成は、チームが何か特別なものを構築できるようにするというアイデアから始まります。 iPhone でさえ最初はプロトタイプとして登場し、熱心なチームのおかげで人気を博しました。
チームを管理している間、プロダクト マネージャーとして、重要な To Do リストを整理しておく必要があります。 まあ、それは思ったほど簡単ではありません。
やることリストを維持し、どれを最初に行うかを決定することは、非常に難しい作業です。 そして、複数の利害関係者がいる場合、それはさらに圧倒されます。
その結果、組織は多くの時間とリソースを失います。
これは、製品の優先順位付けにより、すべてのタスクが簡単になり、To Do リストを適切に維持するのに役立ちます。
この記事では、プロダクト バックログ、その典型的な要素、メリットなどについて詳しく説明します。
製品バックログとは何ですか?
製品バックログは、製品の目標を達成し、開発者チーム間で有効な期待を設定するのに役立つ、優先順位が付けられた機能または作業項目のリストです。 簡単に言えば、開発段階の各製品には、専用の製品バックログがあります。
同様に、すべての製品バックログには専任のチームがあります。 一般に、いくつかのチームがより大きな製品に取り組んでいるいくつかの製品バックログがあります。
たとえば、大きな製品を「製品」、小さな製品を「製品 A」、「製品 B」、および「製品 C」と名付けましょう。 製品 A、製品 B、および製品 C には、独自の製品バックログと特定の開発チームがあります。 指定された各チームは、小さな製品に取り組み、最終的に大きな製品を構築します。
したがって、製品ロードマップと開発チームの要件から導き出された作業の優先順位付けされたリストとして定義できます。 最も重要なアイテムはバックログの一番上にあるため、開発チームはどれを最初に提供する必要があるかがわかります。
ただし、製品バックログは、製品マネージャが典型的な問題と製品の提供に必要なソリューションをより深く理解できるようにするライブ ドキュメントです。
バックログ項目を優先するのは誰ですか?
プロダクト バックログは、プロダクト オーナーまたはプロダクト マネージャーが所有します。 プロダクト オーナーはバックログのメンテナンスを担当し、他のチーム メンバーは労力と時間をプロダクト開発に費やします。
したがって、製品バックログの主な目的は次のとおりです。
- 開発チームが貴重なユーザーストーリーを実装できるように、チームと利害関係者を調整するための基盤を開発する
- 現実とニーズに適応する柔軟性を提供する
- さまざまなチーム間で共通の分母を使用して 1 つの製品に固執することで、製品リリース予測の効率を高めます。
製品バックログの典型的な要素
製品バックログには、バグ修正、機能、知識の獲得、および技術的負債が含まれます。 これらのアイテムは、製品を完成させるために提供する必要がある主要な作業の個別の部分です。
＃1。 バグの修正
欠陥やバグは、エンド ユーザーによって発見され、品質管理プロセス中に回避される問題です。 バグが時間内に解決されない場合、時間の経過とともに累積する傾向があります。
製品の完全性を維持するために、チームはバグ修正に迅速に対応します。 チームの現在のスプリントを中断するほど重要なバグもあれば、次のスプリントまで待つことができるバグもあります。 開発チームがバグ修正を決して忘れないように、製品バックログの一番上に残ります。
＃2。 特徴
機能とは、ユーザーが価値を感じる製品の機能です。 ユーザーストーリーとも呼ばれます。 機能は複雑にも単純にもできます。 ただし、ユーザーのニーズを理解するには、ストーリー マップを作成する必要があります。
新機能のリクエストの発信元はさまざまです。 機能には、製品管理、サポート、販売、エンド ユーザーなどが含まれます。 次の競合する要件のバランスを取る必要があるため、新機能の優先順位付けは難しい場合があります。
- 以前の顧客を満足させ続ける
- タームセールスの機会に会う
- 製品のより高いビジョンへの取り組み
プロダクト マネージャーはこれらのソースを監視し、競合する要求を解決します。 定期的にこれを行うことで、製品バックログに顧客を引き付け、既存の顧客を満足させる新しい機能が含まれていることを確認できます.
＃3。 知識の獲得
ここでは、将来のタスクを完了するための情報を収集します。 重要なことに、知識の獲得は研究段階です。 さらに調査が必要な機能を検出したら、概念実証、実験、プロトタイプなどの知識獲得タスクを作成できます。 これは、機能に関する作業を開始するための情報を取得するのに役立ちます。
＃4。 技術的負債
技術的負債は金銭的負債のようなものです。 債務を無視すると利息が発生します。 これは、開発者がこの段階をバックログの一番下に押し込むと発生し、達成が難しくなります。
製品のバックログを効果的に管理することで、技術的負債を防ぐことができます。 開発チームがリストに従って組織化された状態を維持し、技術的な仕事を毎日または少しずつ引き受けている場合、その仕事への関心が高まる可能性は低くなります。
技術的負債は、以下に基づく変更の結果です。
- スケーラビリティとパフォーマンスの期待
- 範囲と方向性
- テクノロジーとベスト プラクティス
製品バックログ: メリット
製品は確かに、営業担当者、開発者、そして最も重要なユーザーなど、さまざまなソースからのフィードバックを表しています。 彼らのフィードバックを受け取り、それを管理し、優先順位を付け、将来の製品配信のために徹底的に取り組む準備ができている必要があります.
適切なプロセスがなければ、製品の開発は困難になります。 したがって、適切に管理され、適切に処理されたバックログは、製品に集中するのに役立ち、より効率的なチームにつながります.
組織で製品バックログを維持する利点について説明しましょう。
- 集中力の向上: プロダクト バックログは、重要なタスクに集中するのに役立ち、気を散らさないようにします。
- 効率の向上: アイテムに優先順位を付けることで、チームはタスクに徹底的に取り組むことができ、効率が向上します。
- より優れたリスク管理: プロダクト バックログは、開発プロセスの早い段階でリスクを特定して対処できるため、管理者はリスクのないものになります。
- 顧客満足度の向上: エンド ユーザーの満足度が主な目標です。 したがって、バックログの優先順位付けは、組織が製品に追加または削除する必要があるものを確認して満足させるために不可欠であり、ユーザーにとって価値のある製品にします.
- コミュニケーションの向上: プロダクト バックログは、チーム間のコラボレーションとコミュニケーションを促進し、プロダクトの開発中の集中力を高め、成果を高めます。
- チームの士気の向上: プロダクト バックログはチームに目的と方向性を提供し、士気の向上につながります。
- 柔軟性の促進: 開発者の進捗状況とタスクの完了率に応じて、製品のバックログが変化します。 製品ステータスの開発が変更されると、製品マネージャーはタスクの優先順位を変更します。 この柔軟性は、勤務時間の空白を避けるために必要です。
これとは別に、投資に対する最速のリターン、顧客満足度の向上、リスクの最小化など、多くの利点を見つけることができます.
製品バックログを作成する方法
プロダクト オーナーは、優先順位付けタスクの全責任を負います。 適切に管理された製品バックログを作成するには、次の手順に従う必要があります。
ステップ 1: プロダクト バックログにアイデアを追加する
製品バックログはアイデアのリストです。 これには、チーム メンバー、利害関係者、および顧客からの声明またはフィードバックが含まれます。 簡単に言えば、既存の製品または新製品について関係者、チーム、および顧客と話し合った後、アイデアをリストに追加する必要があります。
最初は限られたアイデアしか思い浮かびませんが、開発プロセス中に、製品の市場関連性と競争を念頭に置いて、新しいアイデアを得ることができます。
ステップ 2: 説明を得る
利害関係者が製品の追加または修正に変更を加える必要がある場合は、事前に明確にすることが重要です。 プロダクト オーナーは、追加の重要性を理解するために、次の基本的な点を明確にする必要があります。
- 修正の背後にある理由: これは、問題の実際の内容、原因、解決方法を示しています。
- 貢献する価値: チームは、新しい追加が製品全体に貢献し、品質を向上させるのに役立つかどうかを分析します。 追加は製品の価値を高める必要があります。 したがって、ビジネス価値の向上と投資収益率の向上につながります。
- アイテムの仕様: 仕様は、開発者が開発プロセス中に困難を感じないように、製品所有者の側から明確にする必要があります。
ステップ 3: 優先順位付け
すべてが一直線に並ぶと、製品所有者の責任は、バックログの優先順位を最高のものから最低のものまで優先順位を付けることです。 この段階は、情報の戦略的分析に基づいています。 リストを適切に管理することで、さまざまなチーム間のコミュニケーションを強化できます。
プロダクト オーナーは、特定の基準に基づいてバックログ アイテムに優先順位を付けます。
- 収入: より良い収入につながる可能性のある機能や項目は、優先順位の高いリストに入れておく必要があります。
- 市場の独自性と修正: 追加することを決定した機能が市場で独自のものである場合、市場で目立つ可能性があります。 また、実際の目標は既存の機能がユーザーの問題を解決できるかどうかを確認する必要があります。
- 複雑さ: バックログ項目に優先順位を付ける前に、提案された機能の複雑さと、開発とリリースにかかる時間を確認する必要があります。
ステップ 4: 製品バックログを定期的に更新する
プロダクト バックログは、プロダクト オーナーがタイムリーに更新する必要がある生きたドキュメントです。 バックログ項目を改良し、優先順位を付け、最新の状態に保つプロセスは、開発プロセスの重要な部分です。
プロダクト バックログには多くのアイデアが含まれています。 それらのアイデアを洗練し、関係のないものを破棄する必要があります。 最後のステップでは、バックログ項目に優先順位が付けられ、優先度に従って配置されます。
いくつかの優先順位付け方法
バックログ項目に優先順位を付けるために使用できる方法はたくさんあります。 それらのいくつかについて説明しましょう。
＃1。 MoSCoWテクニック
画像ソース: StoriesOnBoard
MoSCoW は、製品管理で一般的に使用される分析の一種であり、何が不可欠で何がそうでないかを理解します。 これは、自分が取り組んでいることとその理由について利害関係者とコミュニケーションを取るための便利な方法です。
この名前には、次の 4 つの優先度カテゴリが含まれています。
- 必須: 絶対に必要な要件
- 持つべきもの: 優先度の高い機能
- 可能性のある機能: 可能な機能
- ありません: 実装されていません
「必須」は、製品に絶対に必要な機能を表します。 これには、安全上の懸念、ビジネス上の理由、および法的な理由が考えられます。 このために、その機能をリストに含める場合の最良のシナリオと最悪のシナリオをリストし、絵を描きます。
「持つべき」とは、含めることができるが必須ではない機能を意味します。
「Could have」は、組織が必要なリソースを持っている場合に追加できるが、成功するために必要ではない項目のことです。
「ありません」ということは、その機能が不要になった、または廃棄されたアイテムであることを示しているわけではありません。 代わりに、プロダクト マネージャーは「今回はありません」という意味です。 これには、時間やリソースの不足など、いくつかの理由があります。
＃2。 アイゼンハワー マトリックス
この方法は、時間を適切に管理するための簡単な方法です。 これは、ドワイト D. アイゼンハワーの意思決定マトリックスに由来します。 これは後で、バックログ リストのタスクに優先順位を付けるために使用できる 4 象限の視覚化に変更されます。
画像ソース: ModelThinkers
マトリックスには、重要度と緊急度という 2 つの優先順位付けの次元が含まれています。 この手法により、以下を含むマトリックスの 4 つのセクションにタスクを割り当てることができます。
- 優先度高
- 中優先度
- 緊急だが重要
- 低優先度
＃3。 カノ
Kano モデルは、顧客の喜びと満足を求める組織にとって優れたオプションの 1 つです。 プロダクト マネージャーの未処理機能は無限にありますが、完璧な機能を備えた製品ロードマップを作成したいと考えています。 Kano モデルは、プロダクト マネージャーを導く堅牢な手法です。 この手法は、1980 年代に狩野典明によって開発されました。
このモデルには、次の 3 つの前提が含まれます。
- お客様の喜びを反映した満足
- 顧客の反応は、製品の特徴と機能によって異なります
- お客様の気持ち
＃4。 加重最短ジョブ ファースト (WSJF)
WSJF は、チームがイニシアチブのリストに優先順位を付けるのに役立つツールです。 通常、このツールは Scaled Agile Framework (SAFe) で使用されます。 チームは、遅延のコストをジョブのサイズまたは期間で割ることによって、各イニシアチブのスコアを計算します。 最高のスコアを取得したアイテムが、優先度の高いものとしてトップ リストに表示されます。
バックログの管理方法
以下のプラクティスに従って、バックログを適切に管理し、バックログを健全に保ちます。
- イテレーション計画の前に製品バックログを確認して、優先順位を付けたタスクが正しく、以前のフィードバックも実装されていることを確認します。
- バックログが大きくなった場合、項目を短期または短期、長期に分類する必要があります。
- アイテムの利点に応じて、アイテムを保持するか削除するかを決定します
- 適切な計画なしにタスクを追加しないでください。
- この優先順位付けプロセスを組織内の優先事項にしてください。
さらに、顧客からのフィードバックに応じて、開発プロセス中にタスクの優先順位を簡単に再設定できます。 さらに、以前のステートメントを改良し、新しい要件を追加することができます。
スプリント バックログとプロダクト バックログ
- 製品バックログには、開発プロセスを時間内に完了するために完了しなければならないすべての項目がリストされています。 一方、スプリント バックログには、スプリント内で完了する必要があるバックログの項目が含まれます。
- プロダクト オーナーがバックログ リストを決定し、開発チームがスプリント バックログ アイテムを決定します。
- 製品バックログは、製品の目標に基づいて構築されます。 ただし、スプリント バックログは特定のスプリントと一致します。
- プロダクト バックログは時間の経過とともに変化する可能性がありますが、スプリント バックログは設定後は変化しません。
- プロダクト バックログはメンテナンスが必要で、プロジェクトが完了するまで残ります。 しかし、スプリント バックログは最後まで残りません。 それはスプリントで終わります。
結論
製品バックログを維持することは、製品開発プロセスの重要なステップです。 進行中の作業、完了した作業、および将来の計画を明確に把握できます。 したがって、効果的な製品バックログを作成して維持し、ゲームのトップに立つときが来ました.
また、最高の CFD 分析ソフトウェアとスクラム ツールを探索することもできます。
