スクラムでの準備完了の定義

エンドユーザーは、新機能のアイデアや概念を持っている場合があります。コンセプトは1つ以上の機能アイテムとして表され、プロダクトオーナーによってプロダクトバックログに追加されます。チームは協力して、この概念を1つ以上のエピックに変換する方法を見つけ、それをより小さく明確なユーザーストーリーに改良します。これは、実際の製品機能として次のスプリント実装に組み込まれます。

ただし、スプリントの前にユーザーストーリーの準備ができていることを確認すると、チームの生産性に直接かつ重大な影響を与える可能性があります。「準備完了」の定義があるということは、ストーリーをすぐに実装する準備ができている必要があることを意味します。チームは、何をする必要があるか、ユーザーストーリーを完了するために必要な作業量を決定できなければなりません。

チームは、製品バックログの一番上にあるストーリーをスプリントバックログに取り込みます。これらのストーリーは「準備ができている」必要があります。一部の企業は、ストーリーが「ほぼ」だけでなく「準備ができている」かどうかを判断するために、実際には詳細なリストを必要としています。

レディの定義を作成する方法は？

プロダクトオーナーはチームと協力して  「準備完了の定義」と呼ばれるアーティファクトを定義し、バックログの先頭にあるアイテムをスプリントに移動する準備ができていることを確認して、開発チームが自信を持ってコミットして完了することができるようにします。スプリントの終わり。

なぜレディの定義？

準備完了の定義は、ユーザーストーリーをスプリントに取り込む準備ができたときや、チームがスプリントを開始するために必要なすべての条件が整ったときなど、何かを開始する準備ができたときに全員に通知する一連の契約です。準備完了の適切な定義により、スクラムチームが スプリントの目標を達成する可能性が大幅に向上し ます。適切に構成されたDoRがチームにもたらすメリットのリストは次のとおりです。

• バックログアイテムの「準備完了」状態を測定します
• 製品のバックログアイテムが「十分に」検討されていることを確認します
• プロダクトオーナーまたは他のチームメンバーがいつ圧倒されるかをチームが特定できるようにします
• チームがお互いに責任を持ち続ける
• ストーリーが「準備完了」になる前に、チームが見積もりにコミットするようにプレッシャーを軽減します
• 開発における「要件のチャーン」を減らす

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

チームが異なれば、準備の歯列も異なり、必要なものも少なくなります。つまり、一部のチームは、ユーザーに価値を説明し、優先順位を付け、デモの方法を書くだけです。その他の見積もりとコミュニケーションは、 スプリント計画会議 などにあります。チームのDORを開発するために検討するサンプル項目は次のとおりです。

• スプリントバックログ が優先されます
• Spring Backlogには、チームがコミットしているすべての欠陥、ユーザーストーリー、およびその他の作業が含まれています
• 隠された仕事はありません
• すべてのチームメンバーがスプリントの容量を計算しました
• プロジェクトのフルタイム= 1日あたりX時間
• すべてのユーザーストーリーはReadyの定義を満たしています

例—ユーザーストーリーの準備の定義

このセクションでは、ユーザーストーリーの準備完了の定義のサンプルと、スプリントの準備完了の定義のサンプルを示します。これらのいくつかをベースラインまたは開始点として採用できます。

• ユーザーにとってのストーリーの価値は明確に示されています。
• Storyの 受け入れ基準 は明確に説明されています。
• 識別されたユーザーストーリーの依存関係
• 配信チームによるサイズのユーザーストーリー
• スクラム チームはユーザーエクスペリエンスアーティファクトを受け入れます
• 必要に応じて、特定されたパフォーマンス基準
• ユーザーストーリーを受け入れる人が特定されます
• チームはストーリーのデモ方法を知っています。

概要

「準備完了の定義」という用語は、スクラムガイドには記載されていません。これは、それに埋め込まれているユーザーストーリーと受け入れ基準と同じです。おそらく、準備完了の定義をシーケンスおよびステージゲートのチェックリストとして使用するのではなく、準備完了の定義が製品バックログの詳細化アクティビティの不可欠な部分であると考えるかもしれません。バックログの詳細化は継続的なプロセスであるため、イベントに限定されるものではなく、アクティビティと見なされます。