スクラム：テクニカルPO以外のPOによって管理されるバックログ内の技術項目はありますか？

Question

"v1からv2へのアップグレード"や "スタートアップパフォーマンスの向上"や "コードの複雑さを減らすためのログインモジュールのリファクタリング"などの技術項目を製品バックログに含める必要があります。他のより機能的なバックログ項目との優先順位付け？

技術的な内容のバックログが必要ですか？製品のバックログに機能的および技術的な事項を優先させることができる2名の人物とのPOの共同役割が必要ですか？

Answer 1

私は二重のバックログのアプローチで成功を収めている：

1. プロダクトバックログは、製品の所有者が所有しています。これは、チームによって推定され、次に製品所有者によって優先順位付けされるストーリーレベルのアイテム（機能）を含みます。この推定プロセスは、より小さなタスクでストーリーを分割します。

2. チームバックログは開発チームが所有しています。これには比較的小さなタスクレベルの項目が含まれています（スプリント内で完了することができます）。それらは、障害物としての物語などにリンクさせることができます。物語を完成させるには、まず以下の技術的作業を完了しなければなりません。彼らはまた、ストーリーそのもののために必要とされないように独立しているかもしれませんが、将来のより高い速度を可能にするためにいくつかの技術的負債を返済します。

（私も所有しており、さらに上の製品バックログに話を分割する、プログラム管理チームによって優先順位付け叙事詩レベルのアイテムを、含まれているプログラムのバックログを持っていたいくつかの大規模な、マルチプロジェクトのプログラムに。 ）

Answer 2

通常、 'vanilla' SCRUMでは、あなたが言及した技術的な仕事は別々の物語にはなりません。

私には、技術者以外のPOは、「サーバーのアップグレード」のような記事を見てはいけません。それはビジネス上の話ではなく、エンドユーザーには見えないため、このように定式化されている場合、優先順位を付けるのは難しいです。優先順位は、作業のビジネス価値に応じて割り当てる必要があります。 「アップグレードする」という意味ではありません。 'より多くの同時接続を許可する'、 'ダウンタイムを減らす'、または「チームの速度を向上させる」さえも、技術者以外の人にとってははるかに貴重な洞察を提供するかもしれません。技術的でない記述が見つからない場合は、アップグレードの必要性について質問してください:)

「リファクタリング」のストーリーはさらに複雑です。なぜそれがすべての話ですか？リファクタリングはストーリーのタスクとして行うことができますが、それ自体は物語ではありません。だから、あなたがログイン作業をより良くしたい、あるいは物語であるより多くの機能を提供したいのであれば、ボンネットの下で手直しすることは1つに数えられません。ビジネス目的のないリファクタリングでは、いわゆる「金メッキ」が発生する可能性があることにご注意ください。

「パフォーマンスの向上」と「再因子化」のスパイクとしての「アップグレード」ストーリーの提案関連するビジネスストーリーのタスク。

P.S. Mike Cohnの "User Stories Applied: For Agile Software Development"と呼ばれる優れた本では、このトピック（主にその一部の3つ）に関する良い議論を見つけることができます。

Answer 3

私は、私がチームの速度/性能に係る内部の物語があることだと思いますいずれかの技術的な話のビジネス上の利益を見て、主な製品バックログ

上でそれを追跡するの見解に同意します特にプロダクトオーナーがそのストーリーの優先順位付けや管理に興味がない場合に、開発者にいくらかの能力を割り当てることで、より便利に管理されることがあります。 など。自動化されたバックログ（従来の回帰の）、CIサーバーの設定などをテストするために10％の容量を割り当てます。

はい、すべては確かにビジネス用語で表現できますが、プロダクトオーナーとチームの間に信頼関係がある場合、チームはこれに割り当てられた容量を最大限に活用します。