Edited at

スプリントプランニングうまくやってる?

More than 1 year has passed since last update.


背景

実際、スクラムをやると、理解は簡単だけど習得は困難と言われています。

たぶん、3スプリントぐらいやってやめちゃうプロジェクト多いのではないかと思います。

「だいたいわかった、もういい」。

「やってみて良かったよ。うちには合わないことがわかったから」

でも、スクラムは非常によく出来たフレームワークです。

うまくいかないのは、適切に運用できていないから。

ここでは私の、現場での学びと気付きを共有致します。


スクラムの19の要素


  • 透明性

  • 検査

  • 適応

  • プロダクトオーナー

  • チーム

  • スクラムマスター

  • スプリント

  • スプリントストップ

  • プロダクトバックログ

  • スプリントプランニング

  • スプリントバックログ

  • デイリースクラム

  • ポテンシャリリーシッパブルインクリメント

  • スプリントレビュー

  • スプリントレトロスペクティブ

  • プロダクトバックログリファインメント

  • インペディメントリスト

  • 受け入れ条件

  • 完了の定義

上記1つでも欠けたら、スクラムではないと言われています。


スクラムにおける価値基準

スクラムガイドが2016年版になり、新たに価値基準が追記されました。

https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf


  • 確約(commitment)

  • 勇気(courage)

  • 集中(focus)

  • 公開(openness)

  • 尊敬(respect)


スプリントプランニングの目的

スプリントプランニングは、以下の目的があります。


  • チーム全員で参加し、スプリントでやるべきものを全員が把握する。

  • 何を実現したいのか決める。(プロダクトバックログアイテムを選択する)

  • 目的を達成できるプランニングを確実に考え、スプリントバックログを作成する。

  • プロダクトオーナーとチームは、このスプリントでどのプロダクトバックログアイテムを選択し、それを実現するか、確約する。

「確約」とは、「確かな約束」のことです。英語では「コミットメント(Commitment)」になります。

コミットメント、日本人には聞き慣れない言葉かも知れません。

だが、コミットメントしたことは、余程のことがない限り、守らなければならないです。達成せねばならないです。

余程のこととは何でしょう。それはスクラムチームで議論し、ワーキングアグリーメント(チーム内の約束事)に載せておくべきです。

例えば


  • 忌引があった

  • 災害があった

  • 病気があった(チーム、またはその家族等)

  • インフラの障害があった(インフラとは何か?もハッキリさせておいたほうがいい)

などです。

割り込みが激しい部署であれば、割り込みに関してもルール化して載せておけば良いと思います。

これらの障害がなければ、スプリントプランニングの終了時に、プロダクトオーナーとチームは、本スプリントにおける、達成すべきゴールを「確約」(コミットメント)していることになります。

チームは、スプリントプランニングでコミットメントをしたら、そのスプリントで選択したスプリントバックログアイテムを実現する必要に迫られます。徹夜しようが、何をしようが、実現せねばならなりません。そこは注意して欲して頂きたいです。プロダクトオーナーから言わせると、情状酌量の余地は、ないです。

だからこそ、スプリントプランニングは重要です。

ここで誤解しないで頂きたいのが、必ずスプリントを達成するべきだと言ってはいません。

すべてのプロダクトバックログアイテムを確約は出来ません。たかだが1~4週間のスプリントでも、ほとんどのケースでリスクだと思います。それぐらい、現代のソフトウェア開発は複雑です。

だから、確約できないことを確約しておきます。

そんなこと言ったらスクラムを実践なんかできないです。

大切なのは、一歩を踏み出してみる勇気です。

やってみなくちゃ、わかりません。

チームは、バックログアイテムに関する全ての情報をプロダクトオーナーと共有しましょう。

これは透明性に繋がります。そして、プロダクトオーナーは、チームを尊敬し、信頼しましょう

この透明性の前提のもと、プロダクトバックログがUndone(未完了)だった場合は、それは仕方がないと思います。今のチームの実力であり、なぜUndoneだったのかをレトロスペクティブで振り返ります。次以降のスプリントのための学びになるはず。


スプリントプランニングのインプットとアウトプット

スプリントプランニングのインプットは以下の2つです。


  • プロダクトバックログアイテム

  • これまでのスプリントのベロシティ

  • チームのキャパシティ(スプリント中に使える時間)

スプリントプランニングの成果物は以下の2つです。


  • 選択されたプロダクトバックログアイテム

  • スプリントバックログ


スプリントプランニングの時間制限

厳密な時間制限はないが、習慣的に、4週間のスプリントで8時間以内。1日が5-6時間稼働だと考えると、1-2日かける。

1週間スプリントだと2-3時間。


良いスプリントプランニングの傾向


  • アジェンダと時間割を始めるときに決めている。丸1日かけるプランニングで、時間割も決めないでダラダラとなんとなく時間を過ごしてしまうと、プランニングが終わらなくなる。

  • プランニング時にコードを見て、細部まで見ている。

  • デジタル機器を操作しているのがチームで1名以内。

  • タスクの見積もり時間が2時間以上のタスクが存在しない。

  • 5-10分のタスクはプランニング時に終わらせている。

  • ホワイトボードやを活用して、チームの理解・共通認識を広げている。

  • APIやFrameworkの調査が必要とわかった場合は、プランニング時に多少調査するが、時間が足りないとすぐに判断された場合はプロダクトバックログとして積む。

  • チーム全員にプランニング中に暇な時間がない。(逆にある場合は問題がある)

  • チーム全員がまんべんなく発話している。特定の1人が喋りっぱなしということがない。

  • プロダクトオーナーが参加している。

  • プランニングの最後に、プロダクトオーナーとチームが選択したプロダクトバックログアイテムに関して、コミットメントする儀式がある。

  • お昼やすみを挟む場合は、チーム全員で昼食に行く。


まとめ

記載中・・・