スクラムでは、バックログを機能的なバックログと技術的なバックログに分割する必要がありますか？

スクラムチームでは、バックログを使用します。バックログには主に機能的なトピックが含まれますが、技術的なトピックも含まれる場合があります。バックログが1つあることの利点は、次のスプリントのトピックを選択しやすくなることですが、いくつか質問があります。

• まず、私にとっては、開発者自身が純粋な技術項目を追加できる個別の技術的バックログを持つ方が論理的だと思われます。開発者は常に製品所有者を経由してトピックをバックログに追加する必要がありますが、これは製品所有者にとって追加の不必要な作業のようです。
• 第二に、純粋な機能アイテム、純粋な技術アイテム（技術文書の欠落、浸食されてリファクタリングされるべきコード、デバッグ中に常に問題を引き起こすクラスなど）安定した基盤であり、リファクタリングする必要があります、...）「顧客に直接サービスを提供しない」ため、常にリストの最後になります。個別の技術バックログを持ち、これらの純粋な技術アイテムのすべてのスプリントで時間を確保することにより、アプリケーションを機能的に改善するだけでなく、内部の健全性を保つことができます。

最善のアプローチは何ですか？1つまたは2つのバックログ？

私は専門家ではありませんが、チームごとに1つのバックログしか持つことができないと思います。チームは、どの問題が緊急で、どの問題を延期できるかを決定する必要があります。課題を別々の種類のスタックに分けると、スクラムの中心にあるコアアイデアに反することになります。つまり、課題のプールがあり、各スプリントがそれらの最も緊急に取り組むということです。チームを（サブ）分割すると、それらに関連するタスクのタイプを分割できる場合がありますが、基本的には並行して作業するチームを設定することになります。緊急性/必要性は、次のスプリントを計画する際の最大の決定要因です。タスクを分類することもできますが、これが意思決定プロセスの邪魔になることはありません。

製品ごとに1つのバックログを推奨する人に私の声を追加したいと思います。別のバックログを作成することは合理的な対応ですが、実際にはコアの問題を回避しているだけです。プロダクトオーナーが機能アイテムよりも技術アイテムを優先しないのはなぜですか。この問題を回避するのではなく、解決することに集中する必要があります。たとえば、5つの理由のテクニックを使用して、物事の底辺に到達しようとすることができます。

POが技術的な問題を優先しない多くの理由が考えられます。たとえば、技術チームが技術的負債に対処しないことの長期的なコスト（$$$）を説明していない可能性があります。たぶんそれは完全に別のものです。コミュニケーションの問題が原因である可能性が高く、長期的な解決策はそれに取り組んで解決することです-障害を取り除きます。

さらに、もう1つ質問があります。そもそも技術的な負債が発生したのはなぜですか。理想的には、リファクタリングなどの作業は機能的なストーリー内で行われ、スプリント内で完了する必要があります。それらは、それ自体が余分なストーリーであってはなりません。そうでなければ、潜在的に出荷可能なコードがありません。

あなたが言っていることは、一般に「技術的負債」と呼ばれています。欠陥と同じように、技術的負債の仕組みがスクラムプロセスにどのように適合するかを確認するのは難しい場合があります。

あなたが提案しているのは、バックログを3つに分割する「欠陥バックログ」も別にあることを提案するのと似ています。

個人的には、製品のバックログを分割することはまったく勧めません。製品バックログのアイデアは、傑出した作業項目を表すことです。その観点から、機能と技術的な負債項目の唯一の違いは、要件が顧客からではなく、開発チームから来たことです。これはまだ作業項目であり、他の作業項目に対する優先順位付けなど、管理する必要があります。これは、技術的な負債項目にテストが必要な場合に特に当てはまります。その場合、通常の機能とまったく同じQAプロセスを実行する必要があります。

プロジェクトごとにバックログが1つだけであるという点で、私はOnnoに同意します。それ以外の場合、チームは基本的に製品所有者に正当に属するいくつかの決定を自分の手で取っています。

「純粋に技術的な」アイテムであっても、スプリントバックログの対象となるには、ユーザー（および製品所有者）にとって実用的な価値が必要です。これらの利点を製品所有者に説明し、コストを正当化する付加価値を彼/彼女に納得させるのはあなたの仕事です。このプロセスにより、これらの問題を熟考し、最小限の労力でプロジェクトに最大の価値をもたらす技術的な変更を選択するようになります。

上記のすべての回答に同意します。商業的な現実の中で、POは技術的なストーリーよりも機能的なストーリーを優先し続けます。多くの場合、チームのフラストレーションに。チームは、ユーザーの価値のない技術的なストーリー（速度が問題にならない場合、最適化に関心があるのは誰ですか）を控え、機能的なストーリーによって暗示される他の特定の技術的なタスクを確認する必要があります。「完了の定義」も大きな役割を果たします。残りの機能ストーリーは、POが優先順位を付けるためにバックログに記録されます。

例えば、技術文書：技術文書の利用可能性（該当する場合）は、DODに属する典型的な項目です。したがって、機能ストーリーの更新は暗黙的に行われます。

たとえば、コードのリファクタリング：製品開発にメリットがある場合に実行する必要があります。早めではなく（チームは製品がどの方向に進化するかを想定すべきではありません）、それがすでに技術的負債になったときではありません。設計をレビューすることもDoDの一部です。

MelRに同意します。「技術的」なものがある場合は、なぜそれを行っているのか、あるいは（ユーザーにとって）短期的および長期的な原因と結果は何かを調べる必要があります。

私は、いわゆる「技術的なタスク」がビジネス価値のような方法で簡単に記述できる多くのバックログを見てきました。

多くの場合、技術的なタスクは、物事を分類するより簡単な方法になる可能性があるため、大規模な分類されたストーリーの結果でもあります。しかし、これにより真の付加価値の反復が遅くなり（フィードバックの機会）、スプリントの失敗がさらに悪化する可能性があります。

「侵食され、リファクタリングされるべきコード」に関して、パトリックが言及しているように、私たちは尋ねる必要があると信じています-そのコードがシステム機能のどの領域に影響しているのでしょうか？そして、今それをリファクタリングしない場合、ユーザーに長期的な影響は何ですか？

それから、長期的な技術的負債を減らすために「私たちが見つけたよりも少し良いものを残す」という主題があり、これは各プロジェクトの小さなストーリーの一部として、より広いプロジェクトにあまり影響を与えずに行うことができますか？

最終的に、2つのバックログの必要性は見当たりません。これにより、適切に優先順位付けされたニーズを遅らせる機会が開かれますが、技術的影響の懸念について教育を受け、真の価値を特定する強力な能力を備えた製品所有者が必要です。ストーリーを垂直方向に分解する-Adobeは垂直方向のスライシングについて適切な説明を提供します。

いいえ、技術的なストーリーを作成しないでください。これは一般的なエラーです。ストーリーはビジネス要件を反映する必要があります。技術的なものはビジネス要件から決して決してありません。これがスクラムマスターとチームの役割であり、目的またはストーリーを達成するために必要なすべての技術的タスクを評価します。

たとえば、ログイン画面の作成に関するストーリーの場合、まだ作成されていない場合はデータベースの作成も考慮する必要があります。

ITチームがユーザーであるタスクをPOで作成する問題は見当たりません。POがタスクを理解し、ビジネス価値の観点から評価できる場合、はい、技術的なストーリーを作成する方法があります。システムを使用するだけです。