前回に続いてプロダクトバックログについて書いていきます。 iikanji.hatenablog.jp
デイリースクラム に参加しているときにふと、プロダクトバックログをなんで使っているのだろうと疑問に思ったので、考えてみようと思います。
なぜ必要かを考えるために、そもそもプロダクトバックログにはどういった特徴があるのか考えてみます。
思いついたものとしては、
実現したいことが書いてある
各プロダクトバックログアイテム(以下PBI)が上から下に並んでいる
各PBIの見積もりがされている
といったものがありそうです。
実現したいことが書いてある
実現したいことではなく、具体的なタスクがPBIとして書かれていると、やることは明確ですが、そのタスクによってどういった状態が生まれるのか？誰のためにそのタスクを行うのか？といった背景の理解がプロダクトバックログを見ただけだと伝わりづらいかもしれません。
プロダクトがどういった価値をユーザに提供するのか？プロダクトによって得られるリターンはなにか？ということをチームで検討する上で、実現したいことが一覧になっているプロダクトバックログは有効なものだと思います。
各PBIが上から下に並んでいる
プロダクトバックログでは、各PBIが上から下に並んでいます。プロダクトバックログは上から着手していくので、並べるためには、必ず優先順位を決める必要があります。プロダクトオーナーは 優先順位を決めるためにReturn of Investment(以下RoI)を考慮に入れなくてはいけません。RoIの高いものから順にリスト化されていることで、チームメンバーはそのプロダクトにおいて注力すべき課題や実現したいことを把握することができます。
各プロダクトバックログアイテムの見積もりがされている
各PBIに見積もりがされていることで、予定を立てる目安を作ることができます。 目安があれば大まかな予定を立てることができるので、予定を使ってステークホルダーとの調整に活用したり、目標の設定に使うことができるかもしれません。また、目安があることで、ある一定期間の見積もりに対する実績(ベロシティ)を測定することができるので、チームの状態を測るための一つの指標として利用することができます。
おわりに
プロダクトバックログの特徴として思いついた3つに対して、それぞれその特徴がどういったメリットを持つのか考えてみました。 プロダクトの提供する価値について考えるきっかけを作るため、より重要なものから優先して取り組むため、ステークホルダーとのコミュニケーションを円滑に進めるための予定を立てるため、チームの状態の可視化に活用するため、にプロダクトバックログを使うのではないかと思います。
