コーチをしていると、「我々のスプリント期間は短すぎるので、XからYに期間を変更したい」としばしば言われる。

タイムボックスースクラムではスプリント、XPやその他のイテレーティブな手法ではイテレーションと呼ぶーはアジャイルな開発においてチームや組織の問題を明らかにすることができるもっとも強力なツールの1つである。 私が見る限りスプリントの長さが本当に短すぎるケースというのはまれである。 それよりもスプリントの長さが短いと言ってしまうことは根の深い問題のサインだと感じることがとても多い。 スプリントの長さを伸ばしてしまうことは、それらの問題を本当に解決しようとするのではなく、問題を隠してしまうことになる。

スプリントの長さをのばす前に、以下に挙げるような問題がないかどうか「なぜ？」を数回繰り返し自問してほしい。 そしてこれらの問題にまず最初に対処してほしい。 スプリントの長さは本当に短すぎるかもしれないが、改善の取り組み無くしていきなりそこから始めてはいけない。

1. ミニウォーターフォールをしようとしている

ミニウォーターフォールのサイクルを1〜2週間の中にはめ込むのはとても難しい。テストをスプリントの終盤に始めてしまい時間が足りなくなってしまうようであれば、ATDD等を利用してテストを早期に開始するか、一度に取り組むストーリーの数を減らす必要がある。

2. ストーリーの分割がうまくいっていないかストーリーの分割をしていない

オーバーヘッドをかけることなく予測性を向上させるために、私は1スプリント内では6〜10個のストーリーにすることを推奨する。チームは、2週間のスプリントに十分収まる小さいストーリーにすることに苦戦しているためにスプリントの長さの延長を望むことがある。スプリント期間をのばす代わりに、しばらくの間はストーリーを分割するスキルを身につけることに取り組むべきだ。ストーリーの分割は時間をかけて練習するスキルなのだ。

3. ミーティングにとても時間がかかる

たぶんあなたのスクラムのミーティング、特にスプリントプランニングは長くて苦痛なのだろう。そういうミーティングであればあんまり頻繁にはやりたくないと思うのも自然なことだ。でも考えてみてほしい。2週間でやるより3週間でやるほうが50％多くの仕事ができるだろうか？それはたぶんそうだろう。その時スプリントプランニングでは50%多く話すということになる。 ミーティングにおける効果的な時間は通常最初の一時間だ。その後はみんな疲れてしまい注意散漫になり成果が少なくなる。 したがってスプリントプランニングでの内容を50%増やしたら、結果としてのミーティングの時間は50%増しでは効かないことになる。 まぁ、これはそんなにしょっちゅう起こることでもないかもしれない。しかしもしそうなってしまえば今よりも苦痛に晒されることになるだろう。

代わりに、ミーティングをより良くすることに取り組む必要がある。 私がコーチしたあるチームは以下のやり方で1週間のスプリントプランニングの所要時間を10時間から20分に削減することに成功した。

• 毎日とか2日に1回のような短い間隔で、チームの必要なメンバーとバックロググルーミングを行う
• タスクの見積りよりもストーリーポイントのベロシティを使って計画する
• タスクはスプリント期間中に必要になったら洗い出す
• スプリントプランニングをマルチパスで行う。上位レベルの初期のディスカッションとベロシティに基づいたコミットメント、そして各々のストーリーは必要に応じて詳細なディスカッションを行うなど

これらいくつかのテクニックはあなたの役にたつだろうか？

4. デプロイ（もしくはマージや結合などなど）がとても難しい

たぶん、各スプリントごとに完了したストーリーの成果物をある種のステージングサーバや正式なテスト環境にデプロイしようとするだろう。外部のリリースマネージャの手を必要とすることもあるかもしれない。しかしこれはとても時間のロスであり難しいので、あまりやりたくないと思うのも自然なことだ。

私はJez HumbleとDavid Farleyの素晴らしい本「Continuous Delivery」のアドバイスに心から同意する。 「もしそれが苦痛なら、もっと頻繁に実施しなさい。そして苦痛を解決しなさい」（P26）。苦痛を先延ばしにする（プロセスにおいてはそれはより事態が悪化する）代わりに、その苦痛を減らすことに取り組むべきだ。そうすればより頻繁に行うことができるようになる。もし毎スプリントでのデプロイが困難なのであれば、どうやって夜間ビルドや各コミットのタイミングでデプロイできるかを解き明かそう。（Continuous Deliveryはこの手の話に取り組むのにとても役に立つだろう）

5. 2週間で何もDoneにならない

チームは「我々は単に2週間では何も価値あるものをデリバーできないんです。なのでもっと長いスプリント期間が必要なんです」等というかもしれない。 しかしスプリント期間を2週間から4週間に変えたとしても2週間でデリバーできる価値の量には変わりはないのだ。 スプリントの長さをのばす代わりに、以下の2つのことをやってみて欲しい。

ユーザーストーリーをグループ化して価値あるかたまりにして最小のマーケット投入価値のある機能群にする、といった概念を利用しよう。（訳注：ユーザーストーリーマッピングの考え） ストーリーにしたがって作業を進めるが、これらのストーリーがリリース可能な価値についてどれだけ貢献できるかをより可視化できるようになるだろう。 なぜあなたが思っているよりも少ない価値しかデリバーできないのかについて根本原因の分析（たとえば5回のなぜ、とか似たようなツールを使う）を実施しよう。 たぶん対応しなければならない技術的な負債があるだろうし、プロセスのオーバーヘッドが重くのしかかっているかもしれない。 もしくはチーム内で技術レベルに不均衡があってスペシャリストがボトルネックになっているかもしれない。 さらには時代遅れのプラットフォームを利用していて新しい技術を使えばもっと生産性があがるかもしれない。 生産性の低さの原因は色々なことが考えられる。 ただどんな理由にせよ、スプリント期間をのばすことがそれらの問題を解決してくれることはないのだ。

6. フィードバックを得るのに時間がかかりすぎる

もしプロダクトオーナーが質問に答えるのに一週間もかかるようなら、1〜2週間のスプリントで作業を完成させるのは困難なことだろう。 でも3週間にすると事態は良くなるのだろうか？ その代わりに以下にあげるようなフィードバックサイクルを短くする方策をみつけるべきだ。

• POが持っている他の責務を取り除いて、自身のロールに集中できるようにする
• コンタクトしにくいステークホルダーに聞くことなく決定を下せるようにPO（もしくはチーム）にもっと権限を与える
• POや外部のエキスパートに尋ねることになってしまうような大量の質問を減らすためにチームにナレッジを蓄積する（ATDDはこの学びを加速する素晴らしいツールだ）

7. 外部のスペシャリストに依存している

6に関連して、チームはチームの外部からスペシャリストー例えばDBAやテクニカルライターや特定の技術のスペシャリストーの力を借りなければストーリーを完成できないことがある。 そして外部の人間は多くのチームにパートタイムで関わっている。 スプリントの長さをのばす前に以下の対応によって依存性を減らすようにしてみるべきだ。

• スペシャリストをチームに取り込む
• スペシャリストの負荷を下げることで、チームに割ける時間を増やすようにする
• チームでスペシャリストの持っている特定領域の技術や権威を身につける

まとめ

ここにあげたような問題にやられてしまっているとスプリントの長さはとても短いと感じてしまうだろう。 そしてなんとしてでもスプリントの長さを伸ばそうとするだろう。 しかしあなた自身で考えてプロセスを作るべきなのだ。 ただスプリントの長さをのばすことから始めて改善の機会を失うようなことをしてはいけない。