開発コラボレーションのヒント from Atlassian Blogs(65) アトラシアンにおける「スプリント計画」の方法

本稿はアジャイルの作法に関するシリーズ第 2 弾です。第 1 弾のアトラシアンにおけるスプリントの「ふりかえり」方法もご覧ください!

毎年、新年になると新たな目的意識が芽生え、ソフトウェア界では、より優れたソフトウェアを世に出すという誓いが立てられます。アトラシアンでは、新年の生産目標の焦点を定め直し、予期せぬ展開を最小限にとどめ、全体的なコード品質の向上を保証するため、スプリント計画のアジャイル作法をとても頼りにしています。私たちが見出した最も役立つスプリント計画の 4 原則を順に説明していきます。

ステップ 1: 会議前にロードマップを確認

時が経つのは速いものです。したがって、新年初頭の 2 週間に、プロジェクトのロードマップに目を通しておくことをお勧めします。ロードマップは、「エピック」と「バージョン」というアジャイルで重要な 2 つの概念にコンテキストを設定します。エピックとバージョンは、アジャイルプログラム計画を根底から支えるもので、作業期間が長い程、デリバリーを追跡するのに役立ちます。スプリント計画会議の前に、ロードマップが最新のもので、チームメンバー全員が目にすることができ、JIRA でエピックとバージョンが正しくリストされていることを確認してください。

ステップ 2: 会議前の先行会議

スプリント計画には 2 つの主要タスクが含まれます。バックロググルーミング (手入れ) と、次回スプリントで完了する作業の決定です。アトラシアンでは、バックロググルーミングは、本番のスプリント会議の前に、プロダクトオーナーとスクラムマスターと共に別会議で行う方が良いことを見出しました。アトラシアンでは、開発チームメンバー全員のこの先行会議への参加は任意としています。

バックロググルーミングとは何か?

バックロググルーミング (手入れ) は、バックログの健全性を確実にします。健全なバックログとはどのようなものか? と質問があるかもしれません。健全なバックログは:

各作業項目に優先順位がつけられ、最重要作業が一番上に表示されている
開発チームが作業を開始できる状態までしっかりと形成されたユーザーストーリーが含まれている
各作業項目に対する最新見積もりが含まれている

アトラシアンでは、チームはスプリント計画の数日前に短時間のバックロググルーミング会議を行います。この会議には 30 分があてられ、続く 2 回のスプリントで取り組む可能性が高い課題をトリアージします。ここで、作業項目に含まれている情報が実行するのに不十分であったり、プロダクトオーナーから詳細なコンテキスト情報を得る必要があると分かることがあります。これが、バックロググルーミングを先行する利点です。本番会議までにこのギャップを埋めることができ、実際のスプリント計画の際にはブロッカー (時間の無駄) となりません。したがって、先行バックロググルーミングを行うことにより、チームはスプリント計画時にはスプリントのオプションを検討し、必要に応じて次回スプリントへの留保事項を検討する時間を長く取ることが可能となります。

チームアクティビティ: チームによっては見積もりに苦労することがあります。ストーリーポイントは見積もりに妥当なフレームワークを提供します。チームで妥当な見積もりを引き出すアクティビティに取組みましょう。このエクササイズを始めるには、ホワイトボードにストーリーポイントの値 (0.5、1、2、3、5、8、13、20、40、100) を横に並べます。次に、チームメンバーに最も妥当だと思われる値の下にユーザーストーリーを配置してもらいます。多くのストーリーは 1 つの数値に集まります。ストーリーポイントの値に関して異論がある場合は、その理由を議題に話し合いを始めてください。

ステップ 3: 本番のスプリント計画会議

スプリント計画会議の焦点は、スプリント目標の設定と同意です。スプリント目標は、そのスプリントで完了可能だとチームが考える作業量です。プロダクトオーナー、スクラムマスター、開発チームメンバー全員が参加する必要があります。アトラシアンでは、会議で取り扱うスプリント 1 週間当たり最低 1 時間割当てることを推奨しています。例えば、2 週間のスプリントを取り扱う場合は、スプリント計画会議に最低 2 時間割当てるということです。スプリント計画の会議日程は週の初めに設定するのが理想的です。そうすれば、週末近くよりもチームのコンテキストとフローが中断される可能性が低くなります。

経験から学んだこと: スプリントのふりかえりとスプリント計画の会議を同時にスケジュールに入れないでください。チームにふりかえりを十分に消化する時間的余裕を与え、効率的にスプリント計画に貢献できるようにします。2 つの会議の間にランチタイムをはさむのもいいかもしれません。

会議開始時に、スクラムマスターはチームのふりかえりで取り上げられたすべての関連アクションを提示します。次に、プロダクトオーナーが製品や市場の最新情報を伝えて全員の足並みを揃え、新たに幅広いコンテキストを理解するようにします。

