第4章 スプリント

スプリントでは、開始日と終了日が決められている。
スプリントの期間中はゴールやメンバーを変えてはいけない。
最終的に、スクラムチームで合意した「完成の定義」をみたす出荷可能なプロダクトインクリメントが生み出される。

スプリントをタイムボックス化することで得る利点

• WIPに上限を設ける
• 優先順位付けを強制する
• 進捗状況を可視化する
• 不必要な完璧主義を避ける
• 締めくくりの促進
• 予測可能性を改善する

短期間のスプリントにすることで得る利点

• 計画の立てやすさ
• 素早いFB
• 投資収益率の改善
• 損失の限定化
• 熱狂を取り戻す
• 頻繁なチェックポイント

スプリントは止むを得ない理由がない限り期間を変えてはいけない
やむを得ない理由は

• よりフィードバックの頻度を上げるために、スプリントの期間を短くする
• 年次休暇や会計年度末が含まれる場合
• プロダクトのリリース頻度とスプリントの期間があっていない

スプリント中にゴールを変更してはいけない
明確化ならあり
例えばゴールを追加するなら別チケットにする
実利的に考えてゴールを変更するということならあり。
例えば障害が発生しているときには障害の対処をまずはゴールにすべきである

完成の定義とは、そのプロダクトが出荷判断可能であると宣言する前にチームで終わらせておくチェックリスト(以下のチェックリストが例)

• 実装済み
• テスト済み

完成の定義にはプロダクトの機能が完成しているという観点は最小限含むべき

ここまでの感想や実際の現場との差異

• 自分たちのチームでは一人一アイテムを担当しているので、WIPの数が人数分になる
  • ある意味、作業の手持ちがなくなるが、スプリントの優先順位順にできているとは限らない
    • 優先順位をつけても意味がない部分も一定あるのでは
• GWなどの長期休暇に合わせてスプリントの期間を長くするのは正しいかったのではないか
• リリースは完成するたびにやるので、本来ならスプリントの振り返りときに確認してリリースするかを判断すべきなのではないのか
  • とはいえ、これはweb系などで合うのかな