毎年、新年になると新たな目的意識が芽生え、ソフトウェア界では、より優れたソフトウェアを世に出すという誓いが立てられます。アトラシアンでは、新年において、スプリント計画のアジャイル作法をとても頼りにしています。実行することを定め直し、予期せぬ展開を最小限にとどめ、全体的なコード品質の向上を確実にするためです。私たちが見出した最も役立つスプリント計画の 4 原則を順に説明していきます。
ステップ 1: 会議前にロードマップを確認
時が経つのは早いものです。したがって、新年初頭の 2 週間に、プロジェクトのロードマップに目を通しておくことをお勧めします。ロードマップは、「エピック」と「バージョン」というアジャイルで重要な 2 つの概念により設定されます。エピックとバージョンは、アジャイルプログラム計画を根底から支えるもので、長期間作業のデリバリーを追跡するのに役立ちます。スプリント計画会議の前に、ロードマップが最新のものになっていて、チームメンバー全員が目にすることができ、JIRA 内でエピックとバージョンが正しく一覧表示されていることを確認してください。
ステップ 2: 会議前の先行会議
スプリント計画には 2 つの主要タスクが含まれます。バックログ グルーミング (手入れ) と、次回スプリントで完了すべき作業の決定です。アトラシアンでは、バックログ グルーミングは、本番のスプリント会議の前に、プロダクトオーナーとスクラムマスターと共に別会議で行う方が良いことを見出しました。アトラシアンでは、開発チームメンバーについては、この先行会議への参加は任意としています。
バックログ グルーミングとは何か?
バックロググルーミング (手入れ) は、バックログの健全性を確認するものです。健全なバックログとはどのようなものか? と質問があるかもしれません。健全なバックログとは:
- 各作業項目に優先順位がつけられ、最重要作業が一番上に表示されている
- 開発チームが作業を開始できる状態までしっかりと形成されたユーザーストーリーが含まれている
- 各作業項目に対する最新見積もりが含まれている
アトラシアンでは、チームはスプリント計画の数日前に短時間のバックログ グルーミング会議を行います。この会議には 30 分があてられ、続く 2 回のスプリントで取り組む可能性が高い課題をトリアージします。ここで、作業項目に含まれている情報が実行するのに不十分であったり、プロダクトオーナーから詳細なコンテキスト情報を得る必要があると分かることがあります。これが、バックログ グルーミングを先行する利点です。本番会議までにこのギャップを埋めることができ、実際のスプリント計画の際にブロッカー (時間の無駄) になりません。したがって、先行バックログ グルーミングを行うことにより、スプリント計画時には必要に応じて、様々な選択肢を検討したり、次回スプリントへの留保事項を検討する時間を長く取ることが可能となります。
ステップ 3: スプリント計画会議本番
スプリント計画会議の焦点は、スプリント目標の設定と同意です。スプリント目標は、そのスプリントで完了可能だとチームが考える作業量です。プロダクトオーナー、スクラムマスター、開発チームメンバー全員が参加する必要があります。アトラシアンでは、会議で取り扱うスプリント 1 週間当たり最低 1 時間割当てることを推奨しています。例えば、2 週間のスプリントを取り扱う場合は、スプリント計画会議に最低 2 時間を割当てるということです。スプリント計画の会議日程は週の初めに設定するのが理想的です。そうすれば、週末近くに実施するよりもチームのコンテキストとフローが中断される可能性が低くなります。
会議開始時に、スクラムマスターはチームのふりかえりで取り上げられたすべての関連アクション事項を提示します。次に、プロダクトオーナーが製品や市場の最新情報を伝えて全員の足並みを揃え、より幅広いコンテキストを得られるようにします。
それらの報告終了後、実際の計画に関する話を始めるのはプロダクトオーナーの責務です。始めるにあたって、プロダクトオーナーはチームの平均ベロシティ (1 回のスプリントで完了した平均的な作業量) を使い、対象スプリントで取り組むべきストーリー一式をまとめます。これを「スプリント予測」と言い、カスタマーへ届ける価値を最大化するようにします。プロダクトオーナーは次の 3 要因も考慮してください。
- 祝祭日、個人休暇、チーム全体のイベント
- バックログでのストーリーの優先順位付け (最上位の項目を勧めることが理想的)
- 一連の作業により、製品は最終目標に近づくか
チームがまだ新しく、利用できる妥当なベロシティがない場合、プロダクトオーナーはスプリント予測を提示すべきではありません。代わりに、チーム全員によりそれを行います。各メンバーに参加してもらうことが重要だからです。まず始めに、チームはスプリント予測に関する最善の判断を出し、試行錯誤しながら、2、3 回のスプリントを行います。チームのベロシティ (JIRA のベロシティチャートで美しく視覚化可能) を確立できたら、その基準を使用してスプリント予測を導き出します。
そして、プロダクトオーナーがスプリント予測を提示したら、チームはそれに同意 (または調整)し、次のスプリントのアクションプランに同意します。
スプリント計画における次のステップは、ストーリーを順番に確認することと、各ストーリーを完了するために必要な作業内容の説明です。チームが計画を進める際、各 JIRA チケット内に要点を記録するよう誰かをアサインしてください。そうすれば後からその意思決定と根拠の両方を簡単に確認することができます。チームが検討すべき質問は次のようなものです。
- ストーリーを定義した後に、それは変わってないか? チームが考慮すべき新しいコンテキスト情報はあるか?
- ストーリーの見積もりは現在も妥当か? チームメンバー全員がその見積もりに賛成しているか? 異論がある場合、スクラムマスターはチームに再度見積もりを行わせること。
- ストーリーを完了するのにどのようなタスクが必要か? サブタスクを活用して、並行して作業を行えるようにし、フローを最適化する。作業を分類中に独立したストーリーを見つけたら、別のストーリーを作成しそれに関するタスクを分類する。
- ストーリーのテストから推測される事は何か? どうすればテストを自動化できるか? (手動テストスクリプトは基本的に技術的負債であることに注意)
- 専門的スキルセットが必要とされているか? 他のチームメンバーを邪魔せずに、その専門家の時間を有効利用するにはどうしたらよいか?
- ストーリーがプロダクトアーキテクチャにどのような影響を与えるか? デザインやコード検証のためにチームに引き入れる必要がある特定人物はいるか?
- 各ストーリー間に依存関係はあるか? その依存関係を考慮しても、対象スプリントですべての作業を完了できるか?
この細かいエクササイズを急いで終わらせたいと思うかもしれません。しかし、優れた計画を立てれば、スプリント開始後に多くの見返りがあります。ここでのポイントは、作業をどのように完了させていくのかを理解することです。スクラムマスターがチーム内での会話を促すことを利用します。チームメンバー全員が理解することが重要です。計画実行時にチームに当事者意識が芽生えます。
4. スプリントを開始する！
会議がここまで進むと、チームはスプリント予測に満足しているはずです。スプリント終了時にチームが達成しようとしていることについて、スプリント計画の終わりに会議室で全員に口頭での同意を得るのも良いかもしれません。また、始めに取りかかれるタスクを各チームメンバーに最低 1 つ割り当てましょう。作業が重複しないようにしてください。
スプリントごとにチームのエンゲージメントや士気が上がり下がりするのは自然なことです。そのような変動はスプリント計画中に現れますが、その時点でそれを深く掘り下げようとしないでください。代わりに、チームのふりかえりを使い、士気に関わるあらゆる課題を理解してください。チーム文化と開発懸念に対して迅速に対応するチームは満足度が高く、生産性が高く、より優れたコードを生み出します。
スプリント計画であなたのチームが使っているテクニックは何ですか? コメント欄にあなたの意見を書き残してください!
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2015 年 1 月 7 日投稿 "Sprint planning at Atlassian: How we do it"