準備完了の定義—ユーザーストーリーはすぐに実行可能でなければなりません。
エンドユーザーは、新機能のアイデアや概念を持っている場合があります。コンセプトは、プロダクトオーナーによってプロダクトバックログに追加される1つ以上の機能アイテムとして表され ます。開発チームは協力して、 この概念を1つ以上の叙事詩に変換し、それをより小さく、より明確なユーザーストーリーに分解して、真の製品機能として次のSprintの実装に組み込む方法を見つけます。
プロダクトオーナーはチームと協力して 「 DefinitionofReady 」と呼ばれるアーティファクトを定義し、製品バックログの最上位にあるプロジェクトを スプリントに移行する準備ができていることを確認して、開発チームが自信を持って最後にプロジェクトをコミットして完了することができるようにします。スプリントの。
レディの定義の目的は何ですか?
Readyの定義は、ユーザーストーリー をバックログから次の スプリントの開発に移すために満たす必要のある条件を説明してい ます。定義準備完了ステータスを持つユーザーストーリーの考慮事項は、ストーリーがすぐに実行可能でなければならないことを意味します。
なぜレディの定義?
準備完了の定義は、ユーザーストーリーをスプリントに取り込む準備ができたときや、チームがスプリントを開始するために必要なすべての条件が整ったときなど、何かを開始する準備ができたときに全員に通知する一連の契約です。準備完了の適切な定義により、スクラムチームが スプリントの目標を達成する可能性が大幅に向上し ます。適切に構成されたDoRがチームにもたらすメリットのリストは次のとおりです。
- バックログアイテムの「準備完了」状態を測定します
- 製品のバックログアイテムが「十分に」検討されていることを確認します
- プロダクトオーナーまたは他のチームメンバーがいつ圧倒されるかをチームが特定できるようにします
- チームがお互いに責任を持ち続ける
- ストーリーが「準備完了」になる前に、チームが見積もりにコミットするようにプレッシャーを軽減します
- 開発における「要件のチャーン」を減らす
例—ユーザーストーリーの準備の定義
このセクションでは、ユーザーストーリーの準備完了の定義のサンプルと、スプリントの準備完了の定義のサンプルを示します。これらのいくつかをベースラインまたは開始点として採用できます。
- ユーザーにとってのストーリーの価値は明確に示されています。
- Storyの 受け入れ基準 は明確に説明されています。
- 識別されたユーザーストーリーの依存関係
- 配信チームによるサイズのユーザーストーリー
- スクラム チームはユーザーエクスペリエンスアーティファクトを受け入れます
- 必要に応じて、特定されたパフォーマンス基準
- ユーザーストーリーを受け入れる人が特定されます
- チームはストーリーのデモ方法を知っています。
概要
「準備完了の定義」という用語は、 スクラムガイドには記載されていません。これは、ユーザーストーリーとその中の受け入れ基準と同じです。おそらく、Readyの定義を順次の段階的なチェックリストとして使用する代わりに、バックログアイテムの改良アクティビティの一部と考えることができます。 バックログアイテムの改良 は継続的なプロセスであるため、イベントに限定されず、アクティビティとして扱われます。