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