こんにちはー。藤井 (@yoshiyoshifujii) です。
Akkaってスウェーデンの山の名前なんですって、ご存知でした？わたしは知りませんでした。 そういえば、Akkaのロゴって山っぽいですもんねー
さて、今回の標題の件ですが、ひらたくいうと、
「プロダクトバックログを作成して、バーンアップチャートを作り、Velocityを計測して、観測しましょう」
ということになります。
アジャイルの書籍やコミュニティでの発表など、それが必要で効果のあることだと分かってはいたのですが、なかなか実践できておりませんでした。
先日、Scrum Inc.主催のLicensed Scrum Product Owner研修を受けさせていただき、その中で教わった内容を、早速、現場で実践したところ、チームの評判も良く、ステークホルダーへの説明にも効果を発揮しそうな肌感を得ておりますので、そのあたりをご紹介できればと思います。1
前提
今回、私が適用させていただいた現場を前提として紹介させていただきます。 銀の弾丸では無いと考えており、前提が揃わない場合も適用して上手くハマるとは言い切れないと考えております。
得たいモノのイメージを共有する
まずは、どういったモノが欲しいのか、そのイメージを共有します。
所謂、プロダクトバックログと、バーンアップチャートなのですが、それがどういったモノなのか、人によって想定するモノが異なると思います。 擦り合わせのためイメージを共有します。
プロダクトバックログのイメージ
プロダクトバックログ(PBL)の定義は、 The Scrum Guide に書かれています。
プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。 プロダクトに対する変更要求の唯一の情報源である。
(省略)
プロダクトバックログは決して完成しない。構築の初期段階には、明確でよく理解できている要求 が並べられている。その後、プロダクトや使用環境に合わせて進化する。プロダクトバックログは動 的であり、適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化する。プロダク トが存在する限り、プロダクトバックログも存在し続けるのである。
この文章を読むことで、得たいモノが一致すると助かるのですが、今まで色々なプロジェクトでスクラムを経験されてきた歴戦の猛者であったり、未経験であったり、それぞれのバックグラウンドのプロダクトバックログをお持ちだと思います。
そこで、それらを一致させるのに、以下の図を提示しました。 こちらの図は、LSPO研修で拝見しました。 今回はその図を自分で模写させていただき、イメージの擦り合わせに使わせていただきました。
この図を見て読み取れることを、ざっと整理しますと…
- 1のPBLは、直近のチケットの大きさがバラバラで、優先順位も付けられていない
- 2のPBLは、全てのチケットの大きさが分割されており、優先順位が付けられている
- 3のPBLは、直近のチケットの大きさが分割されており、優先順位が付けられており、3月以降は大きさも優先順位も曖昧で、来期まで含んでいる
- 4のPBLは、直近のチケットの大きさが分割されており、優先順位が付けられており、3Q以降は大きさも優先順位も曖昧で、5年後まで含んでいる
- 5年後には星にロケットを飛ばそうぜ！
といった違いのあるPBLだと分かります。
この図をチームに提示して、今から作ろうとしているPBLのイメージを合意します。
「1は違うなー、2はウォーターフォールっぽくて今回のような複雑系を扱う場合は合わないなー、3か4だなー、今回は、5年後まで含めたくないから、3でいきたいなー」といった会話を通して、3のPBLを作りたいといった合意形成をする感じで進めました。
バーンアップチャートのイメージ
次にバーンアップチャートのイメージを合意します。
このような図になるのですが、縦軸に相対見積りのポイントをとり、横軸に経過時間を取ります。
黒い線は、Velocityをプロットしておりますので、時間の経過と共にoutputしたポイントを取ってます。
そのうえで、上手く進めることができた場合の傾きが緑の線で、上手く進めることができなかった場合の傾きが赤の線となってます。
このようなチャートを書くことで、時期を固定したときに得られるoutputの範囲が分かります。
また、逆にスコープを固定することで、期間を得ることができます。
このようなチャートを作成し、スプリントが経過するごとに、outputを得られる時期や量を常に計測し続けることを繰り返して精度を上げていきたいということを共有しました。
こちらは、 Agile Product Ownership in a Nutshell - Youtube の中で説明されている図を模写させていただきました。 この動画は、LSPO研修で視聴したのですが、とても短くProduct Ownerに求められることが説明されており、自分なりの解釈が色々と出来ました。
進め方
最終的に得たいモノとして、プロダクトバックログとバーンアップチャートだよと、そのうえでスコープとスケジュールについて、計画し続けて行きたいんだよ、具体的なイメージはこれだよ、といったことを合意した後、じゃあ、どうやって進めていくかを決めます。
- 優先順位の決め方
- 見積り方法
主にこの2点について、合意します。
優先順位の決め方
取り組むチケットについて、優先順位をどう考えるか、どのように決めていくかを合意します。
1つずつ、チケットを見比べて、こっちのほうが高い、こっちのほうが低いと仕分けていく手法もありますが、「価値と労力」の2軸において優先順位を決める方法があります。
なお、なんでもかんでも、このやり方で優先順位を決めるという話ではありません。
縦軸に価値を置き、横軸に労力を置いた場合、右上が「価値が高く、労力も高い」となり、左下に「価値が低く、労力も低い」となっております。
こういったチケットの優先順位は、以下のように考えます。
「価値が高く、労力の低い」チケットから優先的に取り組むと良く、「価値が低く、労力の高い」チケットについては、取り組まないとします。
この基準に則って、見積り、優先順位を決めていくことで、合意形成をします。
見積り方法
では、価値と労力の見積りをどうやると良いのか、といったところを合意します。
アジャイルな見積りの戦略としては、以下のように考えます。
- 時間を見積もらない
- 時間見積りは間違いが多く、変動も大きかったり、人間は相対的な大きさで区分するのが得意であることなどが研究で分かっているそうです
- 見積りは実際の作業をする人たちがする
- 仕事をやって欲しい人たちではない
- プロジェクトの開始前だけではなく期間を通じて常に見積りをする
- PBLのイメージを合意したように、直近だけ見積りをし、先は適切に見積りをしないので、体験を経て見積り精度を高めるプロセスを踏んでいく
- 詳細に記述したドキュメントより、口頭での会話を用いる
- だれかが記述したドキュメントを受け取って見積りをするのではなく、その記述をする人も参加して口頭でやり取りをします。
そのうえで、相対見積りの手法を2つ用いました。
- アフィニティ見積り
- プランニングポーカー
プランニングポーカーは、有名で実践されていることも多いのかなーと思いますので、今回はアフィニティ見積りを紹介します。
なお、プランニングポーカーも、簡易に実践するため、以下の条件を付与して実施しております。
- 全員の数字が連続する3つの範囲に収まっているのであれば合計して平均値を出し、次のタスクに移る
- 擦り合わせは不要、コンセンサスを目指しているわけではない
- 最終的な見積り値はフィボナッチ数にならなくても良い
アフィニティ見積り
ルールとして、
- しゃべらずに、メンバは動物の付箋を適切なサイズと思われる青付箋の下に動かす。
- ただし、ブルドッグは動かさない
- すべての動物の付箋を動かしたら、1人、ひとつの動物だけをさらに動かすことができる
- 相対サイズをポイントに変換し、見積りを終える。
といった方法です。
このように人間の相対的に区分できる能力を活かして見積りをするというやり方を取り入れて見積りをしました。
ストーリーマップで見積る
以下のようなTemplateを用意してストーリーマップに取り組んだ後、見積りをします。
ざっと、以下のように進めました。
- エピックとストーリーの粒度をあまり気にせず発散をします
- 議論をしながら収束し、エピックとストーリーを整理します
- エピックに着目し、ストーリーはエピックの理解の補助として使うような状況にします(一旦、ストーリーよりエピックに集中する感じです)
- エピックの労力を見積ります
- 価値の軸について話し合い、合意します
- エピックの価値を見積ります
- ポイントあたりの価値を計算し導出します
- ポイントあたりの価値が高いエピックに着目し、優先順位を一番とします
- 優先順位一番としたエピックに取り組むために必要となりそうな依存関係のあるエピックを探します
- 依存関係の深いエピックを一番最初に取り組むことに合意します
- 依存関係の深いエピックを完了させるのに必要なストーリーを発散、収束し、優先順位を付けて並べます
- 依存関係の深いエピックを完了させるのに出したストーリーの労力を見積ります
- 見積ったストーリーを合計し、エピックに対するストーリーポイントの合計を出します
- エピックに対するストーリーポイントの合計で、エピックの労力のポイントを割り、1エピックポイントあたりのストーリーポイントを算出します
- 1エピックポイントあたりのストーリーポイントを、他のエピックの労力ポイントに掛けて、全てのストーリーポイントを換算します
- 全てのストーリーポイントを合計します
上記のように進めることで、全てのストーリーポイントを導出することができます。
やってみた結果が以下です。
流れを絵に落とすと以下のようになります。
優先順位が最も高いエピックを完成させるのに必要なエピックを辿り依存関係を明らかにしたうえで、一番最初に着手するエピックを決めて、そのエピックのストーリーのみ詳細に議論をし、ストーリーポイントを見積り、あとは換算で全体のストーリーポイントを出すということができました。
これにより、当初、PBLのイメージで認識を合わせておりました、
「3のPBLは、直近のチケットの大きさが分割されており、優先順位が付けられており、3月以降は大きさも優先順位も曖昧で、来期まで含んでいる」
が得られていると思います。
あとは、実際にチームが3スプリントほど回してみて、Velocityを取ることができれば、バーンアップチャートを描くことができます。
Velocityについては、実際にチームが3スプリントを回すまで、「だいたいこれぐらいかなー」というのは言わないようにしています。
そこの値を仮でも良いんで当て推量で決めたところで、3スプリント回してVelocityを得ればそれが全てですし、その推量が合ってようが間違ってようが何の意味もないんじゃないかなーという感覚が拭い切れないためです。
3スプリント回すのも勿体ないとか、そんな余裕すらないのであれば、チームで議論してVelocityを仮に置いてもいいですが…なんか…ねぇ…
まとめ
ざっくりとですが、手法について紹介させていただきました。
この方法を実践してみた手応えとしては、かなり早く、必要なところはきちんと議論をして、全体の認識を合わせつつ見積りを進めることができたのではないかと思います。
とはいえ、Velocityの計測は現在進行形でして、このワーク自体、やってみたのも2、3週間ほど前と、ほやっほやだったりしますので、実は全然でしたーってことになるかもしれませんが…
また、進捗次第で得た知見を、どこかしかで発信する機会が持てればなと思います。
以上です。
-
もっと詳しく体系立てて学びたいよという方は、ぜひScrum Inc.主催のLSPO研修を受講していただければと思います(宣伝)。↩
-
Cynefin framework - Wikipedia における複雑系を指しております。↩
-
スクラムのフレームワークの全てを適用していなくても良いのかなーと考えているのですが、とはいえ、検査と適応をイテレーティブに実施していないといけないのではないか、と思ったり…↩
