タイミングは、各チームメンバーがスクラムでストーリーに費やす正確な時間ですか？
私の同僚の1人が、各チームメンバーが各ユーザーストーリーに費やす時間のタイミングを提案しました。これは、反復中の開発チームを混乱させ、将来の計画会議でのストーリー推定の指標として誤解を招く可能性があるように思われます。
そのようなシステムの経験があり、それがどれほど有用または破壊的であるかについて考えている人はいますか？
ストーリーを実装するのにかかった時間をある程度測定するだけで、最初の見積もりと比較できます。この情報があれば、次回はより適切な見積もりを行うことができます。
たとえば、この反復では、ストーリーAに2日、ストーリーBに4日かかると決定します。ただし、実際には両方とも3日かかります。次に、次の反復で、残りのストーリーをもう一度見て、この情報に基づいてそれらを再推定できます。 「A」のようなストーリーが多い場合は、より多くの時間が必要になります（または、より少なくなります）が、「B」のようなより多くのストーリーがある場合は、より少ない時間（またはより多くのことを行う）が必要になります。
チーム内の個人に対して時間を記録するのではなく、ストーリーに対して時間を記録する必要があります。いつでもログに記録するべきではないと言う人もいますが、完全に思い出せる開発者がいない限り、将来のタスクの見積もりは歪められます。数値があると、（ある程度）見積もりを正規化できます。
スクラムでは、すべての努力が楽しみに集中しています。したがって、実績には本質的な価値はありません。実績について役立つのは、それらを使用して、チームが見積もりを行う方法を改善することです。
それでも、個々の見積もりが実際に対してどのように公正化されているかを詳細に分析することはほとんど価値がありません。実際問題として、ほとんどのチームは、見積もりの正確さを維持し、それに応じてスプリントバックログを作成することを学びます。
たとえば、チームが習慣的にタスクを過大評価していると仮定しましょう。彼らは、2週間のスプリント（5 * 6（10営業日の60％の使用率を想定））で5人のチームに30人日の労力を計画し、すべてが4日目までに完了することを発見しました。スプリントは、「まあ、私たちは多くの時間を残して30日間の見積もりを完了することができたので、次のスプリントに60（見積もり）の人日タスクを入れて、何が起こるか見てみましょう」と言います。時間の経過とともに、彼らは自分たちの見積もりがスプリントで実行できる作業量にどのように関連するかを学びます。見積もりが一貫している限り、見積もりがどれほど悪いかは問題ではありません。
ふりかえりは、チームが座って見積もりを確認し、正確さをどのように処理するか（または処理しないか）を確認する場所です。ただし、唯一の重要な要素は、次のスプリントに投入するタスクの適切な量を把握していることです。
私は最初のスクラムプロジェクトでそれを行いました。それは何の価値も提供しませんでした。この手法は、その知識を次の見積もりに再利用する場合にのみ意味がありますが、そのような場合は、不可能な非常に低い（タスク）粒度で数時間で見積もりを行う必要があります。
私たちは自分たちのプロジェクトでそれを行います。彼らは数字でいっぱいのスプレッドシートを持っているので、マネージャーはそれを愛しています。それが実際にプロジェクトの実行を改善するのに役立つという証拠は見たことがありません。
ユーザーストーリーに費やす時間を測定したい理由を彼に尋ねる必要があります。
私が見る唯一の正当な理由は、生産性をチェックすることです。彼が本当にそのように生産性を個別に計算したいのであれば、スクラムの使用をやめなければなりません。
スクラムはチーム中心であり、個人中心ではありません。そのために動作します。
私は2つの用途しか想像できません：
1）各ストーリーにある種のストーリーポイントまたは複雑さのポイントを保持すると、各複雑さのポイントに必要なある種の平均または時間の範囲を取得できます。これは、将来のタスクを見積もるのに役立つ可能性があります。
2）すべてのempoyeese予測の成功を計算できます：タスクについて予測した時間と、これを完了するのに実際にかかった時間。それがプロセスをどのように改善するかはわかりませんが、評価中の報酬/ペナルティポイントとして使用できます。