ユーザーストーリーのポイントは２つ作った方がいいのではないかという私見

スクラムおじさん

まず前提としているケースについて

チームの平均ベロシティ（キャパシティ）が１５ポイントで、４つのユーザーストーリーやタスクのチケットをスプリントに入れた。
ポイントは５、５、３、２。合計１５ポイントで終わるはずだった。
ところがスプリントを終えてみたら５ポイントのチケット１つが終わらなかった。
残りの５、３、２ポイントのチケットが終わっていた。
（なお次のスプリントプランニングで未了の５ポイントのチケットを再見積したら残２ポイントだった）

このとき未了チケットの残ポイントはどうなる？

さて問題
・今回のスプリントのベロシティはいくつか
・次スプリントにおいて今回未了だったチケットのポイントはいくつか
これを少し考えて欲しい。

それでは解答編。スクラムにおいては
・今回のスプリントのベロシティは１０ポイントになる。
これは当然、DONEしたチケットは３つだけ。５＋３＋２で１０ポイント
・次スプリントにおいて今回未了だったチケットのポイントはいくつか
残作業を再見積して２ポイントになったんだからポイントは当然２ポイントになる。JIRAチケットのポイント欄の５の部分を消して２ポイントに上書きする

再見積したら残が２ポイントだった、だから該当チケットのポイントを２ポイントにして次のバックログに入れる。
ここが今回の話の肝になる。

なぜこのやり方をする必要があるか

スクラムに詳しい人には退屈だろうけど聞いて欲しい。
なぜこのやり方をとるかというと、スプリントにおいてプランニングでスプリントバックログに入れた内容は必ず終えて欲しい、コミットして欲しい内容だから。
スクラムでは長期予定では納期やマイルストーンのコミットはするべきではないとされている。でないと
・品質、コスト、納期、開発範囲のバランスが崩れるし、
・フィードバックと適応のサイクルが崩れる
のでスクラムとしての本質が保てなくなる。

スプリントプランニングで今スプリントは全１５ポイント消化を目指しますと言ったら、レトロスペクティブで評価すべきなのは１５ポイントを「全て消化したか」「できなかったか」だ。
もし消化できたらなぜ消化できたかを振り返るべきだし、
もし未消化の残があるならなぜ消化できなかったかを徹底的に振り返らないといけない。
常識以前の話なんだけど、スクラムにはDone or Notの２つのステータスしかない。「進捗率80%」とかいうふざけたステータスは存在しない

レトロスペクティブで「スプリントプランニングでコミットした作業量」に対して「Doneできたか否か」にメンバーの意識を集中させたい。
Doneに成功したら盛大な拍手で祝うべきだし、Doneできなかったら深刻な顔をしてレトロスペクティブでメンバーには真剣に反省して欲しい。
DONE成功＝勝利、DONE失敗＝敗北
それくらいの刷り込みをすると、チームはDONEさせるために真剣に作業してくれる。
だからスプリントのキャパシティとコミットする作業範囲は比較的厳密に見積もりたい。

一番大事なのは、チームのキャパシティが１５ポイントで、スプリントプランニングで１５ポイント分の作業量を消化すると宣言しているなら
チームはスプリントで１５ポイントを消化しないといけない。
全て消化したら勝利だし、消化できなければ敗北、そういう意識をチームに刻むことで、プランニングの精度とスプリントのコミットを強く意識させ他方がいいと私は考えている。

ところが問題が発生する

新規で追加された大きなエピックを見積もったらアバウト９０ポイントだった。
このエピックは着手開始してからどの程度の期間で終わるのか？
これを比較的高い精度で予測したい。
チームキャパシティが１５ポイントだから９０ ÷ １５ = ６週間？
バッファ２０％のせて７週間という見積をしてもいいんだけど時としてこのキャパシティというやつはいい加減になりがちになる。
そもそもスクラムなので実績から未来を予測したい。

実績から未来を予想する方法（簡易版）

前回のエピックが事前予想約６４ポイントで５週間、その前のエピックが事前予想約１１０ポイントで１３週間
となると過去の事前予想ポイントと実績から、今回の９０ポイントのエピックは７〜９週間で収まるかなという予想を立てることができる。

実績から未来を予想する方法（高精度版）

上の方法でいまいち説得力がないと言われた時のやりかた。上記の雑な予想に、Redshiftのデータベースで修正を加えたものを予想として出す。
弊社ではJIRAチケットのデータをRedshiftに連係しているのでRedshiftに以下の条件を突っ込むと９０ポイントのエピック消化に必要な期間が出てくる。
エピックに紐づくタスクで＋バグではなく＋突発作業フラグがない
消化したチケットのポイントの合計を８週間〜１０週間分出すと、チームが過去の進捗できるポイントの実績を出せる。
まあここで８週間で７８ポイント、９週間で８５ポイント、１０週間で９６ポイントだったとしよう。
だいたいこれで８〜１０週間で９０ポイントのエピックが完了しそうな気がしてくると思う。

大体この方法を使うと、チームはスプリントあたりのキャパシティが１５ポイントといいつつ、エピックに対しては１０ポイント前後しかリソースを割けていないことがわかったりする。

ここで現れる問題

一番最初に話した、５ポイントのチケットが終わらなかった。再見積したら残作業量は２ポイントだったのでJIRAチケットのポイント欄を２ポイントにした。という件。
あれのせいでトータル５ポイントの作業量だったチケットが２ポイント扱いになってしまう。
なので私としてはJIRAにはtotal_pointとかそういう名前のカラムを新たにユーザー定義して、そこに全体作業量（今回だと５ポイント）を入力しておくといいのでは？と思っている
すると長期間のエピックの見積精度も上がるんじゃないかな、知らんけど。と思う。
特にキャパシティに対して平均的なユーザーストーリーのサイズが多い、あるいはスプリント期間が１週間と短い場合、このプラクティスは有効になると私は考えている。

書きたかったけど収まらなかった余談

JIRAはスプリントバックログに入れたチケットに関して全て「スプリント中にBurnするとコミットしたもの」扱いしてくるけれど
たとえばベロシティが１５ポイントで、終わる見込みの３チケット入れたら１１ポイント
次に優先度が高いのが８ポイントのチケットだとする。この８ポイントのチケットは「終わることにコミットするつもりはないが総合的判断からスプリントに入ったチケット」という扱いにしたい。
この時点のIntentとしてスプリントでバーンダウンできる範囲としてコミットできるのは１１ポイント分だけ、８ポイント分はExtraな扱いにしたい。
ところがJIRAは「スプリントでバーンダウンすべきポイントは１９ポイントだよ」という。
これが非常に厄介だ