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