こんにちは、技研の「むらたん」です。
先日、客先で開発チームのメンバーとしてスクラムを実践している社員から「スクラムが上手く回っていない」という相談を受けました。
具体的には、以下の内容です。
① プランニングしたポイントがスプリント期間中に膨らみ、予定していた作業を達成できない。その結果、プロダクトオーナーに悪い印象を持たれてしまう。
② ポイントが膨らむ理由は「環境整備」や「調査」のように、プロダクトには直接関係なく、スプリントプランニングで計画しきれていないタスクを行う必要が出てくるためである。
③ そもそも、メンバーによってベロシティが異なるから、ポイント自体の扱い方がよくわからない。
現場を観察しておらず、立ち話で聞いた程度の情報なので外れているかもしれませんが、聞く限りでは以下の印象です。
- ポイントと工数が同じものとして扱われており、ポイントで見積もることの本質が理解できていない。
- プロダクトオーナー（PO）、スクラムマスター（SM）、開発チームというロールの役割と責務の認識が正しくない。
今回のエントリーでは、ここから推測される問題について触れたいと思います。
免責事項
以降、スクラムの用語を用いた説明になります。用語の説明はスクラムガイドあたりを参考にしてください。
① プランニングしたポイントがスプリント期間中に膨らみ、
ポイントはスプリントプランニング時に該当スプリントで対応するプロダクトバックログアイテム（PBI）を選定する基準であり、スプリント期間中に増減することはありません。
スプリントプランニングで作成したスプリントバックログ（SBL）のタスクが増減したり、タスクの工数が計画より増減することはあります。
② ポイントが膨らむ理由は「環境整備」のように、スプリントプランニング中に考慮、計画しきれていないタスクを行う必要が出てくるためである。
残念ながら、これは、スプリントプランニングでSBLをちゃんと作れていないという開発チームの問題です。
開発チームには、スプリントプランニングで合意したことはやり遂げる責務があります。「調査が必要である」「環境構築が必要である」といったことが事前に分かっているのであれば、スプリントプランニングでタスク化することをPOに相談して下さい。
POは開発チームからの申し出を受け、PBIの優先順位の見直しを行います。実施可否の判断基準の1つは「投資対効果(ROI)が最大化出来るか？」です。
「環境整備」は必須の作業だと思われるので優先順位が高くなることだと推測します。
「調査」については、POがその必要性を鑑みて”やる”／”やらない”の判断をしなければなりません。ただし、PO一人で判断ができないのであれば、周りの人たちに相談しても構いません。
① その結果、プロダクトオーナーに悪い印象を持たれてしまう。
うーん、ちょっと残念です。現場じゃないと問題の本質は見抜けないので、全員で課題解決に当たって欲しいところです。
③ そもそも、メンバーによってベロシティが異なるから、ポイント自体の扱い方がよくわからない。
ベロシティは個人に付くものではなく、開発チームに付くものです。
そして、工数換算したくなる気持ちはわかるのですが、それをやってしまうとポイントで見積もっている意味がなくなってしまいます。
ポイントと工数の目的はバックログの役割を考えると、理解が早まります。
| プロダクトバックログ | スプリントバックログ | |
|---|---|---|
| 目的 | 要求事項の見える化, 優先順位の見える化, 受入条件（AC：Acceptance criteria）の見える化 | 実現手段の見える化, 担当の見える化, 工数の見える化 |
| 所有者 | プロダクトオーナー | 開発チーム |
| 見積もり手法 | 相対見積もり | 絶対見積もり |
| 見積もりの単位 | ポイント | 時間 |
| 作成のタイミング | 最初のスプリント, PBLリファインメント | スプリントプランニング, スプリント期間中 |
- プロダクトバックログを作る。（各PBIのACを明確にして、PBIを積み上げる）
- PBIに優先順位をつける。
- PBIのうち、最も規模が小さそうなアイテムを「2ポイント」とする。
- 「2ポイント」とする理由は、先々で更に規模の小さいアイテムが発生することを考慮している。
- 「2ポイント」としたアイテムが1スプリントで終わらなさそうな場合は、PBIを分割する。
- 「2ポイント」と決めたアイテムと比較して、4倍ぐらいの規模のものを「8ポイント」と定める。
- 上記の2アイテムと比較して、その他のPBIのポイントを決める。（プランニングポーカーがオススメ）
プランニングポーカーはアジャイル開発で見積もりを行うときに使われるプラクティスです。
メンバーがトランプのようなカードを持ち、掛け声に合わせて見積もり対象アイテムのポイントを提示します。
ここで出す数値は「ポイント」です。
提示した数値の差異（＝チーム内の認識差異）を埋めることが目的です。（≠工数を見積もるもの）
白紙カード、？カード、数字カード（BIG＞100＞40＞…＞2＞1＞0）
- 「白紙カードを出した人」は休憩を取りたいという意思表示なので、休憩後に再見積もりする。
- 「？カードを出した人」が不明点を述べ、他のメンバーが認識を合わせて再見積もりする。
- 「数字カードの最も大きい数字と最も小さい数字を出した人」がそれぞれの見積もり根拠を述べ、チーム全体で認識を合わせて再見積もりする。
これを繰り返していくと、PBIに対する要求事項の理解が整理され、タスクに落とし込めるようになります。
- プロダクトバックログから優先順位の高いPBIを取り出し、ACを満たすタスクを洗い出す。
- タスクに対して、担当者とチームを割り当てる。
- 開発チームが1スプリントで稼働できる時間内に収まるようにタスクを積み上げる。
- 作業が中途半端になってしまうようなPBIがあれば、PBIを分割する。
- プロダクトバックログは「要求事項」が管理されており、実現方法には言及していないため、工数を算出することが出来ないのです。
- スプリントバックログはPBIの「実現方法（タスク）」が管理されており、工数を算出することが出来ますが、タスクが粗いと見積精度も下がってしまうので、タスクは細かく管理するようにしましょう。
