ウォーターフォールからアジャイルへの移行はまだ始まったばかりです。私たちの新しいプロセスに関する数少ない不満の 1 つは、イテレーション計画会議に時間がかかりすぎるということです。これは主に、会議自体でストーリー カードを作成しているためです。
提案の 1 つは、会議の前にストーリー カードを作成し、全員に会議に来る前に確認するように依頼することで、時間を節約できる可能性があるというものでした。
事前にストーリー カードを作成し、前もってレビューするように依頼するのと比較して、ミーティング中にストーリーを作成することに利点はありますか?
本当の決定的な答えがないので、これはおそらく尋ねるのに理想的な質問ではありません。応答は主観的である可能性があります。
私自身の経験に関連して、私たちのチームは、プロジェクトの製品バックログへのスプリント中に、利害関係者と製品所有者にアドホックな方法でユーザーストーリーを追加させる傾向があります（私たちはWebアプリケーションに取り組んでおり、機能の面でユーザー主導です-私たちは持っていますロードマップですが、フィードバックなどにも適応します）。
そうすることで、イテレーション計画を行うときに、利害関係者、製品所有者、およびプロジェクトリードとの簡単な製品計画会議を行い、優先順位について話し合い、製品バックログのユーザーストーリーを調整します。
それが完了すると、スプリントで作業するためにユーザーストーリーを引き抜くプロジェクトチームとのその後のスプリント計画セッションがあります（確立された速度に対して測定したときに現実的に達成できると感じる十分なユーザーストーリーを選び出します）。
他の人はそれを違ったやり方でやっていると確信しています。重要なことはあなたとあなたのチームのために働く何かを見つけることです。
プロセスが私に説明された方法でした
プロセスの問題 (計画会議が長すぎる) を特定し、その根本原因 (ストーリー カードの作成) を見つけました。最も賢明で機敏に行うべきことは、おそらく「プロセスがどのように記述されたか」に固執するのではなく、それに応じて適応することです。つまり、事前にカードを作成することを意味します。
とはいえ、私の個人的な経験から言えば、プロダクト オーナーがチームにユーザー ストーリーを提示するのが早ければ早いほどよいのです。スプリント計画はおそらく、ストーリーの見積もりが洗練され、詳細がほとんど取り組まれていないときですが、チームが事前に少なくともいくつかの調査と見積もりを行い、完全に無知で会議に到着しない方が一般的には良いでしょう.
ユーザー ストーリーの最も重要な目的の 1 つは、開発者と利害関係者の間で会話のきっかけを提供することです。私の経験に基づくと、1 人か 2 人の人が既存の要件や要求をすべて確認し、それらをユーザー ストーリーに変換することで、多くの時間を節約できます。
しかし、ストーリー カードについて話し合うことは非常に重要であり、それにはかなりの時間がかかるはずです。開発により多くの時間を費やすことができるように思えますが、現実には、議論がなければ、開発は簡単に間違った方向に進んでしまいます。会議の前にカードを確認するように人々に依頼しても、うまくいかないことがよくあります。会議中にカードについて話し合う時間を取りたくない場合、おそらく自分の時間にカードを確認することはありません。
私のアドバイス: 会議の前に 2 人に協力してユーザー ストーリーを書いてもらいますが、会議を利用して各カードを確認し、話し合います。