ストーリーポイントで開発実績を測っていいのか
Scrum によるアジャイル開発を行っていると、チームごとでストーリーポイント使って見積もりを立てて Velocity を計測、ということをやるわけですが。
そこに、開発全体のアウトプットを定量化したいから、各チームのストーリーポイントのスケールが何倍違うのか知りたい、できればチーム間で同じ基準にしてほしい、という欲求が降ってくる。
しかし、見積もりのためのストーリーポイントによって成果を測ること、また、チームごとの指標であるストーリーポイントをチーム間の比較することのについては、誤りであることがいくつかの記事で指摘されている。
直感的にも、見積もりのための指標が成果・実績を測るものになるのは違和感があるし、そのための指標として計測すること自体が見積もりとしてのストーリーポイントを歪めてしまう危険は想像できる。
そもそも、ストーリーポイントは単位を持たず、 Velocity とセットでなければ意味を持たないはずであり、単純に時間に換算できるものでもない。ただ、実際は、1ポイント≒1日のような、理想日による認識で捉えて議論してしまっている場合がある。アウトプット計測のために用いるという発想も、そのような認識から出てくるものではないかと思う。
では、開発のアウトプット量、言い換えると生産性は、どうやって計測すればいいのか。 おそらく、以下の記事にあるような、 TOC に基づくプロセス全体の価値計測がヒントになるのではないか。
リーンソフトウェア開発でいうバリューストリーム、 DevOps 的な、開発・QA・運用までトータルなプロセスで捉えた、顧客に製品価値を届けるまでの全体を対象とした指標でなければ、部分最適に陥りかねない。
