はじめに
みなさんは、スクラムでストーリーポイントを付けるときどのような基準でつけているでしょうか?
ストーリーポイントの基準は時間にすべきではないと言われています。
しかしながら、 スクラムを初めて導入して今まで時間対の工数見積もりに慣れていたチームや請負型の社外パートナーが入ったプロジェクトなど、現実的には時間を基準にしてストーリーポイントを運用しているプロジェクトも多いでしょう。
また、ストーリーポイントの見積もりを付け始める際の最初の基準として「4時間 = 1ストーリーポイント として考えよう！」というように知らず知らずのうちにそのような運用になっているケースもあると思います。
私は経験から、ストーリーポイントの基準を時間にするのは、プロジェクト管理に大きい悪影響をもたらすアンチパターンであり、すべきではないと結論づけています。
私が経験してきたプロジェクトで、ストーリーポイントの基準を時間にして運用したときに実際にどのような悪影響が生まれるかを紹介します。
ただし、あくまで私の経験に紐付くケースであることにご注意ください。
補足：ストーリーとストーリーポイントとは
ストーリーとは、スクラムで管理されているプロジェクトの持つタスクの呼び方です。スクラムでは、ストーリーとタスクは明確に区別されますが、この記事を読むときはストーリー = タスクと読み替えても差し支えないです。
ストーリーポイントとは、スクラムのスプリントプランニングなどでストーリーの規模感を知るために付ける相対評価の数値です。
一般的には、ストーリーポイントは相対評価にするためにフィボナッチ数列 1,2,3,5,8,13 に沿って付ける、スクラムチーム全員で相見積もりを行いながら決定するためにプランニングポーカーを用いて付けるなどのスクラムでおすすめされている手法と一緒に運用されていることが多いです。
ついストーリーポイントの基準を時間にしたがるチーム
この記事で想定している(私が経験してきたケースの)スクラムの注意しなければいけない特性は、PMが不在のために(またはPMが存在しても何らかの事情で)開発者が直接ステークホルダーと交渉してストーリーの受け入れ条件(納期)を調節しなければいけないことです。
ほとんどのプロジェクトでは、タスクの受け入れ条件や納期はPMがステークホルダーと交渉して決定し、責任を持つでしょう。しかし、リソースが少ないとてもスモールなチームや社外パートナーが請負型でスクラムの一員として入っていて、常に社外パートナーの費用を気にしているチームなどでは、開発者が直接ステークホルダーと「このタスクは○○までに完了する予定です。」「このタスクは○○までに完了させましょう。そのためにスコープをこの範囲にしましょう」などと交渉しなければいけない場面も多くあると思います。
このようなプロジェクトでは、ストーリーポイントと工数見積もりを混同して扱いたいがために、ストーリーポイントの基準を時間にする誘惑が働きます。
とくにプロジェクト管理において、頻繁にタスクの工数見積もりをステークホルダーから要求されます。
プロジェクト管理はスクラムで行われているため、ストーリーポイントを付ける時に一緒に工数見積もりをストーリーポイントとして行いたくなってしまいます。
「このストーリーは8ポイントなので、だいたい2週間かかります！」
このような言葉がかわされるようになるでしょう。
ストーリーポイントが工数見積もりとして扱われていく
スクラムでストーリーポイントの基準を時間にする運用は悪魔の誘いです。
この運用を実施しているチームは、最初は気をつけていてもだんだんとストーリーポイントを正式な工数見積もりとして扱いだすようになります。
もともと工数見積もりに対しては曖昧な基準しか持たないストーリーポイントが工数見積もりとして誤用されていくとスクラムチームはとてもツラい状況に陥っていきます。
ストーリーポイントが工数見積もりとして誤用される例
実際にストーリーポイントと工数見積もりの進み方を図示しながら説明します。
① ストーリーポイントを割り当てるときに規模が曖昧に見積もられる
開発者や開発チームはスクラムの中でスプリントプランニングの前にストーリーポイントをストーリーに割り当てます。
個別の開発者が割り当てるのではなくてリファインメントなどのMTGのタイミングで行われることも多いでしょう。
このとき、ストーリーポイントの他ストーリーと比較して規模が大きいか小さいかを比較するという特性に集中して、ストーリーポイントの基準となっている時間が正確な見積もりになっているかはさほど気にされずに付けられます。
② ストーリーにとりかかるときにストーリーポイントは工数見積もりになる
次に、スプリントプランニングでPO(プロダクトオーナー)などのステークホルダーと話しつつ、開発チームはスプリントでとりかかるストーリーを精査します。
ステークホルダーは基本的にストーリーがどれくらいの期間で完了するかをストーリーポイントを参考にしつつ比較します
このとき、時間が基準になっているためにステークホルダーはストーリーポイントをストーリーが完了する見込み期間であると捉えます。
しかしながら、実際にはストーリーポイントにはストーリー規模の大小を測る前提で付けられているためにストーリーポイントをストーリーが完了する見込み期間の見積もりと実際にかかる工数には大きなズレが生まれます。
③ 正確な見積もりが出てきたころには既に遅い
タスクを進めてしばらくした頃に開発者が「ストーリーが後どれくらいで完了しそうか」という見積もりを精度高く見積もれた時には、ステークホルダーは別のステークホルダーとの調整をスプリントプランニングで確認したストーリーポイントを参考に進めています。
開発者や開発チームは知らない間に決まっていた受け入れ条件に対してストーリーを完了させなければいけなくなってしまいました。
悲惨なのは、ストーリーを担当していた開発者や開発チームに対して、このケースのような曖昧に付けたつもりのストーリーポイントが工数見積もりとして扱われることで、開発者はステークホルダーに「正確な工数見積もりをしなかった」とみられて信用を失ってしまいます。
なにがそうさせてしまうのか
一例ではありますが、ストーリーポイントの基準を時間にして運用するとこのようにストーリーポイントを工数見積もりとして濫用される危険性があります。
スクラムチームにいる開発者たちは、ストーリーポイントを付ける中で自分たちが自然と曖昧なまま工数見積もりをしていることに気づきにくく、
PMやステークホルダーなどはプロジェクトが進む中で「いつストーリーが完了するか」の答えを求めているので、最初に提示されたストーリーポイントを使い勝手良く工数として解釈してしまいます。
また、ストーリーポイントを付ける作業に対して充分な見積もりの時間がとられにくい運用になりがちです。
ストーリーポイントの基準を時間としてしまったがためにこのような結果になってしまいました。
どうするべきか
ではどうしたら良いのでしょうか?
工数見積もりとストーリーポイントはまったく別々に運用されるべきです。
別の概念である以上同じ数値に別々の意味を持たせようとすると必ず濫用が始まります。
一度、ストーリーポイントが誤解されて運用すると、その認識を修正するのもとても大変なので最初から工数見積もりとストーリーポイントが混同されないように必ず分けて行うことをオススメします。