チーム間でストーリーポイントを正規化しますが、大きな問題はありますか？
私たちは製品のサイズ/努力を少なくとも大雑把に比較することを考えていました、そしてこれはいくつかが示唆したものです：
- 複数の製品があり、それぞれに1つのスクラムチームがあります
- すべてのスクラムチームは、共通のリファレンスストーリーと比較してストーリーを推定します。したがって、たとえばプロジェクトAでは、彼らは自分のストーリーを見て、リファレンスストーリーの2倍の労力が必要であると見積もっています。
- 結局、すべてのプロジェクトはこのリファレンスストーリーに関連して推定され、予想される労力の点である程度比較可能です。1つのプロジェクトに200 SPと他の400 SPがある場合、それは予想できます。だいたい2倍のWORKです。
- 個々のチームには独自の速度がありますが、生産性はもちろん異なるため、誰もそれを比較することはできません。
アナロジー：穴を掘るとき、深さ10メートルの穴は、基準穴（深さ1メートル）の10倍の作業になると言えます。 1つのチームが掘削機を使用し、10メートルの深さの穴を30分で掘ります。もう一方のチームはスペードを使用して、深さ1メートルの穴を掘るのに2時間費やします。ただし、生産性に関係なく、実行される作業量は同じであり、比較できます（1対10）。確かに、SWは推定するのは簡単ではありませんが、完全にオフにするべきではありません。
それで問題はありますか？チームは自分の作業を共通のリファレンスストーリーと比較し、それに関連するポイントを割り当てるだけでよいので、私には問題ないように見えます（独自のリファレンスストーリーを使用して推定する場合と同様）。チームAがストーリーポイントを完了するのに1日かかり、チームBが2日かかる場合、見積もりが一貫していることは問題ありません。
私はいくつかのチームでこのアプローチを試しましたが、チーム間の効率にはつながりません。私たちは常に、誰もが理解しているリファレンスストーリーを基礎として使用しました。これは、私たちが知っていることが、そのリファレンスストーリーよりもさらに小さいことを確認するために、1以外の値（この場合は2）を持っているため、 1。
コンセプトチームが推定室に運ばれるとすぐに崩壊しますであり、参照ストーリーよりも大きなものは何かを言う必要があります。一部のチームは、何らかの理由で参照ストーリーの4倍と見なすチームもあれば、参照ストーリーの2倍と推定するチームもあります。 ストーリーポイントは時間ではないなので、どちらも正しいです。
チームがサイジングに一貫性があるである限り、チームの見積もりは有効であり、チームは速度から予測を達成できます。しかし、チーム間での比較は機能しません。チームAは、参照からより大きな増分を定期的に使用して、常にスプリントでより多くのストーリーポイントを達成しているように見えます。チームBは実際には異なるスケールで推定しているだけで、「パフォーマンスが低い」と評価されます。
これは、約3週間の休暇を取ったときにさらに明確になり、「より高い」見積もりを持つ他のチームを率いるチームリーダーが私の不在時に2回の見積もりラウンドを行うことができました。私が戻ったとき、私たちの速度は突然劇的に跳ね上がり、チームのすべてのストーリーポイントははるかに高くなりましたが、実際にはこれ以上の作業は完了していませんでした。
（これはまた、私がチームが行った見積もりのサイズに不均一な影響を与えたことを指摘しました）
結論として、リファレンスストーリーを使用すると非常に役立ちます。組織は見積もりプロセスを理解でき、誰もが標準化しているように感じます。ただし、それを超えて、同じ人がすべての見積もりを行い、方程式からチームを削除するでない限り、チーム全体で見積もりサイズがどのように調整されるかは信頼できません。
これは悪い考えです。ストーリーポイントで推定する全体のポイントは、時間やチーム間で直接比較できない抽象的な単位を持つことです。チーム間でストーリーポイントのサイズを同じにしようとしても、有益な情報は得られません。実際の比較を行うには、適度に正確な速度とストーリーの合計ポイントが必要です。チームAが200ポイントのプロジェクトを見積もっても、必ずしもチームBが400ポイントのストーリーを見積もるよりも小さいというわけではない場合、意味のあるものを得るために速度も必要です。比較。チームAが4つのスプリントを、チームBが5つのスプリントを実行している可能性があります。似たものにしようとすればするほど、より多くの比較が行われます。複数のチーム環境で最低速度のチームにならないように、常に微妙なプレッシャーが存在します。チーム間でストーリーポイントを一致させようとすることで、そのプレッシャーがより顕著になります。
これについて私が最初に疑問に思うことは、これを行うことで何を得たいですか？
プロジェクトの相対的なサイズを把握しようとしていますか？まあ、私はこれがあまり役に立たないと思います（何かが大きいか小さいかについて非常に大まかな推測を与えることを除いて）。ストーリーポイントは、その性質上、推定した人にのみ適用されます。
それを説明するストーリータイム。私が取り組んだ1つのプロジェクトは、ほとんどがCRUDページであるWebサイトでしたが、非常に複雑なインターフェイスが1つありました。このプロジェクトは古いメインフレームアプリの代替となるはずでしたが、迅速なキーボード入力を処理できるという点で、メインページに古いシステムを模倣させる必要がありました。そして、このページにはたくさんの可動部分があり、1つの入力を変更すると他の多くのフィールドが有効または無効になり、検証要件が変更され、ページの一部が非表示または表示される場合があります。
私たちは、UIを処理するために主にフロントエンド関連の作業を行う1人のジュニア開発者と私がいました。ジュニア開発者は、HTML、CSS、およびいくつかの基本的なjQueryを処理できます。もし彼女がそれが彼女に取るであろう努力を見積もっていたら、それは100以上のストーリーポイントだっただろう。
私はこの時点で上級開発者だったので、そのページにAngularを使用することを提案しました。また、合計30点程度で作業を推定しました。ジュニア開発者、私たちは他の場合よりも少ない労力でより良いUIになりました。
その話の要点は、努力は仕事をしている人々に大きく依存するということです。経験豊富なチームは、優れた設計を考えたり、作業を高速化したり、問題を減らしたりすることができます。これの一部はチームの速度に飲み込まれ、一部は飲み込まれません。
あなたが何を得ようとしているのかに戻って。チームの仕組みとチームの優秀さを比較しようとしていますか？あなたがそれを望んでいるかどうかに関わらず、あなたはそれを手に入れると確信しているからです。
ストーリーポイントがチームに関連している場合、チームを正当に比較できるのはそれ自体だけです。特定のチームの速度の増加、より正確な推定などを追跡できます。しかし、「チームAは2週間のスプリントで50ポイントを獲得し、チームBは30ポイントしか獲得しません。なぜチームBはそれほどスラックしないのですか？」とは言えません。これを試みても、1チームAポイント=/= 1チームBポイント（および他の引数の束全体）を覚えておけば、即座にシャットダウンできます。しかし、1ポイントはチーム全体で1ポイントであると言う方法が決まったら、直接比較することは避けられません。人々が意識的にそれらの比較をしたいかどうかにかかわらず、それらは起こります。そして、どこかのマネージャーが同じことをすることを約束し、それを使ってチームが「パフォーマンス不足」であることを宣言することができます。
私はここで何かを見逃しているかもしれませんが、私が見ることができるのは、これがほとんど利益がなく、多くの潜在的な欠点があることです。要するに、それをしないでください。