スクラムにおける「準備完了の定義」－ それは何か、なぜ重要なのか

エンドユーザーは時折、新しい機能のアイデアやコンセプトを思いつきます。このコンセプトは1つ以上のエピックとして表現され、チームによってプロダクトオーナーに追加されます。プロダクトバックログ。チームは協力して、このコンセプトを1つ以上のエピックに変換する方法を検討し、その後精査それらをより小さく、明確なユーザーストーリー（実際の製品機能として）にし、次のスプリントの実装に含める。

プロダクトオーナーはチームと協力して、「準備完了の定義」というアーティファクトを定義し、バックログの上位にある項目がスプリントに移行できる状態にあることを保証することで、開発チームがスプリント終了までに確実にコミットし、完了できるようにする。

なぜ「準備完了の定義」が必要なのか？

準備完了の定義（DoR）とは、誰もが何かが開始できる状態にあると判断できるようにする、合意された基準のセットである。たとえば、ユーザーストーリーがスプリントに入る準備ができているとき、またはチームがスプリントを開始するためのすべての必要条件が満たされているときなどである。明確に定義されたDoRは、スクラムチームがそのスプリントゴールを成功裏に達成する可能性を大幅に高める。以下は、適切に構成されたDoRがチームにもたらす利点のリストである：

• バックログ項目の「準備状態」を測定する
• バックログ項目が「十分に準備できた」と見なされることを保証する
• プロダクトオーナーや他のメンバーが負荷過多になっているタイミングをチームが把握できるようにする
• チームメンバー間の相互責任を促進する
• ストーリーが本当に「準備完了」する前に見積もりをコミットする必要性を減らす
• 開発中の「要件のずれ」を軽減する

例－スプリント用の準備完了の定義

異なるチームは、準備状態の定義が異なる場合がある。中には、より少ない基準を要するチームもある。たとえば、一部のチームはユーザーへの価値を説明し、項目を優先順位付け、どのようにそれを示すかを記録するだけで済ませる。見積もりやコミュニケーションはスプリント計画会議で行われる。以下は、チームのDoRを構築する際に検討すべき例の項目である：

• スプリントバックログは優先順位付けされているスプリントバックログには、すべてのバグ、ユーザーストーリー、およびチームがコミットしたその他の作業が含まれる隠れた作業はない
• すべてのチームメンバーがスプリントの能力を計算している
• プロジェクトのフルタイム＝1日あたりX時間
• すべてのチームメンバーがスプリントの能力を計算している
• プロジェクトのフルタイム＝1日あたりX時間
• すべてのユーザーストーリーが「準備完了の定義」を満たしている

例 – ユーザーストーリーの準備完了の定義

このセクションでは、ユーザーストーリーの準備完了の定義の例と、スプリント準備完了の例を示しています。これらのうち一部をベースラインや出発点として採用できます。

• ストーリーはユーザーに対する価値を明確に示している。
• ストーリーの受入基準が明確に定義されている。
• ユーザーストーリーの依存関係が特定されている。
• 納品チームがユーザーストーリーを受け入れている。
• その スクラムチームがユーザーエクスペリエンスのアーティファクトを受け入れている。
• パフォーマンス基準が適切に定義されている。
• 誰がユーザーストーリーを受け入れるかが明確にされている。
• チームはストーリーをどのように提示するかを把握している。

要約

「準備完了の定義」という用語は、スクラムガイドには記載されておらず、それらに組み込まれたユーザーストーリーや受入基準とは異なります。おそらく、「準備完了の定義」を段階的または段階ゲートチェックリストとして使用するのではなく、バックログ精査活動の一部として捉える方が適切かもしれません。バックログ精査は継続的なプロセスであるため、単一のイベントに限定されるものではなく、活動そのものです。