誰が製品バックログにストーリーを追加することを許可されるべきですか？
バックログが混乱するのを防ぐだけでなく、開発者の生産性を維持するためのベストプラクティスは何ですか
製品バックログにストーリーを追加できるのは誰ですか？また、これらのストーリーが特定の要件を満たしていることをどのように確認しますか？
たとえば、機能Xの開発中にいくつかの小さなcssバグを見つけました。開発者として、バグを説明するストーリーをバックログの下部に追加できるようにする必要がありますか？それとも、製品の所有者と話し合う必要がありますか？
すべてのアイデア/バグを製品所有者に渡すことは、ボトルネックの可能性があるようです。
通常のアプローチはanyoneがバックログにストーリーを追加できるというものです。製品の所有者がそれらに優先順位を付け、チームがそれらを推定します。ストーリーの品質の問題は、通常、会議や回顧の計画において何らかの方法で対処されます。
つまり、製品の所有者が割り当てた優先順位に満足している限り、製品の所有者はボトルネックになりません。そうでなければ、あなたの主張をしてください。
私がソフトウェア開発で働いてきたところはどこでも、常にバックログに相当するもの、常にバグレポートのリスト、そして優先順位を担当する人（POに相当）がいたので、あなたの質問はスクラム用語を使用していますが、私見はスクラムに限定されていない。
Googleで「スクラムバックログのバグ」をすばやく検索したところ、一部のチームはバグや問題を「新機能」のストーリーから切り離しているが、そうでないチームもあることが明らかになった。場合によっては課題追跡が使用され、場合によってはWiki、時にはすべてがバックログに直接送られるなど、「どちらが良いか」というコンセンサスがありません。したがって、チームで最初に明確にする必要があるのは、-あなたがこれをどのように処理するか、チームがバックログで何を確認するか、何を処理しないか、および何をするかです。あなたのチームはあなたのケースに最適だと思います。
誰もがバックログに何かを追加することを許可されている場合、それを台無しにするという経験をした場合は、おそらくユーザーストーリーをバグから分離する方が良いでしょう。良いバグレポートがどのように見えるべきかという要件は、新機能の優れたユーザーストーリーがどのように見えるべきかという要件とおそらく異なるでしょう。これもまた別の理由かもしれません。それでも、どちらも開発者の仕事になってしまいます。そのため、それらを1か所に保管しておくのは理由かもしれません。
ただし、ほとんどの製品では、バグレポートをだれでも（ユーザー、テスター、開発者、マーケティング担当者、潜在的な問題に気づいた人なら誰でも）提供できる場合に意味があります。 「新機能」は、バックログに追加する際のプロセスの一部としてPOと話し合う必要があります。あなたのPOは、編集作業を事前に行うために自分でストーリーをそこに入れたいのか、または誰かがストーリーをバックログに入れて後で編集作業を行うのかを決定する必要があります。ただし、バグ、特にレポーターにとって深刻に見えるバグの場合は、バグをトラッカー、バックログ、バグリストドキュメント、またはどこにでも保持するために追加するためのディスカッションは必要ありません。 「議論なし」は、バグレポートを静かにどこかに置くことを意味するのではなく、まったく逆です。バグレポートが追加され、レポーターがそれがおそらくマイナーではないと考えた場合、PO（または責任者）に通知する必要があります。
最後に、チームでこれをどのように管理するかを適切に決定するために、製品のサイズ、バグや新しいストーリーを報告する人の数、週に1つしか報告しない場合はかなりの違いがあります。 、ダースまたは数百。
チームの全員が製品のバックログの下部にバグを投稿することを許可します。アイテムは特定のルールに対応する必要があります（たとえば、再現の条件、正しい動作など）。ただし、新しい機能は個別のリスト「アイデア」に追加され、POはそこからバックログにプルします（明らかにPBIに変換します）。必要に応じて詳細情報を含む）
通常、次のように行います。プロダクトマネージャーは、説明付きのストーリーをプロダクトバックログに追加します。私たちのスクラムマスター（チームリーダーでもあります）は、これらのストーリーをレビューし、十分に明確に定義されていないストーリーについて追加のフィードバックを要求します。計画の週、チームは各ストーリーをタスクに分解します。バグが発生した場合、私たちのチームリーダーがそれらをバックログに置き、優先度もそれぞれに割り当てます。