スクラム：プロダクトバックログ項目またはユーザーストーリーは誰が作成するのか？

この質問は一見すると単純に思えるが、実際にはより複雑である。まず、次のように言える。プロダクトバックログ項目にはユースケース、エピック、ユーザーストーリー、バグ、さらにはプロダクトバックログ内の時間制限付きの調査タスクを含むことができる。

最も単純な定義では、スクラムプロダクトバックログは、プロジェクト内で完了が必要なすべてのプロダクトバックログ項目（PBIs）のリストである。従来の要件仕様書の役割を置き換える。アーティファクト。PBIsは顧客やステークホルダーのニーズを反映する。エンドユーザーの要件を把握する一般的なアプローチは、PBIsをユーザーストーリー.

プロダクトバックログの維持管理は誰の責任か？

プロダクトオーナー（PO）はステークホルダーの代わりにプロダクトバックログを「所有」し、主にその作成責任を負う。POはバックログを個人で作成する必要はない—彼または彼女は開発チームおよび／またはスクラムマスターに、バックログ項目の定義や見積もりを支援してもらうことができる。POはプロダクトバックログの作成と維持管理の責任を負う。したがって、POはバックログ精査プロセスを監督する。

プロダクトバックログはプロジェクトのロードマップに対応する——チームが提供しようとしている計画である。チームがそれを定義した後、どの機能や要件を構築するかを優先順位付けする。また、プロダクトバックログはチームが追跡・共有する必要があるすべての情報を含むリポジトリとしても機能する。

プロダクトバックログ項目はユーザーストーリーと同じものなのか？

前述したように、PBIsは顧客やステークホルダーのニーズを反映する。エンドユーザーの要件を把握する一般的な方法は、PBIsをユーザーストーリーの形で書くことである。しかし、PBIsにはユースケース、エピック、ユーザーストーリー、バグ、またはプロダクトバックログ内の時間制限付きの調査タスクを含むこともできる。実際には、プロダクトバックログ内のすべての項目が同じ詳細レベルにあるわけではない。以下の図に示すようにである。

詳細なプロダクトバックログ

近い将来に作業を予定しているPBIsは、バックログの上部に位置し、サイズが小さく、詳細度が高くなるべきである。そうすることで、短時間で作業を進めることができる。スプリント. 当面作業しないPBIsはバックログの下部に置くべきです——規模が大きく、詳細が少ない。これで問題ありません。これらの項目をすぐに作業する予定はないのです。

大きなPBIs、たとえばエピックに近づくにつれて、それらを小さなスプリント対応のストーリーに分解していきます。これは適切なタイミングで行うべきです。あまりに早く精査すると、実装されない可能性のある詳細を無駄に検討してしまうかもしれません。逆に遅れると、PBIsがスプリントに流入できず、チームの進行を妨げてしまいます。適切なタイミングで適切なバランスを見つける必要があります。

アジャイルで優先順位付けされたプロダクトバックログ

PBIsの精査は誰が責任を負うのか？

プロダクトオーナー（PO）は、ステークホルダーの立場でプロダクトバックログを「所有」しており、主にその作成と維持を担当します。POがすべてのバックログ項目を個人で作成する必要はありません。開発チームや/またはスクラムマスターを巻き込んで、項目の定義や見積もりを支援することもできます。POはバックログ精査プロセス全体を監督します。

したがって、質問に答えるとすれば、プロダクトオーナーはプロダクトバックログを所有していますが、すべてのバックログ項目を作成する必要はありません。通常、プロダクトオーナーは上位レベルの要件やユーザーの目標に基づいて大きなPBIsを作成し、チームにその大きな項目をユーザー・ストーリーに分解する支援を依頼します。これらの小さなストーリーは、バックログの上部に適しており、次の基準を満たす必要があります。「準備完了」（通常は次の）準備完了の定義）—その後、スプリントバックログに移動されます。スプリントバックログ.