スプリントで終わらなかったストーリーのポイントはベロシティに入れるべきか？

ユーザーストーリーを活用しているチームは多い。

ユーザーストーリーの形式はシンプルに「背景」と「実現したい状態」を表現していて非常に認識齟齬を減らしてくれる良いツールです。

逆に、「やる事」だけが書かれているようなユーザーストーリーは注意が必要です。

（往々にして何故やるのかわからないからやった内容に後からイチャモンが付く。）

で、ユーザーストーリーに対して見積もりとしてストーリーポイントを付与するチームも多い。

相対見積もりによって効率よくプロダクトバックログ全体のボリュームを見通すのにちょうどいい。

また、バックログを消化するスピード（ベロシティ）にもちょうど良い指標にされている。

ところで、「スプリントで終わらなかったストーリーは、終わった分だけ割合でベロシティに計上していいですか？」って聞かれることがよくある。かなりある。

結論から言うと、計上しなくていい。ということを勧めている。

① 理由として、計上すると、終わらなかったことに対する責任をチームが持てなくなる。

終わらなかったけどベロシティとしてチームの成果に見えてるぞ、と。

となると計画に積んだのに終わらなかったことを振り返る気にもならない。

結果、ふりかえりで改善のフォーカスが当たらず、チームのパフォーマンスは上がらない。

② さらに、積まなくてもどうせベロシティ計算するときに薄まるから気にしなくていい、ということもつたえる。

3スプリントでベロシティ見積もるとして、それぞれ未完了があったとしたら、次のスプリントで完了したときに、次スプリントで計上されるから。

もちろん次スプリントでも（考えたくないが）未完了は発生するが、3スプリント間で相殺するので、影響は 1/3 になる。

そこまでいったら経験上ベロシティとしては誤差だから気にしなくていい。

③ いちいち気にするだけ時間の無駄だ。

ってあたりをチームに話してみて、計上したい？って聞くといい。

仕事をしたのにベロシティという目に見える形に影響出来ないのは辛いが、ベロシティは成果を評価するためのツールではないので気にしない方がいい。

チームには、終わらなかったことから何を学んだか？んじゃ次はどうしたいか？を考える方に情熱を使ってもらおう。

ちなみに、仕掛かりのままの仕事が多いと、とても生産性が落ちる。

たくさんの仕事をスプリントに積んで食い散らかすより、食べ残しが無いようにしてみると、意外とベロシティは上がる。

（色々着手しないことでサイクルタイムを減らす圧力がかけやすいから当たり前だけど）

始めることをやめて、終わらせることを始める

っていうカンバンの原則を活用すると良いかも。

海と山が好き