プロジェクトの最初にポーカーの計画を立てる方法が好きです。各ストーリーの詳細を互いに比較して話し合うことができます。
私がこれで気付いた問題の1つは、時間の経過とともに問題ドメインでより多くの経験を積むにつれて、各ストーリー（つまり、最初は5または8の価値があったストーリー）に投票するポイントが少なくなるということですプロジェクトの今の価値があるかもしれません3。
この問題を可能な限り最善の方法で回避または対処するにはどうすればよいですか？推定するより良い方法はありますか？ストーリーは常に同じである必要がありますか、それともこのストーリーポイントは減少しますか？
回答:
それは大きな問題ではないと思います。
それを引き起こしている可能性のある2つの明白なものがあります。1つは、穏やかなポイントのデフレが発生していることです。もう1つは、チームが実際に速くなっていることです。（後者だといいのですが！）
いずれにせよ、それは大したことではありません。速度の2つの主な用途は、次の反復でどれだけの作業を行うかを把握することと、より大きな作業のチャンクの納期を大まかに見積もることです。どちらも、速度が徐々に変化しても害はありません。確かに、ベロシティの改善が改善の結果である場合、新しい数値はチームの能力をより正確に示しています。
速度が速すぎて快適ではない場合、1つの応答は標準的なストーリーです。過去2か月間を経て、使用するポイントレベルを表す3つのストーリーをそれぞれ選びます。見積もりを行う壁に立てかけてください。次に、見積もりとして、扱っているストーリーとの比較として使用します。これにより、見積もりのドリフトとボラティリティの両方が減少します。
基本的に、これはそれほど大きな問題ではありません。これらの問題のほとんどはすぐに出てきます。概して、推定の出力の明示的な操作は、プロセスにとってネガティブになります。ストーリーポイントの推定は、チームがボールを注視しているときに最も効果的です。ストーリーと他のストーリーの相対的な複雑さを推定し、完成したストーリーの履歴情報が手元にある限り、問題が解決するのを見るでしょう。長期的には。チームが結束してメリットを享受できる場所はここにあります。チームは最終的に方法を決定し、ストーリー推定のためのストーリーを参照します。
ストーリーポイントのデフレは軽度の問題になる可能性がありますが、ポイントの範囲の見積もりが圧縮されると、速度の微調整に関する情報が失われ始め、その圧縮により、長期リリースの配信の長さを見積もる際に悪影響が生じる可能性があります。計画（すべてのストーリーを狭い範囲に圧縮することで発生するエラーを乗算するため）概して、専門知識によるベロシティの増加の結果は、見積もりが下がるのではなく、より多くのストーリーポイントを取るように表現されることを望みます。これに対処する方法は、以前に完了した見積もりを継続的に参照し、常に複雑さを見積もりていることを確認することです。何か時間がかかると思う時間を明記せず、ストーリーの全体的な難易度を以前のストーリーと比較してください。しましょう たとえば、モバイルプラットフォームをサポートするアプリがあり、別のアプリに移植する必要があるとします。以前のポートと似ていますか？より難しい、プラットフォームがより悪いツールを持っているので？あなたはより良いデバッガを持っているので、もっと簡単ですか？これは、チームに見積もりが上手くなったためにこの移植がより速くなる可能性が高いという事実ではなく、見積もりを通知するはずです。複雑さに集中することは、問題がある限り、この問題の解決に役立つはずです。