tuneの日記

アジャイル開発、組織変革、ファシリテーションについて学んだことの記録

プロダクトバックログリファインメントに関する10の改善案(10 Experiments With Product Backlog Refinement)

はじめに

medium.com

昨年公開されたブログ記事で、プロダクトバックログリファインメントをより良くするために行なった10の施策が面白かったので紹介します。 「10の改善案」とありますが、続きものもあるのでアイデアとしてはもう少し少ないです。

10の改善案

1. 「ストーリーが着手できる状態」についてチームと合意する (Agree a Definition of Ready with the team)

「スプリントの始まりにプロダクトバックログの先頭にあるものが着手するものだ」ではなく、着手できる条件を明確に決めておき、着手できないのであれば時間を作って事前にもう少し詳細化しておきましょうねというものです。

「ストーリーが着手できる状態」は「1. リファインメントができる状態」と「2. ストーリーが着手できる状態」に分けて考えないといけません。

定義すると、例えば以下のような感じでしょうか?

  1. リファインメントができる状態
  2. なぜ実装するのか、誰にとっての機能なのかなどが明確になっている。
  3. どういうUI/UXにするか、どういう設計にするか、作業見積もりができる程度まで明確になっている。
  4. ストーリーが着手できる状態
  5. チームがストーリーをタスクに分解できるだけの情報が備わっている。
  6. どういうUI/UXにするか、どういう設計にするかがスプリント内で取りかかれる程度まで明確になっている。

2. 誰がリファインメントを担当するかを決めておく (Decide ownership, then allow others to opt out.)

全員で見積もりすると時間の無駄になるから、「このストーリーを担当するのはこの人たち」とあらかじめ任命してしまうというものです。

個人的にはスクラムマスターと、一番詳しい人と、分野外でツッコミ入れてくれそうな人をランダムで呼び集めれば事前に決めるまでしなくても良いのではないかと思います。

3. チーム内に階層があることを理解する (Acknowledge the existence of hierarchy.)

マネージャーやQA責任者といった組織上の上位階層に位置する人を尊重し、イベントに参加できるように取りはからいましょうというものです。 事前に呼ぶことを伝えておけば、リファインメントに参加できなくても適切な人を代役に立ててくれるはずです。

4. プロダクトバックログリファインメントは同じ時間に開催する (Schedule PBR Sessions at Same time every day.)

タイトル通りです。

私は英語を誤読していましたが、「毎日同じ時間にリファインメントをスケジュールしよう」ではなく、「リファインメントをスケジュールするなら時間を都度決めるのではなく、やるならこの時間と決めておこう」という意味のようです。

5. リファインメントに回すユーザーストーリーを事前に回覧する (Circulate User Stories 48 hours in advance)

2日前(48時間前)に回覧できるかは分かりませんが、会議の議題を事前に送るのが有効なように、やった方が良い施策だと思います。 一方で自分の経験で、送ったこともありましたが、必ずしも読まれるとは限りません。

原文でも言及されいるようにリファインメントの最初に「回覧したストーリーは読んできましたね」と毎回確認し、「事前に読んでおかなければならないもの」と印象付けるのが良いと思います。

6. リファインメントの結果をSlackに流す (Slack Channel with details of Refinement done that day)

RedmineとかJIRAとか何らかのIssue管理システムを使っていればRSS配信や外部システム連携機能が備わっているので設定すれば任意のチャンネルに自動投稿ができるようになります。 私もやったことがありますが、スクラムマスターがたまに見てくれているぐらいです。効果があるのかはよくわかりません。

7. リファインメントの進捗状況がわかるようにカンバンボードを用意する (Kanban Board for Refinement Process)

「リファインメント待ち」「議論中」「デザイン待ち」「設計待ち」のように、各ストーリーがどの状態にあるのかを見える化するという施策です。 プロダクトオーナーが思いついてからチームが着手するまでによくよく議論するチームはこういう施策が必要なのかもしれません。

私の経験では必要になったことがないので分かりません。

8. (7の続編で)リファインメントの進捗状況がわかるようにTrelloでボードを用意する (Trello Board for Refinement Process)

7をWeb化したものです。コツは7が成功して、効果を感じられるようになってから8をやることだそうです。

9. (4に近いが)リファインメントの開催スケジュールをスプリントの始めに決めておく (Prepare Refinement Schedule at Start of Sprint)

プロダクトオーナーの思いつきで開催するのではなく、きちんと事前に決めておきましょうというものです。 スプリントごとにリファインメントの打ち合わせ日時を変えるメリットはさしてないと思いますので、「毎週何曜日の何時から何時はリファインメントの時間だから空けておくように」と決めておくのがよいとおもいます。

10. スパイク(着手前の事前調査)が発生することを許容する (Please Please Please: Allow for Spikes to happen)

安定して成果を提供できるようにするには事前の準備が欠かせませんが、スケジュールがタイトだったりするととにかく実装しろというプレッシャーをかけてしまいがちなのでやめましょう。

おわりに

原文では導入した詳細な背景、おすすめ度なども言及されています。 興味がある方はぜひとも参照下さい。