PBI vsユーザーストーリー
最近、「xページからログインページに移動するとエラーが表示されます。そのエラーを削除してください」というアイテムが製品所有者によって製品バックログに追加されました。
これはユースケースではなく、PBI（Product Backlog Item）であってはならないようです。しかし、それについて話し合ったとき、スクラムマスターはユーザーストーリーはPBIではないことを教えてくれました。PBIは、バグレポート、タスク、ユーザーストーリー、何か、文字通り最初に対処する必要のあるアイテムである可能性があります。
これについてはよくわかりません。また、PBIの適切な定義を見つけることができません ウェブ上 。だから、私の質問は、どのようなものがアイテムとして製品バックログに入ることができるかということです。製品バックログアイテムはユーザーストーリーにマッピングされますか？彼らは同じですか？
製品バックログアイテムはユーザーストーリーにマッピングされますか？彼らは同じですか？
必ずしもそうとは限りませんが、一般的にはそうです。スクラムマスターが言ったように、他の事柄も製品のバックログアイテムになる可能性があります。ただし、それはyour SCRUMがどのように機能するかによって異なります。チームによっては、スプリントについても考慮される個別のバグバックログを持っているものもあれば、製品バックログにそのようなものを保持しているものもあります。
次のスプリントでは2つのログを考慮する必要があるため、2つの別個のログにより、製品の所有者がタスクの優先順位を付けることがより困難になります。しかし、それらはより優れた監視を提供し、両方を個別に優先することができます。
だから、私の質問は、どのようなものがアイテムとして製品バックログに入ることができるのですか？
これは、製品ビジョンの一部であり、作成する製品への道のりである可能性があります。ほとんどの場合、要件（ユーザーストーリー）が含まれますが、製品に直接属さないアクションや技術的なものを含めることもできます（「開発チーム用に新しいサーバーを購入する」、「製品の広告を作成する」など）。バックログは不必要な詳細を避け、技術的な事柄を細かく管理しようとするべきではありません。製品バックログには、製品に価値をもたらすものをすべて含めることができます。
真のスクラムは1つではありません。場合によっては、個別のバックログが製品を管理するためのより良い方法である場合があります。あなたに最適な方法を見つけてください。
上記の回答はすべて、スクラムフレームワークの信頼できるソースドキュメントを参照できません： The Scrum Guide 。
製品バックログ
製品バックログと、その中に含まれている、しばしばPBIと呼ばれるアイテムを説明するセクションがあります。
製品バックログには、将来のリリースで製品に加えられる変更を構成するすべての機能、機能、要件、拡張機能、修正が一覧表示されます。
しかし、プロジェクト計画のようにfixedではありません。
製品バックログは、製品とそれが使用される環境が進化するにつれて進化します。製品バックログは動的です。それは常に変化し、製品が適切で、競争力があり、有用である必要があるものを特定します。
ユーザーストーリー
user storyという用語は、The Scrum Guideには決して表示されません。
これは、さまざまなプロセスや手法を使用できるフレームワークです。
ユーザーストーリーの使用は、PBIを記録するための1つの可能な手法にすぎません。
さらに：「として、私が欲しいので」の形式を表示することは一般的ですが、それはその 元の意図 に反することができます。この厄介な形式は Agile 2017 でも対処されました。
バグに取り組むとき、それらをバックログに追加し、それらをbug storiesと呼びます。このようにバックログにバグ修正を追加することで、バグ修正だけではないことは明らかです。他のタスクを追加して、自動テストが作成され、検証が行われるようにすることができます。また、DoDに従う必要があることをより明確にします。
PBIという用語を使用したことはありませんが（バックログツールではPBIと呼ばれています）、常にユーザーストーリー、バグストーリーまたは単にストーリーです。
これは主に、チームが選択した用語だけであり、何が本当に重要ではないかがすべて明確である限りです。
プロダクトバックログではユーザーストーリーしか許可されないという一般的な誤解があります。それとは対照的に、スクラムは要求テクニックに対して中立です。 Scrum Primer が示すように、
製品バックログ項目は、明確で持続可能な方法で明確に示されています。よくある誤解に反して、製品バックログには「ユーザーストーリー」が含まれていません。単にアイテムが含まれています。これらの項目は、ユーザーストーリー、ユースケース、またはグループが有用と考えるその他の要件アプローチとして表現できます。しかし、どのようなアプローチでも、ほとんどのアイテムは顧客に価値を提供することに焦点を当てる必要があります。*
@ファルコンはそれをうまく説明しています。正式な定義がある1つのページは次のとおりです： http://en.wikipedia.org/wiki/Scrum_（development）#Product_backlog 少なくともその説明に従って、製品のバックログに入れないでください。
- 製品への変更および追加の明確な仕様は、製品バックログを形成する製品バックログ項目（PBI）と呼ばれます。
- 各PBIは、開発者が開発および提供して、完了時に関連する利害関係者に付加価値を与えることができるものについて説明します（完了の定義を参照）。
- 最も一般的な利害関係者は、市場またはその代表者である製品所有者です。
- ただし、PBIは、企業のコストを削減したり、開発チームの労力を削減したりする作業や、プロダクトオーナーチームが作業を効率化するのに役立つツールについて説明する場合があります。
- PBIは、利害関係者にとって潜在的な価値があるあらゆるものを説明できます。
（ユーザー）ストーリーは、バックログアイテムの便利な標準形式です。その背後にある理論的根拠は、「誰も気にしないのなら、それに時間を無駄にしないこと」です。また、POはアイテムの緊急度を評価することもできます。これは、POを使用して、だれに対してそれを行うか、およびそれがどれほど悪いかを定義するためです。
あなたの場合、バグはストーリーとして簡単にフォーマットできます。
- ユーザーとして
- Xページからログオンできるようにしたい（代わりにエラーが表示されない）
- だから私は時間を無駄にせず、イライラして製品に信頼を失います
努力する価値があるように思えます。