ユーザーストーリーの品質の向上 [終了]

Question

私たちはスクラムを使用します。スプリント中に、スプリントを完了するために必要な労力を把握するにはユーザー ストーリーの粒度が十分ではないことが判明すると、問題が発生します。

特に、元のストーリーが暗示しているよりもはるかに複雑な UI ワイヤーフレームが提供されていることがわかります (例:ユーザビリティ上の理由から、機能は重複しています)。これにより、バーンダウン チャートはスプリントの最終日にすべてが完了したように見えます。

私たちは、2 週間の各スプリントの開始時に月曜日を費やして、プロジェクト チームが作成したストーリーを検討します。通常、その間にストーリーを少し調整してタスクに分割し、バーンダウンを作成するためのそれぞれの時間を見積もります。チャート。この日は、ストーリーの質を有意義に向上させる時間がないようです。

スプリントの不完全/不十分なストーリーのサイクルを断ち切る最善の方法は何でしょうか?

これは、プロジェクト チームが最初にストーリーを十分に具体化できなかったことが原因なのでしょうか、それとも、我々は（つまり、開発チーム）責任の一端はあるのでしょうか？

Answer 1

それであなたはこう言っているのですか：

1. 顧客/ユーザーがプロジェクト チームと話す
2. プロジェクト チームがストーリーを書き、ワイヤーフレームを作成する
3. 開発チームはストーリーをタスクと見積もりに分割します

開発チームが実際に顧客/ユーザーと話す可能性はありますか?ユーザーストーリーは、要件文書/仕様書とは対照的に、会話を開始する方法として見られることがあります。

編集：いくつかのリンク:

• ガゼルがガゼボに相当するように、ユーザー ストーリーはユースケースに相当します。
• 優れたユーザーストーリーの 6 つの特徴 - INVEST モデル
• 顧客はいつでも対応可能です

編集：マーティン・ファウラー氏は昨日、ブログに投稿しました。 会話的なストーリー 私よりもはるかに上手にこれをカバーしています。

Answer 2

スプリントの振り返りを実施していますか?振り返りの最後には、前のスプリントで起こったことを改善するための優先度の高い実行可能な項目が必要になります。 同じことが繰り返しうまくいかないはずがない.

スプリント中にプロダクト所有者にアクセスできますか?そうでない場合は、ユーザー ストーリーの詳細が不完全であるため、見積もりにさらに追加する必要がある可能性があります。

スプリントの 5% を製品バックログの整備に充てるという @Pascal の提案は良いものです。これにより、スプリントの開始前にユーザー ストーリーをより詳細な場所に配置できるようになります。

私たちは、プロジェクトチームが作成した2週間のスプリントの開始時に月曜日を過ごします。その間、私たちは通常、ストーリーを少し洗練し、タスクに分解し、それぞれがバーンダウンを作成する時間を推定しますチャート。この日、ストーリーの質を有意に向上させる時間があるとは感じません。

これはスプリント計画セッションのようですが、スプリント中に完了するようコミットするユーザー ストーリーを制御できますか?十分な詳細情報がない場合、どうやってコミットできますか?

これにより、良い振り返りを行うことができます。 解決する 提起された問題。

スプリントのために不完全 /不十分なストーリーのサイクルをどのように破るのが最善ですか？

振り返り、計画、未処理の整理。

これは、プロジェクトチームが最初に十分にストーリーを特定できなかったのでしょうか、それとも私たち（すなわち開発チーム）責任の一部を取りますか？

それはチーム全体の責任です。責任を見つけることは価値を生みませんが、 みんな 責任を取ることで与えられる みんな プロジェクトが無事に完了するチャンス。

おそらく月曜日の朝の計画セッション中に、ユーザー ストーリー/ワイヤーフレームを作成している人を巻き込んで、どの詳細が欠けているか、どの詳細を見積もればより簡単かつ正確に見積もることができるかを一緒に見つけ出すことができます。おそらく、何を含めるべきかのテンプレートが作成されるかもしれません。

Answer 3

