プロダクトバックログ

スクラムの作成物

この記事では、

・プロダクトバックログってなに?
と悩んでいる方に向けて

・プロダクトバックログの基本的な知識
を説明します。

この記事を読むと以下のことがわかります。

この記事で読んでわかること!
  • プロダクトバックログとは何か。
  • プロダクトバックログの書き方。
  • プロダクトバックログがReadyの状態。

スクラム作成物の概要を確認したい方は、以下記事をご確認ください。

スクラムの作成物(5選)
「スクラムガイド」で定義されている、プロダクトバックログ、スプリントバックログ、インクリメントと完成の定義に関して、画像多めでわかりやすく説明しています。スクラム開発を実施する上で、基礎であり、最も重要な作成物ですので、作成理由とアウトプットのイメージをこの機会にしっかりと理解しておきましょう!

プロダクトバックログとは?

プロダクトバックログ(PBL)とは、

プロダクトの作成改善に必要なタスクが優先度順に一覧で並べられたもの

です。

また、上記のタスクは「プロダクトバックログアイテム(PBI)」と呼ばれます。

プロダクトバックログは、スクラムチームが行う作業の唯一の情報源です。

スクラムチームやステークホルダーがPBLを共有することで、作業の価値や優先度・どのような作業を実施するか確認でき、共通のゴールを認識することができます。

PBLを作成する前に実施すること

プロダクトバックログは、プロダクトゴールを達成するために、必要なタスクを洗い出したものです。

そのため、プロダクトバックログを作成する前に、

事前に「どのような顧客(ペルソナ)に、どんなサービス(価値)を提供したいか

を検討する必要があります。

一般的、以下のプラクティスを実施して、ペルソナや価値を整理します。

  • インセプションデッキ
インセプションデッキ
スクラム開発では「インセプションデッキ」を作成するのが一般的です。チームでプロジェクトの共通認識を持つための重要な作成物となっています。この記事では、インセプションデッキの目的・メリット・作り方を簡単にまとめています。実際にスクラム開発を実施する前に、一読いただくことで、目的を見失わずに、スムーズに開発に取りかかれると思います。皆さんのお役に立てると嬉しいです。
  • ユーザーストーリー
ユーザーストーリー
スクラム開発では「ユーザーストーリー」を作成するのが一般的です。ターゲットとするユーザーを決定し、そのユーザーに対して、プロダクトを通して「どのようなことを価値」を提供するかを整理するために重要な作成物となっています。この記事では、ユーザーストーリーの目的・メリット・作り方を簡単にまとめています。実際にスクラム開発を実施する前に、一読いただくことで、目的を見失わずに、スムーズに開発に取りかかれると思います。皆さんのお役に立てると嬉しいです。
  • リーンキャンバス

※ 詳細は別記事で作成予定です。今しばらくお待ちください!

プロダクトバックログを作成する前に、スクラムチームやステークホルダーと

プロダクトゴールや初回リリースで提供する価値(MVP)などは整理しておきましょう!

とも坊

スプリント開始前の準備期間を「スプリント0」といいます。

PBLの書き方・作成方法

プロダクトバックログを元に、スクラムチームはプロダクト開発します。

そのため、各プロダクトバックログアイテムを実施することで、

「誰がどのような価値を得られるのか」を明確にすることが大切です。

ただ、上記記載のみでは、プロダクトオーナーと開発者で共通認識を築くことはできません。

そのため、「UIイメージ、表示メッセージ、連携システムの仕様書など」の関連ドキュメントを準備します。

また、何を持ってPBIの価値提供が達成されたかを判断するために

「受け入れ基準(AC)」を明確化することも大切です。

上記の観点をPBLに記載し、スプリントレビューやリファインメントを通して、

POと開発者の間で共通認識が持てるプロダクトバックログを目指しましょう!

PBLを作成するタイミング

スプリントバックログは、いつまでに、どの程度作成しておく必要があるのでしょうか?

結論としては、

スプリント開始前に、次のスプリントを開始できるだけのPBIが作成できていればOKです。

もう少し具体的に言うと、、、

※ 慣れていない場合は、上記+1週間の余裕を持って計画するのがオススメです。
※ 「ストーリーポイント」「スプリントバックログ」は、別記事で説明予定です。

始めから実現したいことの全てのPBIを作成する必要はありません。

むしろ、初回に多くのPBIを作成しても、日々変化する要望や状況においては、

実現したいことや、優先順位は変更になるため、

スプリント開始時に作成したPBIは、ほとんどゴミになります。

(予めやる内容を確定できるのであれば、WF開発の方が効率的かもです。)

ただ、全てにPBIを作成しておかないと不安に感じる人も多いと思います。

その場合は、直近のスプリント以降のPBIは粒度が大きいまま(ユーザーストーリーレベル)に留めておき、分割や詳細化などの作り込みは避けるようにしましょう!

スプリント中に消化したPBI分を、スプリント中のリファインメントなどを通して、分割&詳細化を実施し、常に直近2,3スプリント分のPBIが準備出来ている状態を目指しましょう!

PBLがReadyの状態

プロダクトバックログは「スクラムチームが行う作業の唯一の情報源」とお伝えしたように、

スプリントを始めるためには、直近のプロダクトバックログの作成が完了している必要があります。

このように、PBLがスプリントを開始できる状態になっていることを「Ready」と言います。

直近のPBLに対して「Ready」の状態を保つことで、

スクラムチームのベロシティが安定し、予測精度が向上することで、リリース計画も立てやすくなります。

「PBLを作成するタイミング」でもお伝えしたように、全てのPBIを100%完璧な状態にする必要はありません。

スクラムチームが共通認識を持つことができる度合いで、PBLの直近のスプリント分のPBIが「Ready」であれば十分です。

まとめ

  • プロダクトバックログは、プロダクトの作成・改善に必要なタスクが優先度順に一覧で並べられたもの。
  • PBLを作成する前にプロダクトゴールや初回リリースで提供する価値(MVP)を整理しておく必要がある。
  • PBIは「実施理由」「参考資料/補足情報」「受け入れ基準」を共有し、PO – 開発者で共通認識が持てるようにする。
  • PBLは、直近のスプリントを開始できるだけのPBIの作成が出来ていればOK。
  • 直近のPBIが「分割&詳細化」「受け入れ基準の明確化」「優先度順に並んでいる」「見積りが完了している」状態がPBLが「Ready」の状態である。

Sponsored Link

コメント

タイトルとURLをコピーしました