推定値はどの程度一貫性があると期待できますか？
私は最近、2つのスクラムチームの見積もりに関するいくつかの統計を行いました。
これらのグラフは、「実際の消費時間」に対する「元の推定」をプロットします（ロギング時間spentは、スクラムの意味で、計画）。
推定履歴（対数目盛）
推定履歴（線形目盛）
結果としての努力は、元の推定値とほとんど相関がないように思えます。もちろん、予想されるオーバーラップがあり、おそらく隣接する推定値のみがオーバーラップしている可能性がありますが、1-2-3allが非常に低い位置にあるのは意味がないと思いますエンドおよびハイエンド。
5│ ══════════════
3│ ═════════
2│ ══════
1│════
└───────────────────────────
My expectation: Partially overlapping estimates
もちろん、見積もりは大雑把で、時々物事が爆発しますが、私にはこのデータは悲鳴を上げます "見積もりで吸います"これはある程度妥当ですが、データはここに表示されるのは理由をはるかに超えています。見積もりのためのより良い文化を生み出すために、チームと「見積もりワークショップ」を作成したいのですが、それについての妥当なリファレンスフレームがあることを確認したいと思います。そう...
見積もりはどの程度一貫性があると期待できますか？「期待される」グラフは非現実的ですか？では、何をすべきでしょうか
編集：はい、受け入れ基準と「完了の定義」（テスト、レビューなどを含む）がありますが、ポリシングが不十分な場合があります。私たちのプランニングポーカーは通常、隣接するサイズのカードを表示します（大きなギャップはありません）が、それでもギャップは合意された結果と実際のサイズの間にあります。
対数スケールでは非表示になっていますが、実際の数値は予想どおりの分布であるように見えます。密度を示すプロットを使用すると、より直感的になります。バイオリンのプロット。ボックスプロットを使用すると、データからは明らかではないいくつかの要約統計をすばやく提供できます。
中央値は「1-SPストーリーの50％がX時間以内に完了した」と表示されるため、中央値を比較する方が最小/最大値を比較するよりも優れている場合があります。タスク推定では、両方向に外れ値があることが予想されます。一部のタスクは予想よりもはるかに簡単です（バグ修正のためにときどき発生します）。かなり多くのタスクが予想よりもはるかに長くかかります。
しかし、はい、高い分散は奇妙に見えます。ただし、これはそれらのチームがSPをどのように使用するかによって異なります。例えば。チームがSPを使用してタスクをランク付け作業量（序数スケール）に従ってタスクを（通常のスケール）場合、それを期間として再解釈しようとするのは無意味/無効です（間隔スケール）。 （参照： 統計データタイプ 。）分析は、SPが間隔スケールでもある場合に有効です。つまり、3つの1-SPタスクは、1つの3-SPタスクと同じくらいの労力であると予想されます。
SPの実行を停止し、{½日、1日、2日、週}の増分で推定を開始することを検討します。はい、はい、これは非スクラムと悪です。ただし、フィードバックサイクルを形成できます。振り返ってみると、チームは完成したストーリーを調べ、推定値と使用時間を比較できます。その後、チームは、予想外の問題が発生したこと、およびそれらをどのように回避または将来解決することができるかについて話し合うことができます。期待を現実と比較するこの単純な行為は、もちろんチームがより良い見積もりを作成することに関心があります。
TL; DR：
- はい、分散は少し極端です
- チームは振り返り中に（推定）プロセスを改善するように努めるべきであり、リアルタイムの推定を使用して
- いいえ、見積もりワークショップはそれを支援する可能性は低いです
- 統計を行う場合は、もう少し慎重に行ってください
これで、見積もり自体の精度のみを確認できます。私の経験では、この不正確さは、ユーザー自身の推定ではなく、ユーザーストーリーが原因であることがよくあります。
ここで考慮すべきいくつかのこと
- ストーリー自体で定義されているよりも多くの作業がユーザーストーリーに対して行われます（いくつかの追加のぶら下がり果物機能）。
- 受け入れ基準は明確に定義されていません。合格基準は明確でテスト可能でなければなりません。つまり、レディの定義はありますか？
- 完了の定義はありません。 DoDにコードレビュー、テストの記述、リファクタリング、コードのクリーンアップを含めますか？それも見積もりに含まれていますか？
「これとこれを一覧表示するウィンドウを作成する」などのユーザーストーリーを見つけることがあります。誰もが何を意味するのか知っているので、なぜそれをさらに定義するのですか？まあ、それは漠然としていて、人々は異なることをするでしょう。 planspokerの実行中にチームメンバーからの推定値が離れている場合、これはユーザーストーリーが適切に定義されていないことを示す良い兆候です（常にではない）。
役立つと思われるのは、過去数回のスプリントからのユーザーストーリーのリストを保持することです。チームは、見積もりは大丈夫だと考えています。計画会議の開始時にそのリストを表示し、ベースラインがあり、新しいユーザーストーリーをそれらと比較できるようにします。
複雑さ（ストーリーポイントが想定されているもの）とストーリーに費やされた時間は、常に相関しているとは限りません。実装に時間がかかる非常に単純な変更や、これらの実装に比較的時間がかからない複雑な変更は、時間の経過とともに互いにバランスが取れている可能性があり、あなたの例ではそのように思われます。 10時間未満だった場合は、より長い1の数を補います。
チームでより一貫した見積もりを取得するためにできることがいくつかあります。以前のストーリーを取り上げて、Xポイントストーリーの標準的な例として使用できます。 Xを完全に推定するよりも、ストーリーXがYまたはZに近いかどうかを推定する方が一般に簡単なので、これは便利です。もう1つ私に突き出ているのは、すべてのポイントのストーリーに費やされた時間が非常に長いように思われるということです。完了までに40時間以上かかる3つ以下のポイントストーリーがいくつかあるようですが、これは何かが正しくないことを示す良い兆候だと思います。これを調査するために少し時間をかけると、不十分な要件、スコープのクリープ、人々がすぐに助けを得られない、外部チームへの依存、ストーリーを十分に分解しない、ストーリーが拒否される多くのバグがある場合に、より良いアイデアを得ることができます複数回、または何か他のもの。