スプリントプランニングを少し変えたらいいことがたくさんあった

はじめに

こんにちは。ReviCoのスクラムチームでスクラムマスターをやってるりっちゃんです。
認定スクラムマスターを取得してもう少しで1年経ちます。
自分が所属するスクラムチームへ良い影響を与えられているかどうかはまだわかりませんが...。きっと何かしらあるはず...と思い出したのがスプリントプランニング（以下、プランニング）です。
プランニング方法を昨日の天気を利用した方法に変えたことでよいことがたくさんあったので紹介できればと思っています。
※昨日の天気については後ほど説明します

所属しているスクラムチームの情報

メンバー：プロダクトオーナー、開発チーム（4人）、スクラムマスターの6人チーム
スプリント：月曜日始まりで金曜日終わりの1週間スプリント

変更前のプランニング

プランニング1部でスプリント内で開発メンバーが稼働できる総時間を算出（ここでは便宜上100時間と）します。 ※1人25時間
プランニング2部でReadyなプロダクトバックログアイテム（以下、PBI）をプロダクトバックログからスプリントバックログへ移して各PBIを作業タスクに分解していきます。
それぞれのタスクに対して作業に必要な作業時間を割り振り、合計時間が100時間になったところで終了です。 ↓できたスプリントバックログがこちら（ツールはAzure DevOpsを利用しています）
※すでに100時間を超えた計画になっている...

プランニングの課題

プランニングで稼働時間を見積もっていたときは、以下のような課題が発生していました。

• プランニングがタイムボックス内で終わらない
• タスクが何時間で終わるかわからない
• 実施する人によって作業時間が変わる
• 実作業時間を入力するのを忘れがち、もしくは入力するのが手間
• タスクに割り振られた時間と実作業時間の差分が大きい、これによってストレスを感じるメンバーもいる

課題解決への糸口

当時の私は↑のプランニングを課題だとは思っていましたがどうやって解決するかわからない状態でした。 そんな中、認定スクラムマスターの研修で 「プランニングでは時間を使わないでベロシティを使った方がいいよ（ビシッ！）」 と教えてもらい衝撃を受けました。 うぉぉぉぉー、今めっちゃ使ってるー！！！！！！

現状は教えてもらった内容をちょっとだけアレンジした状態で活用しています。

スクラムチームへは恋文を書いてプランニングのやり方を変えたい想いを届けました。

作業時間の見積もりから昨日の天気を使った見積もりへ

プランニング1部として1スプリントでDoneにできそうなベロシティ（計画ベロシティ）の算出方法をSprint5を例にして紹介していきます。
図にするとこんな感じになります。早くエクセルから脱却したい...

それでは、プランニングにでてくる用語を説明していきたいと思います。

（注）残業が多すぎると正確な数値が計測できないので、残業はしないようにチームで協力しましょう

• 実際のベロシティ：1スプリントでDoneになったPBIに設定されているストーリーポイントの合計pt
  この数値が大切になってくるので計測を始めてない場合は測ってみてください。3スプリント分必要になります。
  例）DoneになったPBIのストーリーポイントがそれぞれ3,5,2,6,4,3,3,1,3,5だった場合、実際のベロシティは35ptです。

• 稼働時間：開発チームが価値提供にあてられる合計時間
  例）会社関係の打ち合わせが16時間ある場合、1人あたりの稼働時間は24時間になりますので合計は96時間です。
  ※1人40時間、4人で計算しました。残業は考慮に入れません

図の更新方法としてはスプリント開始時にSprint4の「実際のベロシティ(pt)」（図だと①）とSprint5の「稼働時間(h)」（図だと②）を入力します。
これから説明する項目は計算式を設定できるので入力は不要になります。
したがって計画ベロシティを算出するにはそこまで時間はかかりません。
ちなみに私が所属しているチームではここまで15分くらいで終わります。

• キャパシティ：業務時間のうち稼働時間が占める割合%
  例）稼働時間が96時間の場合、業務時間が160時間なのでキャパシティは60%（96*100/160）になります。

• 補正されたベロシティ：全業務時間を価値提供にあてたと仮定した場合のベロシティ
  なぜこんなことをするかというと、スプリントによってキャパシティが違うので条件を揃えるためです。
  例）実際のベロシティが35ptでキャパシティが60%の場合、補正されたベロシティは58pt（35*100/60）です。
  キャパシティ60%でベロシティ35ptだから、キャパシティ100%だったらベロシティ58ptはできたね！という意味です。 この説明がとても難しい、うまく伝えられてないと思います。ごめんなさい。

