ストーリーポイントを工数ベースで考えてはいけない理由

Last updated at 2023-12-19Posted at 2023-12-19

はじめに

本記事はUzabase Advent Calendar 2023の20日目の記事です

株式会社Uzabaseに入社して1か月半が経ちました@maaaashiです

Uzabaseでは、アジャイル開発を採用しています

前職でもアジャイル開発をしていましたが、Uzabaseに入社してから理解が深まったことの一つにストーリーポイントについての考え方があります。

本記事ではその気付き・学びについての共有をしたいと思います

ユーザーストーリーはソフトウェア開発に用いられる手法です。「誰が、何の目的で、何を実現したいか」を示し、内部メンバーなどに向けて、ソフトウェアの機能や利点を伝えることが目的です。

例：こういうやつです

ストーリーポイントとは、タスクの難易度・規模・複雑性を表した指標です。
ストーリーポイントを利用することで、チームの成長を測ったり、タスクの優先順位を考えたりすることができます。

陸上に例えつつ進めてみようと思います
（分かりやすくなっているかはわかりません。）

試しに時間ベースでストーリーポイントを見積もってみましょう

例１）
1時間走ったら10kmくらい走れるので、10km走ったら1ptとします。

しばらく経ち、徐々に体力がついてきて、1時間で15km走れるようになったので、
途中で15km走ったら1ptに変更しました。

この後も1時間で走れる量を1ptとし、距離の変化は許容していきました。

ベロシティ計測してみたところ、毎週5pt消化で、変化のない結果になりました。

徐々に体力がついてきて、1ptをこなすスピードが上がったのにも関わらず、ベロシティは一定となっています。この計測結果は有用なデータといえるでしょうか？

ベロシティとは、チームがこなしたストーリーポイント数であり、開発スピードを表す指標なので、開発スピードが上がったのであれば、ベロシティはどんどん上がっていくはずです。

次に難易度・規模・複雑性を基準にして考えてみます

例２）
ひとまず、10kmで1ptとしました。
今後これを一つの指標として相対的にポイントを考えていきます
（例えば雨の日は10km走る難易度が上がるので、2ptとしたりします。）

徐々に体力が着いてきて、1日に走れる距離が15kmに増えました。
今まで１日で10km ⇒ 1ptでしたが、1日で15km ⇒ 1.5ptになりました。

ベロシティを計測してみたところ、体力がある週はポイント消化が多く、体調がすぐれない日はポイント消化が少なかったことがわかりました。

規模や、難易度というものは普遍的なものです。
それに比べて、工数というものはチーム成長や、プロジェクト管理方法によって変化するものです。

変化する工数をベースにしてしまうと、普遍的なデータとしてベロシティが計測できなくなってしまうでしょう。

チームメンバー間でのスキルの差も、ストーリーポイントを工数ベースで考えるべきではない理由の一つです。

たとえば、経験豊富な開発者は特定のタスクを短時間で完了できるかもしれませんが、新しいメンバーにはもっと時間がかかることがあります。同じストーリーであるのにもかかわらず、見積りを行う人のスキルによって結果が変わるのはプロジェクト管理に支障をきたす可能性があります。

また、時間ベースでストーリーポイントを割り当てると、チーム内での作業負荷の差異が生まれ、プロジェクトの進行に影響を与える可能性があります。

ストーリーポイントは、タスクの難易度や複雑性を表すものであり、個々のメンバーの作業速度を基準にすべきではありません。

ストーリーポイントを工数ベースで考えると、ベロシティの計測が不正確になるだけでなく、スキルや、時間感覚の差による見積りの不正確さをも引き起こすことがあります。

アジャイル開発では、ストーリーポイントをタスクの難易度、規模、複雑性を反映する指標として用いることが重要です。

これにより、チーム全体としての進捗をより適切に把握し、プロジェクトの成功に向けて効果的に進めることができるでしょう！