複数チームでのバックログリファインメント

f:id:tune:20180527163528p:plain

概要

LeSS(Large Scale Scrum)で推奨されている複数チームでのバックログリファインメントのやり方。

詳細

LeSSは「基本スクラム」なので、定期的にリファインメントを実施し、直近数スプリントのバックログの見通しがつくようにしておく。

1. Overall Product Backlog Refinement (全体バックログリファインメント)

プロダクトオーナー、スクラムマスターまたはチームの代表者が集まり、Multi-team Product Backlog Refinementへ回す項目をピックアップして選択する。Multi-team Product Backlog Refinementに先立って実施する。

2. Multi-team Product Backlog Refinement (複数チーム混成バックログリファインメント)

開発チーム(スクラムチーム)で見積もりをしてもらうのではなく、チーム横断の混成グループをつくり、グループで分担して見積もりをしてもらう。例えばOverall Product Backlog Refinementで15のストーリーを詳細見積もりする必要があると判断し、開発チームが3つある場合、全開発メンバを3グループにわけ、5つのストーリー詳細見積もりを各グループに依頼する。アイテムの詳細見積もりにステークホルダーの知識が必要になることもあるので、同席してもらえるならばMulti-team Product Backlog Refinementに招待するとよい。

f:id:tune:20180527163502p:plain

全グループが1箇所に集まり、バザール形式で開催する。ステークホルダーやグループ外メンバの知識が必要であれば声をかけて場所を移動してもらい相談する。

チーム横断グループを構成することで下記のメリットがある。

見積もり(ストーリーポイント)のチーム間のズレが抑えられる。
チームがストーリーに着手した際に、見積もりに参加したメンバがいることが期待できる。

プロダクトオーナーはMulti-team Product Backlog Refinementに参加しない。これは開発メンバが増えるとプロダクトオーナーが開発全体のボトルネックになってしまうからである。プロダクトオーナーがいないと見積もり時に生じた疑問を解消できない課題があるが、逆に開発メンバに考えてもらう好機と捉え、各グループで「疑問」とそれに対する「決断」を簡単に残すようにするとよい。開発メンバには決断する練習機会となり、チームが自律的に開発を進める土台が固まる。またプロダクトオーナーは「疑問」と「決断」の記録をあとで参照することで、自らの考えがどの程度開発メンバに伝わっているかを確認することができる。