それらの報告終了後、実際の計画に関する話を始めるのはプロダクトオーナーの責務です。始めるにあたって、プロダクトオーナーはチームの平均ベロシティ (1 回のスプリントで完了した平均的な作業量) を使い、対象スプリントで取り組むべきストーリー一式をまとめます。これを「スプリント予測」と言い、カスタマーへ届ける価値を最大化するようにします。プロダクトオーナーは次の 3 要因も考慮してください。

祝祭日、個人休暇、チーム全体のイベント
バックログでのストーリーの優先順位付け (最上位の項目を勧めることが理想的)
一連の作業がどのように製品を最終目標に近づけるのか（そして、近づけることができるのか)

プロのアドバイス: プロダクトオーナーはスプリントマーカーを使用してベロシティを計算できます。

チームがまだ新しく、利用できる妥当なベロシティがない場合、プロダクトオーナーはスプリント予測を提示できません。代わりに、各メンバーの積極的な参加が重要なチーム全員のエクササイズを行います。まず始めに、チームはスプリント予測に関する最善の判断を出し、何回かのスプリントで試行錯誤を繰り返し対処していきます。チームのベロシティ (JIRA のベロシティチャートで美しく視覚化) を確立できたら、その基準を使用してスプリント予測を導き出します。

プロダクトオーナーがスプリント予測に対する見解を提示したら、チームはそれを認証 (または調整)し、対象スプリントのアクションプランに同意します。

プロのアドバイス: チームは、各スプリントに伴う技術的負債を削減する方法を検討すべきです。チームのバックログにあるバグを強調するクイックフィルターを作成すれば、チームがコードベースの様々な分野でユーザーストーリーに取りかかろうとする時に、スプリントで注目すべき重要なバグを簡単に強調できます。「技術的負債」クイックフィルターは、JQL (JIRA Query Language) “type in (bug)” を使い、バグ表示だけに制限します。必要に応じて JQL クエリを増やすだけでその他の課題タイプにも対応できます。

スプリント計画における次のステップは、ストーリーを順番に検証することと、各ストーリーを完了するために必要な作業内容の説明です。チームが計画を進める際、誰かに要点を各 JIRA チケット内に記録してもらってください。そうすれば後からその決断とその根拠の両方を簡単に確認することができます。チームが検討すべき質問は次のようなものです。

記録時以降、ストーリーの定義は変わったか? チームが検討すべき新しいコンテキスト情報はあるか?
ストーリーの見積もりは現在も妥当か? チームメンバー全員がその見積もりに賛成しているか? 異論がある場合、スクラムマスターはチームに再度見積もりを検討させてください。
ストーリーを完了するのにどのようなタスクが必要か? サブタスクを使い、並行作業を支援し、フローを最適化する。作業を分類中にチームが固有ストーリーを見つけたら、そのタスクを完全に独立したストーリーに押し上げる。
対象ストーリーのテストから推測される事は何か? どうすればテストを自動化できるか? (手動テストスクリプトは基本的に技術的負債であることに注意)
必要な専門的なスキルセットはあるか? どうすれば、残りのチームメンバーを妨害せずに、その専門家の時間を最適化できるか?
ストーリーがプロダクトアーキテクチャにどのような影響を与えるか? デザインやコード検証のためにチームに引き入れる必要がある特定人物はいるか?
各ストーリー間に依存関係はあるか? その依存関係を考慮すると、対象スプリントですべての作業を完了できるか?

この詳細エクササイズを急いで終わらせたいという強い衝動が起きるでしょう。しかし、優れた計画はスプリント開始後に多くの見返りをもたらします。ここでの焦点は、スクラムマスターがチーム内で会話を促進し、作業をどのように完了させていくのかを理解することです。チームメンバー全員が理解することが重要です。計画実行時にチームに当事者意識が芽生えます。

プロのアドバイス: スプリント計画の間、チームがスプリント予測を作成する際に、スプリントにストーリーを簡単に出し入れできます。課題を右クリックするだけで、スプリントに出し入れが可能です。

ステップ4. 位置に着いて、よーい、ドン!

会議がここまで進むと、チームはスプリント予測に満足しているはずです。スプリント計画の終わりに、対象スプリント終了時にチームが何を達成しようとしているのか、会議室で全員に口頭での同意を得るのは良い習慣です。また、各チームメンバーに取りかかれるタスクを最低 1 つ割り当て、作業が重複しないようにしてください。

スプリントごとにチームのエンゲージメントと士気は変動するのが自然です。これらの変動はスプリント計画中に現れますが、その時点でそれを深く掘り下げようとしないでください。代わりに、チームのふりかえりを使い、士気に関わるあらゆる課題を理解してください。チーム文化と開発懸念に対して迅速に対応するチームは満足度が高く、生産性が高く、より優れたコードを生み出します。

スプリント計画であなたのチームが使っているテクニックは何ですか? コメント欄にあなたの意見を書き残してください!