• 昨日の天気：補正されたベロシティの平均（過去3スプリント分）
  今スプリントの計画ベロシティを出すために必要となる値です。
  過去の実績から今スプリントの値を正確に算出することはできないし、やろうとするととても時間がかかるので「過去3スプリントの平均を取れば7～8割くらいあってるでしょ」という考え方です。
  例）過去3スプリントの補正されたベロシティがそれぞれ60pt, 50pt, 58ptの場合、昨日の天気は56pt（(60+50+58)/3）です。
  ※昨日の天気という言葉はちゃんとしたスクラム用語なので、照れずに使いましょう！ 　私は使うのがとても恥ずかしかった

• 計画ベロシティ：今スプリントで実施できるストーリーポイントの合計pt
  昨日の天気とキャパシティから今スプリントで実施できるであろうベロシティを出します。
  今スプリントのPBIを選ぶときに計画ベロシティの値を超えないようにします。
  例）昨日の天気が56ptでキャパシティが80%の場合、計画ベロシティは44pt（56*80/100）です。

スプリントバックログを作ってみよう！

ここまできたらあと少し！
先ほど出した計画ベロシティを超えないようにプロダクトバックログからスプリントバックログへPBIを移動しましょう！

余談ですが、優先度が高いPBIから順に移動していき計画ベロシティを超えるか超えないかくらいでやめておきましょう。 多めに入れてもできる可能性は低いので欲を出しても良いことはありません。 逆にスプリント内でスプリントバックログ内のPBIが足りなくなったら追加していく方がメンバーにとっても良いことがたくさんあります！
もし、プロダクトバックログのPBIが優先度順に並んでない場合は事前に並び順を変えておきましょう。 （多少の並び替えは問題ないと思いますが、）プランニング内で並び替えをするのは時間が足りなくなる原因の1つです。
POは忙しいことが多いので、チーム全員でどうすればよいかレトロで考えるのが良いかと思います。

余談が長くなってしまいましたが、
スプリントバックログに今スプリントで実施するPBIが揃ったので、次はPBIをタスクに分けていきましょう。
タスクは1日で終わるくらいの粒度に分けるのが良いと言われていますが、まずは開発チームがやりやすいように分けていくでいいと思います。
課題が出てきたら改善していけばいいので。

以上でプランニングは終了になります。
出来上がったスプリントバックログの一部はこちら

他にやることとしては、スプリントゴールを決めたり、メンバーごとの初動（初めにとりかかるタスクのみ）を決めたりです。
導入したての時は時間が掛かっていましたが、今は慣れてしまったので負担に感じることはほとんどありません。

プランニングを変えてよかったこと

• スプリントプランニングがタイムボックス内で終わるようになった
  時間に余裕をもてるようになったため、時間が無くなって「もう、これくらいでよくね？」という会話はなくなりました。
  実作業時間を入力することもなくなったため、価値提供や自分の成長に使える時間が少し増えました。

• タスクごとに設定した時間内に終わらないとストレスを感じるメンバーが解放された まじめな方は決められた時間内にタスクを完了させないとストレスを感じてしまうことがあります。 タスクごとに時間を割り振っていないので、時間を気にせずに取り掛かることができるようになりました。 時間から解放されたことで効率もよくなったはず。

まとめ

以前はスプリントプランニングを実施するだけで疲れ果てていました。 スプリント開始から疲れて果てていては良い価値提供はできなくなってしまいます。 スプリントの計画を立てるスクラムイベントだからこそ、ストレスなくスタートダッシュができるようにした方がパフォーマンスもでると思います。
スクラムチームによっては合う合わないがありますので必ずしも良い結果に繋がるとは限りませんが、課題を解決するために一度試してみるのはいかがでしょうか。

最後に、何回かこのプランニング方法を実施後、スクラムチームへ元のプランニング方法に戻したいかとアンケートを取ったところ全員がこの方法が良いと回答してくれました。 良い提案ができたみたいでよかったです。

最後まで読んでいただきありがとうございました。
少しでもスクラムの課題解決につながれば幸いです。

一緒にスクラムを盛り上げてくれる人を募集しています！
careers.ecbeing.tech