# スプリント（イテレーション）計画
〜目標を明確にして、チームを集中させる〜
# 言葉の説明
この文章では、アジャイル開発の用語が多いため、まず最初に言葉の説明をします。
# スプリント（イテレーション）とは
スプリント（イテレーション）は、１〜４週間で固定された開発サイクルの時間単位のことです。
この時間単位はチームで自由に決めることができます。
# ストーリーとは
ストーリーとは、実装する要件を意味します。
明確に完了の定義がされていることが必要です。
# スプリント計画とは
開発チームがプロダクトオーナーと協力して、次のスプリントについての計画を行い、目標とその結果の認識を一致させるイベントです。
チームメンバーは、プロダクトオーナーのすべての受け入れ条件が満たされ、
完了の定義が満たされるレベルまで機能を提供するために、機能を細かいタスクに分解します。
その上で見積もり、次回のスプリントで完了できるのはどこまでかの認識を全員で合わせます。
# なぜスプリント計画をするのか
スプリント計画は、チームの成功のために設定します。
終了日（締切日）が設定されている場合、チームは目標や活動により重点を置く傾向があり、作業を完了させる必要があります。
全体的なスプリント目標を念頭に置いて、チームを集中させ続け、プロジェクトを通しての進捗を確実なものとします。
また、スプリント計画をチームメンバーはスプリントに受け入れられる機能についてのプロダクトオーナーやステークホルダーの受け入れ基準についての共通の理解を深められ、
プロダクトの機能を提供するために必要なすべての作業タスクを決定することができます。
# どうやっておこなうのか
一般的なスプリントの期間は１〜４週間です。
その期間の始まりの日にスプリント計画を開催します。
一般的にスプリント計画は１週間のスプリントで１時間、２週間だと２時間かかります。
# やり方
- プロダクトオーナーが用意した優先度がつけられたストーリーを説明します。
- 各々、質問をします。
- 各ストーリーの担当を割り振ります。
- 次のスプリントで完成するストーリーについて認識を合わせます。
アウトプットとして、次のスプリントで行うストーリーの一覧ができます。
# 注意点
# ストーリーの完了の定義を明確にしよう
せっかくストーリーを完了させても実はプロダクトオーナーの思うストーリーと違った
なんてことにならないように最初に認識をきちんと合わせておきましょう。
例えば、極端ですが、「ユーザーがAIからアドバイスをもらうことができる」というストーリーを作ってしまうと
何を作ればいいのかが不明です。
チームで認識の合わせたストーリーが書かれていることが大切です。
# スプリントが終わったらふりかえりをしよう
スプリント計画を行う前に
前回のスプリントのふりかえりをしておきましょう。
ただスプリントを繰り返しているだけでは、高い効果は見込めません。
ふりかえりをして、どうやればよりうまくいくのかを検証しましょう。
# 見積もりを行う場合
チームの中で合意が取れていて、認識が一致していることが最も大事です。
この点を忘れずに見積もりを行なってください。
あるチームの見積もりでは３だったストーリーが違うチームだと１になることや１０になることもあります。
これはそのチームの状況、技術レベル、コードの品質などの様々な要因が異なるためです
他のチームとの比較や、他のチームが見積もったものをそのまま使うのはやめましょう。
# 見積もり方法
実際に行う見積もりの方法を簡単にご紹介します。
見積もりは相対的に行います。
一般的な手法としては、プランニングポーカーです。
１、２、３、５、８、１３・・などのカードを使って相対的に見積もる方法です。
カードをメンバー全員で同時に出し、違うカードが出た場合は、話し合いを行います。
この数字はちょうどよい幅で数字が区切られているため、
意見が割れた際に議論をしやすくなります。
また、Tシャツのサイズを使って、S（小さい）、M（普通）、L（大きい）、XL（とても大きい）や
果物を使って、さくらんぼ（小さい）、林檎（普通）、スイカ（大きい）
などを使ったものでも、チームの認識さえ揃っていれば問題ありません。
# スプリント計画は安定と継続可能性を意識しよう
今のチームがスプリントでどの程度のストーリーを終えられるのかを学ぶことが大事であり、
スプリント計画を終わらせることを重視しぎてはいけません。
残業や無理をして終わらせたとしても、短期的には計画通りに行くのでよいかもしれませんが、
中長期的にはチームが疲弊して安定したストーリーの消化が難しくなってしまう可能性があります。
予定では終わるはずだったのに終わらなかった場合はふりかえりの際に、
なぜ終わらなかったのか、ストーリーが大きすぎたのではないか、もっと工夫すべき点はないのか、チームで協力できたことはないのかなどを見直していくことが大切です。
また、何か問題が発生して終わらなくなりそうな場合には、それがわかった段階でチームに共有して解決をするのが適切です。
継続的に改善していくことで、徐々に上手にはやくDeliveryすることが可能になります。
# 参考資料
# さいごに
文章の改善のため、フィードバックや質問などありましたら、こちら (opens new window)からお願いいたします。