対象とする人

一通りアジャイル開発に関する教科書的知識を理解している気はある。
が、なんか腹落ちしない、うまくできている気がしない人。

まえがき

アジャイル開発を学んでいると、人によって言っていることが違っていたり、教科書的にやったら現場ではうまくいかない...
などなど何かと疑問と不安が湧いてきます。
それらの疑問に対してQA形式で細かい疑問を整理しました。
これを読んで、もやもやした気持ちを少しでも晴らした上で開発に取り組んでもらえればと思います。

QA

相対見積もりの判断軸を時間にしてはいけないなら、何を判断軸にするの？

バックログを実行する際の工程の量が基準になります。

時間を判断軸にすると力量差があるメンバー同士で見積もり結果が異なりやすくなります。
（Aさんが行うと２時間、Bさんが行うと３０分）

工程の量であればAさんもBさんもやること自体は一緒となるので、人によって大きく変化することはありません。

※工程の量というのは人によって差異が少ない指標の一つであるだけであり、よりよいものは他にもあるかもしれません。

とはいえ、工程の量の見積もりも人が想像するものによって変わってくるのでは？

ここでやっとプランニングポーカーの出番です。

バックログに対する工程の量の認識が一緒であれば見積もりも人によらず、大幅には変わらないはずです。

それでも変わってしまうということは各々が想像する工程に抜けがある、そもそもやり方が違うということが考えられます。

そこで、私はこういう工程も想定していた、こういうアーキテクチャを想定していたという意思疎通を交わすことで、
よりよいやり方、抜けのない工程を最初の段階で洗い出すことができるのです。

力量差がありすぎて工程の量の見積もりでも差がありすぎる！

そういった場合には担当者を決めてしまって見積もるということも１つの手です。

ただし、機能横断的でない組織はそもそもスクラム開発に反するものなので、是正できるような手を打ちましょう。

なんでプランニングポーカーではフィボナッチ数列を使うの？

直感的に相対見積もりをする際に、基準より倍かどうかは考えやすいからです。

フィボナッチ数列は前２つの数を足すということによって得られる数列です。
1, 2, 3, 5, 8, 13, ...

この数列の特徴として、ある数の前の数は1/2より少し大きく、次の数は二倍よりも少し小さいです。

つまり、他のバックログに対して、２倍、３倍より大きいか小さいという粒度で判断できるため、
ポイントを見積もる上で迷いが少なくなるです。

また、これだけ明確なレンジがあるにも関わらず迷いが生まれる場合には、ストーリーの分割ができていないとも考えられます。

PJ毎に扱うユーザーストーリーが変わったら基準が変わってしまう？

プロジェクトに関係なく、「このバックログの作業量を２にします」というのをずっと持つと基準が固定できる。

作業量で見積もったものでどうやって中期的な計画を説明すりゃいいのさ？

バックログの工程の量による数値が得られました。

そこで、ベロシティを使用します。
直近までの数スプリントから、チームが１スプリントで消化できるポイント数をベロシティとします。

これにより、将来の数スプリントで消化できるポイントを予測できるので、
バックログの優先度が高いものから作業を行った場合にどのバックログまで辿りつけそうかという見立てがたちます。

ただあくまでも、アジャイル開発においては変更しうる計画というのは悪しからず。

最初はベロシティなんてないよ！

最初は決め打ちです！
基準としたバックログについてチームで平均してどれくらい時間がかかりそうかメンバーで話してみましょう。
そうすると、２ポイント（基準としたバックログの見積もり）に対してかかる時間がわかるので、
スプリントでの稼働時間に直せばざっくりとしたチームのベロシティが割り出せます。

大切なことは正確に見積もることではなく、都度見直すことです。
１週目の最終日時点での消化ポイントを二倍したものによっても見積もれます。
こういったことを繰り返し、チームとして安定して出せるベロシティを計測することができるようになります。

あとがき

筆者はアジャイル開発のプロでもなんでもありません。
自分の整理兼・備忘録用に書きました。（なので対象とする人は自分のことです...）

また、人、チーム、企業、状況によって取りうるルールは常に変わると思いますので、
こういった疑問もあるよ！　とか　こういうケースではこうやってる！
などのコメントお待ちしております。

参考資料