実務を通して気づいたストーリーポイント活用のメリット

はじめに

この記事はツクリンクアドベントカレンダー2024の15日目の記事です🔥

こんにちは。
ツクリンク株式会社でエンジニアやっとります、ikarikomanです。

私が所属する開発チームではスクラムフレームワークを使用したアジャイル開発を行なっています。
その中で、開発の見積もりにストーリーポイントを使用しているのですが、この記事ではストーリーポイントを運用している中で感じたメリットや気づいた課題についてお話しします。

ストーリーポイントについて

スクラム開発でストーリーポイントを使用することは、手法として一般化されていると思いますが、そもそもスクラムガイドにはストーリーポイント、ストーリーという言葉自体出てきていません。
（2010年の初版ではユーザーストーリーという言葉は登場していたようです）

ストーリーポイントの起源としては、アジャイル開発における手法の一つである、「エクストリーム・プログラミング（XP）」において、ストーリーの純粋な実装以外の様々な要因を取り除いた、理想的な日数である「Ideal Days」という概念からスタートしたようです。
「Ideal Days」については、純粋な実装時間以外を考慮していなかったため、実際にストーリーがデリバリーされるまでに「Ideal Days」で見積もりをした以上の日数がかかっており、ステークホルダーの混乱を招いていたため、「Ideal Days」を日数ではなく、「ポイント」と呼称するように変更されました。

参考：https://ronjeffries.com/articles/019-01ff/story-points/Index.html

ストーリーポイントは、時間や日などの絶対的なものではなく、プロダクトバックログアイテム（以下PBI）間の相対的な複雑さや規模を表します。
ポイントの値についてはフィボナッチ数列（1,2,3,5,8,13など）を用い、プランニングポーカーを使用して見積もりを行うことが一般的です。

運用中に感じたメリット

ストーリーポイントのメリットについては様々なところで語られていますが、実際に運用している中で自分が感じているメリットは下記です。

相対的な見積もりができる

絶対的な時間（時間や日など）で見積もるのではなく、相対的なPBIの複雑性や、作業量、規模によって見積もるため、個人のスキルや経験の差による見積もりのばらつきを抑え、より客観的な見積もりが可能になっています。

タスクの共通理解を深めることができる

プランニングポーカーを用いて見積もりを行うことで、PBIに対するそれぞれの認識をできるようになっています。

ポイントが全員一致しなかった場合は、各自がポイントをつけた理由を発表するため、「他のメンバーが想定しているよりも実は技術的に難しい実装だった」、「実は既存実装を流用できるため、想定より軽い対応で済んだ」など、PBIの難易度や方針に関する認識のズレを解消できます。

また、PBIのゴールに関してもメンバー間で認識が異なる場合があるため、そのような場合もプランニングポーカーがあることで、ディスカッションする機会が生まれ、その都度認識をメンバー全員で合わせることができているのはとても良いことだと思います。

ポイントを使うことで、タスクを適切に細分化できる

チーム内の取り組みとして、PBIの粒度を細かく保つことで、実装やレビューの負担を軽減させるようにしています。
ポイントをつけて見積もりをすることで、細分化する際の基準としてポイントが機能しています。

今後の開発計画が立てやすくなる

ストーリーポイントは時間や日などではないため、正確なリリース時期を伝えるのには適していないのですが、1スプリントあたりにこなせるストーリーポイント（ベロシティ）を用いて、ざっくりしたリリース時期を伝えるのに役に立っています。

ただ、アジャイルで開発する上では変化が多く起こるので、一度伝えてそのままにしておくのではなく、できる限り頻繁にお伝えするのが大事かと思います（自チームではスプリントごとに伝えてます）

運用中に感じた課題

ストーリーポイント自体の課題ではないですが、運用上で気づいた課題があります。
チームでは、ユーザーストーリーをさらに細分化した作業用のタスクをPBIとして扱っているため、ストーリー以外のタスクにもポイントを振っています。

ストーリー以外のPBIにポイントを振っているため、ベロシティを考慮した見積もりを行なうと、スプリントごとにストーリーを完了することができないケースが発生しました。

そのため、スプリントゴールの定義が難しくなり、「~という作業を完了させること」といった、ユーザーへの価値提供とは直結しないゴール設定になりがちで、スプリントゴールの役割が曖昧になっていることがあります。

対策としてはタスクごとではなく、ストーリー単位でPBIを作成しポイントを振ることや、スプリントゴールの定義をチーム内で見直すなど、スクラムの運用自体を改善していく必要があると感じています。

さいごに

ストーリーポイントやベロシティはアジャイル開発における一般的な見積もり手法であり、導入することでPBIの共通認識を深めたり、細分化に役立ったりと、多くのメリットを感じました。

ですが、ストーリーポイントはあくまで見積もりの手法の一つなので、導入すればOK！というわけではありません。チームの状況や方針と合わなくなってくることも当然起こると思います。
そのような時にも柔軟に対応できるように、日頃からチームでの振り返りや他の見積もり手法の検討などをチームで重ね、より良いアジャイルのプロセスを作っていきたいと思います。