■ 1. バックログ管理の重要性と共同作業
- プロダクトバックログはチームの方向性を定義する重要なアーティファクト
- プロダクトマネージャーはバックログ管理における禁止事項を明確に理解する必要がある
- バックログ管理は共同で行う活動であり、全員が協力して取り組む
■ 2. PMだけが管理するという誤解
- PMはプロダクトの成果に責任を持つが、バックログアイテムを追加できるのはPMだけではない
- PMはチームやステークホルダーに新しいバックログアイテムの作成を促すべき
- 協力体制がなければPMがボトルネックになるのは時間の問題
- 従来の手法では要件管理が協働的でなかったため、この誤解が生まれやすい
■ 3. 古いバックログアイテムの放置
- バックログは生きたアーティファクトであり、継続的なレビューが不可欠
- 2年以上前のアイテムがバックログに残存するケースは問題
- 3ヶ月以上経過したアイテムはすべて削除することを推奨
- このアプローチによりチームの生産性と効率性が向上
- 古いアイテムを残すとバックログ全体が牛乳のように古くなる
- バックログアイテムに執着せず、アジャイルの学習加速という目的を優先する
■ 4. 複数のバックログへの分割
- バックログをテクニカルと機能で分割することは大きな誤り
- プロダクトバックログは1つのみであるべき
- 複数のバックログが引き起こす問題:
- チーム間の協力関係が大幅に低下する
- サイロ化が現実のものとなる
- PMと開発者の間に不一致が生じ、チームパフォーマンスに悪影響をもたらす
- プロダクトチームは単一のバックログをともに管理・順序付けする方法を見つける必要がある
■ 5. バックログ精査の不足
- 精査セッション不足はアンチパターンであり避けるべき
- 不十分な精査によりチームは検査・適応の機会を失う
- すべてを事前に把握していないことを認め、継続的な精査が必要
- 推奨する精査の目安:
- チームキャパシティの10%以内をバックログ精査に継続的に充てる
- 2週間スプリントの場合、精査に1時間30分を投資する
■ 6. 過剰な洗練
- バックログアイテムを過剰に精査することもアンチパターン
- バックログは順序付きリストであり、上位アイテムほど詳細、下位アイテムほど粗い状態が適切
- 過剰な事前計画の問題点:
- スプリントを重ねるごとに学習が進み、過剰に精査されたアイテムが陳腐化する
- 下位アイテムについては情報が限られるため、詳細な精査は不適切
- まず上位アイテムを精査し、学習を重ねながら他のアイテムを順次精査していく
■ 7. 過剰な計画（オーバーサイズ）
- ウォーターフォール手法やプロジェクト管理の背景を持つPMは過剰計画に陥りやすい
- ウォーターフォールでは要件はすべて事前に定義され、チーム自身は関与しない
- アジャイルでは進むべき道が事前には分からないことを受け入れる必要がある
- アジャイルは経験的であり、実践と学習を通じて方向性を発見していく
■ 8. 成功するバックログ管理の条件
- PMは全員に新しいバックログアイテムの作成を促す
- バックログの調整は必要に応じて頻繁に行う
- 3ヶ月以上経過したアイテムは議論なしで削除する
- プロダクトバックログは1つのみ維持する
- 精査はバックログ上位のアイテムのみに集中する
- 事前に全ての計画は行わず、学習を通じて適応していく