私たちは（といくつかの点での継続）、この同じ問題を抱えていました。私は、この問題は、先行分析の不足、ユーザーストーリーを推定するのに十分な時間を費やして開発者の不足があると思います。

あなたのような話を始めます

As an administrative user I can create a new widget.

OK、それは何を意味するのでしょうか？いくつかの分析の後、それが意味するかもしれません。

As an administrative user I can create a new widget in created status with complex data validation errors.

その後だから、フィールドのリストについては、どのように大きな、そしてどのような必要なフィールドをデータベースに保存するためのものです。基本的なUIのモックアップにもいいだろう。

次のスプリントのための別のユーザーストーリーは次のようになります。

As an administrative user I can edit a created widget and correct the complex data validation issue to move the widget to completed status.

そして、複雑な検証ルールのリストます。

Answer 4

私たちは 2 週間の各スプリントの開始時に月曜日を費やして、プロジェクト チームが作成したストーリーを確認し、その間に通常はストーリーを少し修正します。

スプリントの開始時には、ストーリーは READY になっている必要があります。それらを少し改良する必要がある場合は、あなた (開発チーム、スクラムマスター、プロジェクト チーム) がそれを少し前に、前のスプリント中に行うべきだと思います。

スプリントの不完全/不十分なストーリーのサイクルを断ち切る最善の方法は何でしょうか?

あなたはストーリーを過小評価しているか、ストーリーが大きすぎて曖昧すぎるのかもしれません。どちらの場合も、これは見積もりの​​問題のように思えますが、改善する良い方法はストーリーのサイズを減らすことです。この問題に取り組むには、ある程度の時間を割くことができます (例:各スプリントの 5%) から 製品バックログの整備 最も重要なストーリーを準備し、それらを配置してサイズを縮小するため ダイエット中 もし必要なら 前に 次のスプリント。これにより、実際にスプリント計画会議がよりスムーズになります。

これは、プロジェクト チームが最初にストーリーを十分に具体化できなかったことが原因なのでしょうか、それとも、我々は（つまり、開発チーム）責任の一端はあるのでしょうか？

私の個人的な意見では、責任はそれほど重要ではありません (おそらく政治的理由を除いて、いずれにしても大きな価値を生み出しません)、開発チームとプロジェクトチームは両方とも協力し、一緒に「失敗」しています。ここで重要なのは、障害を取り除くために検査し、適応することです。したがって、この問題を可視化するのは開発チームの責任です ( は 障害です）。そして、この障害に対処するのはスクラムマスターの責任です。失敗はそれに取り組まないことだろう。バックログ グルーミング セッションは、そのための 1 つの方法です。そして最終的には、プロジェクト チームが改善され、開発チームが何を期待しているのかをよりよく理解できるようになると確信しています。そして、二人ともより良い結果を生み出すでしょう。

Answer 5

問題のスクラムの側面に関して、すでに多くの良いアイデアがここにあります。あなたのコメントに基づいて:

特に、元のストーリーが暗示しているよりもはるかに複雑な UI ワイヤーフレームが提供されていることがわかります (例:ユーザビリティ上の理由から、機能は重複しています)。

ただし、開発プロセスにも取り組む必要があるのではないかという懸念もあります。UI 内の複数の場所から機能にアクセスするには、ほとんど時間を費やすことなく簡単に追加できる必要があります。これが一般的な問題であると思われる場合は、機能が特定の UI 要素と密接に結合しすぎていることを意味します。チームは設計スキルを向上させる必要があるかもしれません (例:パターンの使用法）。

Answer 6

これは面白いです。あなたがスプリントでスプリント計画をしているように見えるでしょうか？そして、スプリントバックログは、スプリント計画前にコミットしていること？もしそうなら、どのようにチームは話の詳細を議論することなく、スプリントバックログにコミットされますか？

別のアプローチは、特定の物語が原因明確性の欠如のためにスプリントバックログに追加することができないことをプロダクトオーナーに認識させることができます。特に、許容基準は完全には理解されていないこと。これは、プロダクトオーナーとの必要な会話を引き起こす可能性があります。理想的には、これに来てはいけません。これは、遡及で議論し、解決する必要があります。