見積もりの意見の相違への対処法

見積もりの意見の相違への対処

見積もり中の意見の相違は健全です。隠れた仮定、リスク、知識のギャップを表面化させます。目標は意見の相違をなくすことではなく、生産的に解決することです。

見積もりが乖離する理由

1. 異なる仮定 -- ある人は既存のAPIが機能すると仮定。別の人はまず修正が必要なバグがあることを知っている。
2. 異なる経験 -- シニア開発者はこのタイプの問題を以前解決しており簡単と見る。新しい開発者は多くの未知を見る。
3. スコープの曖昧さ -- ストーリーが十分曖昧で、人々が異なる実装を想像している。
4. リスク認識 -- ある人は直線的なタスクを見る。別の人は壊れやすい依存関係を見る。

解決テクニック

2分ルール

公開後、最高と最低の見積もりを出した人にそれぞれ正確に2分間、理由を説明させる。中断なし。その後再投票。

明確化の質問

多くの場合、1つの質問がギャップを解決する：

• 「APIが既に存在すると仮定していますか？」
• 「これはモバイルも含みますか、それともWebだけですか？」
• 「エラー処理はスコープ内ですか？」

高い方にデフォルト

2ラウンド後にチームが収束できない場合、高い方の見積もりを採用。過小見積もりは過大見積もりよりダメージが大きい。スプリントコミットメントの不履行につながるため。

ストーリーを分割

広い範囲（例：3 vs 13）が続く場合、ストーリーはおそらく大きすぎるか曖昧すぎる。より小さなピースに分割してそれぞれを見積もる。

やってはいけないこと

• 平均を取らない -- プランニングポーカーは算術ではなくコンセンサスについて。3と13の平均8は誰も満足させず、誰の理解も反映しない。
• オーバーライドしない -- チームが8と言い、テックリードが3と言う場合、チームの見積もりが優先。オーバーライドは信頼を破壊する。
• 恥をかかせない -- 「それはばかげた見積もりだ」は正直な評価を封じ込める。すべての見積もりには理由がある。それを見つける。

ファシリテーションのヒント

• チームが最初の投票で収束する頻度と再投票が必要な頻度を追跡。再投票が稀な場合、ストーリーが十分に精査されていない可能性。
• 同じ2人が常に意見が合わない場合、ストーリーでペアにする。時間とともに校正される。