スプリントの期間を長くしたいと思ったら...

みなさんこんにちは。@ryuzeeです。

元記事はLichard Lawrence氏のWhy Longer Sprints Probably Won’t Helpです。良記事でしたので抜粋・意訳にてご紹介します。

本文に入る前に若干前提事項を補足しておきます。

以下で言っている「スプリント期間を伸ばす」というのは、あるスプリントだけの期間を伸ばすのではなく、スプリントのサイズ自体を変えることです（例：2週間スプリント→4週間スプリント）
タイムボックスであることに意味があるので、ご存知の通り「あと1日あれば終わる」とか言ってスプリント期間を延長することは許されません
そしてスプリントの期間は原則固定なので、今回は2週間、次回は4週間、その次は1週間、というのも無しです。ただし変化への対応はもちろん大事。今回はその点に関するお話です

コーチとしてよく、「スプリント期間が短すぎるので、XからYに変更したい」と言われます。

タイムボックス（スクラムではスプリント、XPやその他の方法論でのイテレーションなど）は、アジャイル開発における問題を浮き彫りにする最も効果的なツールの一つです。私が経験した中で、実際にスプリント期間が短すぎるというケースは少ないです。それより、スプリントの期間が短いと感じる背後には、深刻な問題が隠れていることが多いと思います。単純にスプリントの期間を伸ばすのは、問題の本質的な解決ではなく、問題を覆い隠すことになるでしょう。

スプリントの期間を伸ばす前に、以下のような点について「なぜ？」と繰り返し問いかけてみてください。そして、これらの問題へまず取り組みましょう。確かにスプリントの期間が短いこともあるかもしれませんが、その点だけに焦点をあてずに全体を見るべきです。

1. ミニウォーターフォールを試みている

ミニウォーターフォールのサイクルを1〜2週間に詰め込むのは大変です。スプリントの後半で急にテストを開始し、時間が足りなくなる場合、ATDDなどの手法を活用して早期にテストを行ったり、取り組むタスクの量を減らす必要があります。

2. プロダクトバックログアイテムの分割が上手くできていない

無駄な手間をかけずに進捗を予測するために、私は1スプリントで6〜10のプロダクトバックログアイテムに絞ることをおすすめします。スプリント期間内でこれらのアイテムを適切に分割するのが難しい場合、スプリントの期間を伸ばしたくなるかもしれませんが、それよりもアイテムの分割スキルを高めることが重要です。

3. イベントが長すぎる

おそらく、スクラムのイベント、特にスプリントプランニングは長引きがちでしょう。もし2週間の作業を3週間でやると50％の成果が上がると感じるなら、スプリントプランニングでも50％多くの議論が必要になります。しかし、実際にはその効果は期待通りには出ないでしょう。

その代わりに、イベントの効率を向上させる努力が求められます。私が指導したチームでは以下の方法で、スプリントプランニングの時間を大幅に短縮することができました。

チームの必要なメンバーで、毎日または2日に1回の頻度でバックログリファインメントを実施
タスクの見積もりよりもベロシティに基づいて計画を進める
タスクはスプリント中に必要に応じて整理
スプリントプランニングは段階的に行い、必要に応じて詳細な議論を重ねる

このようなアプローチは、あなたのチームにも適用できるかもしれません。

4. デプロイやマージが難しい

スプリント毎に完了したプロダクトバックログアイテムをステージングサーバや本番テスト環境にデプロイすることは一般的です。時には外部のリリースマネージャの協力が必要かもしれません。しかし、これには時間がかかり、煩わしいと感じるのも当然です。

私はJez HumbleとDavid Farleyの「Continuous Delivery」という本のアドバイスに深く同意します。「苦痛な作業であれば、それを頻繁に実施して苦痛を解消すべきだ」という内容（p. 26）です。問題を先送りにするのではなく、解決策を探るべきです。もし毎スプリントのデプロイが難しいなら、夜間ビルドや各コミット毎のデプロイの方法を模索しましょう。

5. 2週間での成果が乏しい

チームは「2週間では価値あるデリバリーが難しい。よって、もっと長いスプリントが必要だ」と感じるかもしれません。だが、スプリントを2週間から4週間に伸ばしても、2週間でのデリバリーの量は変わりません。スプリントを伸ばすより、以下のアプローチを試みると良いでしょう。

プロダクトバックログアイテムをまとめて、価値のある単位に整理する
プロダクトバックログアイテムの進捗を明確にして、どれがリリース可能かを明示する
デリバリーが少ない原因を「5回のなぜ」などの方法で分析する
技術的負債やプロセスの過剰なオーバーヘッドが問題かもしれません
あるいはチームの技術的なスキルの偏りや、古いプラットフォームの利用が生産性を下げているかもしれません

6. フィードバックが遅い

プロダクトオーナーが質問の回答に1週間かかる場合、短いスプリントでの完了は難しいでしょう。しかし、スプリントを3週間に延ばすことが解決策とは限りません。フィードバックサイクルを速めるための方法を検討すべきです。

プロダクトオーナーの他の役割を減少させ、彼らの主要な役割に集中させる
必要以上にステークホルダーに質問しないよう、プロダクトオーナーやチームにもっと決定権を委譲する
チームが自ら問題を解決できるような知識やスキルを蓄積する

7. 外部のスペシャリストへの依存

チームが外部のスペシャリスト（DBA、テクニカルライター、特定技術者など）の協力なしにプロダクトバックログアイテムを完了できない場合があります。これらのスペシャリストは多くの場合、複数のチームでのパートタイム作業をしています。スプリントを長くする前に、以下のような方法で依存関係を削減する試みが必要です。