1週間スプリントから始めよう

たびたび聞かれる質問として、「スプリント期間」が挙げられる。スクラムでは1ヶ月（4週間）以内のスプリントと定められている。世界で最もポピュラーなのは2週間スプリントだ。

スプリント期間はスクラムチームで相談して決めればいいが、スクラムを始めてする、またはスクラムの習熟度が高くないなら1週間スプリントから始めよう。

1週間、すなわち5営業日である程度のカタチまで持っていく訳である。具体的にはスクラムチームで「完成」を定義して、その「完成」基準を満たすように作る。

もちろん5営業日では大きなものは作れない。それでも、利用者にとって意味のあるもの、善し悪しを判断できるものを作り上げる。そして、見てもらったり操作してもらって、気に入る・気に入らない、何が欠けているかを評価してもらうのである。

こんな話しをすると、始めてスクラムをするチームは4週間スプリントにしたいと言い出す。新しいメンバーで不安だし、インフラも整っていなかったり、技術的プラクティスもチームに浸透していないから、リスクを踏まえてスプリントは長くしておきたいそうだ。

だが、スプリントが長期化すると、リスクが増える。

• スプリントが小さなウォーターフォールになってしまう。スプリントの中で、要件定義・設計・開発・テストの流れができてしまう。ユーザーと開発者の相互作用が減ってしまう
• 長いスプリントは、プランニングの精度が下がる。従って割り込みリスク、メンバーの病欠リスク等、想定外の状況が増える。柔軟に優先順位付け、作業の再計画ができない限り、新しいチームは機能不全に陥ってしまう
• 長いスプリントでは、PDCAループも長くなるためプロセス改善が進まず、プロセスが安定しない
• スプリントにリズムがでない
• 一定のペースで進めにくい。長いと終盤追い込み型になるリスクが高まる。バーンダウンチャートがなかなか収束しない
• 長いスプリントでは作業の受け渡しが発生しやすい。チームのコラボレーションが進みにくい。手待ちのムダ
• 日々のデイリースクラムが形骸化しやすい
• POが待てずに、スプリント期間中の要求変更が増える。
• スプリント中止リスクが高まる
• プロダクトドメインにもよるが、完成の定義にリリースまで含める圧力がかかりやすい
• プランニング時にバッファーを含める傾向を助長し、スプリントの透明性が欠ける

他にもいろいろあるだろうが、スクラムを始めるなら1週間スプリントから始めよう。1週間なら失敗しても1週間の時間と予算の損失ですむ。4週間だとダメージは4倍だ。自分たちのやり方が確立するまでは、小ロットでいろいろ試して経験を積もう。

50メートルプールや海で遠泳する前に、25メートルプールで何度も往復して練習しよう。チームの泳ぐフォームとリズムが安定してきたら、自ずとタイムも安定してくる。最初は、学習し、発見し、学ぶ為に最短のタイムボックスで練習するのがベストである。

1週間に1つずつ。毎日の暮らしが輝く52の習慣 新品価格 ￥1,510から (2019/5/10 20:45時点)