ストーリ―ポイントの導入経緯
私のプロジェクトでは、ある程度の期間の工数を見積もり、毎週の進捗レビューで予実の確認を行っていました。
しかし見積もりと実工数の差が大きいことが問題になり改善するためにストーリポイントを導入してみることにしました。
ストーリポイントとは
1つのタスクに対して工数ではなく、ポイントで見積もりを行います。
- 初めに過去に行ったいくつかのタスクに対し、ポイントを割り当てる。ポイントはタスクの難易度を表します（ポイントが高いほど難しい）
- 次に1週間分のタスクに対し、1で決めたタスクから相対的な難易度のポイントを割り当てる。
- チームでポイントに合意する。
- メンバーにタスクを割り当てる。
- 次週に各メンバーのポイント消化率を見て、今後のメンバーごとに割り当てるポイントの合計量を調整します。
以上の5ステップの2~5を繰り返します。1はポイントの基準となるため基本的には変更しません。
これを繰り返し行うと、チームが1週間に消化できるポイント合計が定まってきます。
ポイントのルール
実はタスクに割り当てるポイントは1,2,3,5,8,13,21…というフィボナッチ係数と呼ばれる、係数しか使えません。
これは、難易度が高いタスクほど見積もりに誤差が出やすくなる傾向があるため、ポイントも増えるほどおおざっぱにします。たとえば、ポイントは8より多いけど13ほどでもないなと思うタスクには13を割り当てるようにします。
導入のメリット
実績ベースの見積もりでスケジューリングしやすくなった
新しいタスクが来ても、過去の実績がポイントの根拠になるため、ポイントを振りやすくなります。
1週間でチームが消化できるポイントもわかってくるので、今後のスケジュールも立てることができます。
メンバーの作業スピードがわかる
メンバーごとに1週間の消化ポイント率がわかるため、評価がしやすい。
消化率の変動が成長の指標にもなります。
ストーリーポイントの難点
メンバーの専門性によってポイントの認識がずれやすい
あくまでも初めに決めたタスクとの相対評価ですが、タスクに対して有識者と全くの無知のメンバーとでは、ポイントの認識がずれることがあります。
1つのチームに専門の違うメンバーが複数存在してしまう場合に、こういった問題が起こりやすいと思います。
そのため、チームを専門ごとにグループ化し、その中でストーリポイントの定義を分けるのが良いかもしれません。
長期の工数見積もりには向いていない
ポイントは過去の実績をベースに精度があがっていくため、事前に全行程のポイントを算出することは無意味です。
毎週ポイントの評価を改めるフローが必要で、1週間のポイント消化率が決まってくるのは始めてから2,3か月後くらいだと思います。
まとめ
ストーリポイントはアジャイル開発とマッチした、実績に基づく論理的な見積もり手法です。
最近ではRedmineなど、マネジメントツール側もストーリポイントに対応していることが多いため、導入を検討してみてはいかがでしょうか。
