作業項目をプロトタイプとメイン作業項目に分割しますか？
グルーミング中、私たちは通常、何をする必要があるかをチームが理解したことに基づいて承認される作業項目を持っていますか？製品の所有者は、それがどのように行われるかについての詳細について話し合うことはなく、チームがそうしようとすると話し合いを中止します。これは、すべての作業項目（新しいUI、新しいAPI、または既存のUI/APIへの変更）に適用されます。プロダクトオーナーの推論は、それがどのように行われるかについての詳細（技術的および機能的の両方）に入るのはスプリント中に起こる必要があることであり、グルーミング中にそれを議論することは正しくないということです。労力の見積もりも、この議論に基づいて行われます。
ただし、スプリントの計画中に、承認されたアイテムがスプリントに使用されます。作業アイテムが承認された場合、チームはソリューションのすべての詳細を知っており、スプリントでアイテムを完成できる必要があります。チームは最初の2〜3日を調査に費やし、ソリューションに対するPOの承認を取得します（UI設計、主要なビジネスロジックの明確化）。分析の結果、作業量の見積もりに大きな違いが生じない限り、チームは機能を完了するように求められます。これは各スプリントで発生します。
作業項目を完了するために余分な労力を費やしても問題はありません。私の質問はプロセスに関するものです。
- チームがソリューションがどのように見えるかを理解していない限り、チームはアイテムの承認にノーと言うべきですか？
- 作業項目を調査/分析に分割して、ソリューションのプロトタイプをPOに提案する必要がありますか？ POがプロトタイプを承認すると、主要な作業項目に承認済みのマークが付けられます。
- それをより良い方法で処理する方法に関する他の提案はありますか？
計画会議の詳細レベルは、POの個性と専門知識に大きく依存します。
例としてユーザーインターフェイスを取り上げます。一部の製品所有者は、強力なUXスキルを持っているか、チーム外のUXエキスパートを使用しています。これらのPOには、計画会議に大まかなUX仕様が付属している方がよいでしょう。その他の場合、このスキルはチーム内により多く存在します。これらのチームは、実装の一部としてUXデザインを処理します。この問題は、POがUIについて強い意見を持っているが、彼が望むものを事前に伝えられない場合に発生します。それはチームにとって不公平です。
要するに、それが作業項目の受け入れに影響を与える場合、POは計画会議での質問を避けてはなりません。
一方、彼がすべての答えを準備することを期待することはできません。チームは積極的に考え、彼にいくつかの選択肢を与える必要があります。
計画会議でこれに取り組む良い方法の1つは、POに「もし...なら話を受け入れますか」という質問を作成することです。
質問に戻る：
チームがソリューションがどのように見えるかを理解していない限り、チームはアイテムの承認にノーと言うべきですか？
はい、POが何を受け入れ、何を受け入れないかを明確にできない場合は可能です。
作業項目を調査/分析に分割して、ソリューションのプロトタイプをPOに提案する必要がありますか？ POがプロトタイプを承認すると、主要な作業項目に承認済みのマークが付けられます。
特定の作業項目については、反復的なアプローチが最適だとみなされます（「これがどのように機能するかを確認してから、変更が必要かどうかを判断しましょう」）。次に、2つの項目に分割することをお勧めします。ただし、ステップ1をプロトタイプとは考えず、チームとPOの現在の理解に基づいて、「出荷可能」にします。 POはいつでも作業項目を定義して、後で改善することができます。
それをより良い方法で処理する方法に関する他の提案はありますか？
一部のチームまたはPOは、計画会議の前に大まかなUX仕様（ワイヤーフレーム）を準備します。早期の失敗を目指します。同意するのにちょうど十分です。チームが作業項目にコミットするときに、スコープが事前に明確化されているようにします。
それを行う別の方法は、セッションを2つの部分に分割することです。
最初のものでは、プロダクトオーナーは、要件を理解するためにチームが必要とする詳細レベルに入ります。この部分では、労力の見積もりは行われません。次に、POが部屋を出て、チームは「どのように行われるか」を含む見積もりプロセスから開始します。
POは、出てくる質問に答えるために利用できる必要があります。これはスプリントプランニングの重要な部分であり、プランニングポーカーやその他の見積もり手法を含めることができます。計画に永遠に時間がかからないことが重要であり、セッションを閉じる終了時間を設ける必要があります。
チームが重要と考えるものはすべて、計画セッション中に話し合う必要があります。それは良い習慣です。チームが部屋を出て、たくさんの質問がある場合、生産的になることは不可能です。未知の要因が多すぎる場合は、スパイクを開始して概念を調査したり、単純なプロトタイプを作成したりできます。しかし、それは例外であり、規則ではありません。
チームがソリューションがどのように見えるかを理解していない限り、チームはアイテムの承認にノーと言うべきですか？
いいえ、もちろん違います。実装の詳細がわからない場合、チームは後で最も簡単な解決策を見つける余裕があります。これは議論が妨げられるべきであるという意味ではありませんが、それは確かに制限されるべきです。
たとえば、計画会議で、特定の方法でストーリーを再生することが決定されたとします。チームはスプリント中にそのデザインを使用することを強制されるべきですか？それは アジャイルマニフェスト とは反対です。
作業項目を調査/分析に分割して、ソリューションのプロトタイプをPOに提案する必要がありますか？ POがプロトタイプを承認すると、主要な作業項目に承認済みのマークが付けられます。
いいえ、これはチームの助けにはなりません。プロトタイプはユーザーにとって価値がなく、したがってスクラムによると優先度が最も低いはずだからです。ストーリーにコミットした後ではなく、必要な場合にのみプロトタイプを作成する必要があります。
それをより良い方法で処理する方法に関する他の提案はありますか？
私はいくつかを持っています：
製品の所有者がスクラムマスターを演じているのはなぜですか？役割は実際には別々である必要があり、そうでない場合は一般的に悪いアイデア™です
なぜあなたはあなたの物語を2回見積もるのですか？これは実際には起こらないはずです。何がスプリントに収まるかを理解するために、一度、不正確にそれらを見積もります。その点を超えて誰も気にする必要はありません-測定はあなたが実際に達成するものになります。もちろん、タスクの見積もりが存在する可能性がありますが、スプリントに適合するものを見積もるために使用してはならないため、意図的に別のユニットのセットに含まれています、ただし、残りの作業量のみです。
スプリント中にPOとのコラボレーションに問題があるようです。たとえば、「チームは最初の2〜3日間、調査を行い、ソリューションに対するPOの承認を得るのに苦労している」と言います。これは私には意味がありません。 POは、特定のソリューションにコミットするのではなく、ユーザーの最終結果に関心を持つ必要があります。彼らは事前にいくつかのエンドツーエンドの受け入れテストを指定するようになりますが、それらに合格するものはすべて公正なゲームです-他のものはすべて新しい話でなければなりません。
プロトタイプ->ストーリーパイプラインを持つというあなたの提案は、コラボレーションに反し、役割の分離に向かいます。代わりに、本当に必要なのは、スプリント全体でPOとチームが協力し、互いに話し合うことです。ストーリーは、完成するまでデザインしないでください。あなたが「プロトタイプ」と呼ぶものは、本当に物語であるべきです。
私の意見では、あなたの問題はここにあります：
「分析の結果、作業量の見積もりに大きな違いが生じない限り、チームは機能を完了するように求められます。」
「アジャイル」を望んでいる別の会社は、見積もりと米国のより詳細な定義に時間を費やしていません（そしてそれは完全に大丈夫です）が、見積もりと妥協。
SMは、これを経営陣に説明する必要があるものであり、チームが完全な機能のために残業する必要がある状況では、スプリント後の通常のスプリントは、SMがすぐにこのナンセンスに終止符を打ち、持続可能なペースを回復する必要があります。チーム。
持続可能なペースを持っていることは、アジャイルのコアバリューの1つであり、すべての米国をスプリントに含めることはもちろんそうではありません。長い目で見れば、最初のものは2番目のものよりもはるかに重要であり、これを理解するための鍵です。