適切なReadyfor Sprint定義には何が含まれている必要がありますか？
当社のチームは、適切なバックロググルーミングを行うために私たちと一緒に多くの時間を費やすことができないような立場にあるプロダクトオーナーに対応します。
したがって、時間の制約の一部を緩和するために、ストーリーを「スプリントの準備ができました」、言い換えれば、ストーリーをスプリントに取り込むのに十分な知識/理解のある状態にする技術の実装を開始しました。
残念ながら、「Ready For Sprint」の適切な定義はまだ新しいので、バックログのReady for Sprintでストーリーを取得するときに、何を覚えておくとよいのでしょうか。
[編集]
RyathalとDonalFellowsの回答とコメントに応えて、私たちは実際にストーリーを構築するつもりはないことを説明したいと思います。これで説明されているように、既存のストーリーを「ReadyforSprint」にする方法を適用したいと思います ブログ投稿 。製品の所有者はおそらくこれに追加する必要がありますが、前述のように、私たちは製品の所有者との主要な立場にありません（まだ）。
ストーリーのエフォートポイントが5以下の場合、ストーリーの最小受け入れ基準が定義されている、またはBalsamiqモックアップが必要な場合など、ストーリーを準備完了状態にするなどの定義を作成できることを確認しました。
私の質問は、他の人が彼らの定義で何を使用し、何が彼らのために働いたかを見つけることに向けられています。 :)
スプリントの最後に、受け入れが問題にならないように、十分な情報が含まれている必要があります。
1文で十分な場合もあります。
多くの場合、チームメンバーの中には、誰も気が変わって合意されたすべてのことを覚えていないことを確認するために、より多くの情報/要件を書き留めておく必要があります。
書き留めたものはすべて、可能な限り客観的/検証可能でなければなりません。 「given/when/then」と「as ... i ... so that ...」は、コンパクトな形式で多くの情報と検証可能な要件を伝達するため、非常に多くの形式が好きです。
ストーリーのライフサイクルのさまざまな段階で「ルール」またはゲートを定義しようとする試みをいくつか見ました（スプリントの準備ができて、受け入れられました...）-そして私の経験では、ルールだけではうまく機能しません。ストーリーに含める必要のあるもの（ユースケース、テストプラン、モックアップ、受け入れ基準、ドキュメントなど）のリストが過度に網羅されてしまうことは非常に簡単です。それらのアイテムが「良い」ことを保証することは非常に困難です。そして、多くの場合（多くの共有コンテキストまたは驚くべきコンテンツを含まない単純なストーリー）、モック、テスト計画、および詳細は時間の無駄です。
最近の例：「XとしてYしたい」を奨励すると、「管理者として、プラットフォームでデータの機密性と整合性が維持されることを期待しています」という結果になりました。ガイドラインを満たしていますが、配信/テスト/ドキュメント化する必要があるものを開発者に伝えるのにはまったく役に立ちません。
POと開発者の間の良好なコミュニケーションから逃れることはできないと思います。そして、それぞれの側が何を考えようとしているのかについての良い感覚で十分です。
次の場合、ストーリーは「スプリントの準備ができています」。
- 検証可能な要件が含まれており、
- あなたはそれがクライアントが望んでいるものと一致すると信じています。
また、所有者と協力して、所有者があなたと協力するために費やすことができる時間を増やし、彼らがまだできない場合は、彼らが自分でバックロググルーミングを行うことができる方法を見つける必要があります。より多くの関与を得るための最良の方法は、現在のレベルの相互作用で品質を提供し、さらなる関与が結果をさらに改善できることを説明することです。
レディの定義はかなり自明であり、明示的に定義する価値はないと思います。
スプリントが終了するまでPOが消え（発生する可能性があります）、チームがストーリーの内容を作成した場合、プロダクトオーナーが「これは私たちが合意したものではありません」と言うことができる方法はありますか？そうでない場合は、準備ができています。
スプリントへのPOの関与、およびストーリーのタイプに応じて、これは非常に詳細な場合と非常に単純な場合があります。