スプリント

開発が長期間続くと、作り始めたときの前提が変わっていても、成果を確認するまで気づけないことがあります。
スプリント（Sprint）は、スクラムでアイデアを価値へ変える、1か月以内の固定期間のイベントです。
一つのスプリントを終えたら、すぐに次のスプリントを始めます。

実装以外の仕事も期間に含める

スプリントには、計画、実装、検証だけでなく、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブも含まれます。
「2週間開発してから、別の週にテストとふりかえりをする」という区切りでは、開発した2週間だけをスプリントと呼ぶことはできません。
成果を利用可能にし、その結果や仕事の進め方を検査するところまで、同じ期間の中で行います。

期間は、次の判断に必要な成果をどのくらいの間隔で確かめたいかを踏まえて選びます。
たとえば2週間にするなら、2週間で完成の定義を満たす成果を作れるよう、仕事の範囲を小さくします。
期間を短くしても、完成しない仕事が積み上がるだけなら、検査する機会は実際には増えません。

目的と作業項目を区別する

スプリントプランニングでは、チーム全体でスプリントゴールを作り、開発者がプロダクトオーナーと話し合って仕事を選びます。
たとえばゴールを「利用者が注文の配送状況を自分で確認できる」とし、追跡情報の取得と表示を計画したとします。
開発中に外部サービスの制約がわかったら、詳しい履歴の表示を後へ回し、現在の状態を確実に表示する範囲へ調整することが考えられます。

このように、スプリント中でも新しくわかったことから計画を変えられます。
開発者はプロダクトオーナーと範囲を交渉し、スプリントゴールを危険にさらす変更を避けます。
作業項目を一字も変えずに守ることと、ゴールの達成に責任を持つことは、区別する必要があります。

終わりに確かめる二つのこと

スプリントレビューでは、チームと関係者が成果や環境の変化を検査し、次に何をするかを検討します。
配送状況の例なら、利用者が知りたい情報を確認できるかや、新たにわかった制約を踏まえ、プロダクトバックログを見直します。
機能を見せて承認をもらうだけで終えず、今後の選択を話し合います。

スプリントレトロスペクティブでは、チームが品質と仕事の進め方を検査します。
たとえば外部サービスの制約を知るのが遅かったなら、次回は計画前に接続を確かめるなど、試す変更を決めます。
プロダクトをどう変えるかと、仕事の進め方をどう変えるかでは、確かめる対象が違います。

延長と品質低下で帳尻を合わせない

スプリントは、選んだ仕事が終わらないという理由で延長するものではありません。
完成しない項目を完了扱いにしたり、期限に合わせて品質を下げたりせず、残った仕事を改めて検討します。
見込みが外れた理由は、次の計画やふりかえりの材料になります。

ただし、スプリントゴール自体が不要になった場合には、プロダクトオーナーがスプリントを中止できます。
単なる作業の遅れと、目的が意味を失った場合は、別の判断です。
また、完成した成果のリリースは期間中にも行えるため、スプリントの長さがそのままリリース間隔を決めるわけではありません。

参考資料