ユーザーストーリーを推定する際に、マンデイではなくストーリーポイントを使用するのはなぜですか？

アジャイル手法（SCRUMなど）では、ユーザーストーリーに必要な複雑さ/労力はストーリーポイントで測定されます。ストーリーポイントは、チームが反復で取得できるユーザーストーリーの数を計算するために使用されます。

推定工数のように、具体的な測定値を使用できる抽象的な概念（ストーリーポイント）を導入する利点は何ですか？推定工数を使用して、速度を計算したり、反復のカバレッジを推定したりすることもできます。

対照的に、ストーリーポイントは使用するのが難しく（概念が抽象的であるため）、関係者に説明するのも困難です。どのような利点がありますか？

主な利点の1つは、人間と開発者が特に時間を見積もるのがかなり悪いということです。開発の性質も考えてみてください。最初から最後まで直線的に進行するわけではありません。多くの場合、「10分間でコードの90％を記述してから、17時間であなたの髪を引き裂きます」。これは、クロックタイミングの観点から推定するのはかなり困難です。

ただし、抽象化を使用すると、実際の時間や時間を数時間または数日から外し、代わりに、他のタスクと比較したタスクの相対的な費用と複雑さの説明に焦点を当てます。人間/開発者の方が優れています。そして、それらのポイントの推定値と実際の進捗状況をハミングしたら、経験的に時間を調べ始めることができます。

私は、ポイント推定では発生しないであろう時間推定で発生するオブザーバー効果もあると考えています。たとえば、ポイントをベースにしたシステムでは、「スケジュールよりも先に」見積もりを実行し、方法を提供するインセンティブは、インダイレクションによってミュートされます。

フィボナッチ数（または同様のもの）を使用している場合、ストーリーを推定する際のオプションの数が制限されます。私は1、2、3、5、8、13という低い数字のみを使用したグループと協力しました。5の参照ストーリーがありました。これにより、Planning Pokerをしながら、ストーリーの複雑さを簡単に簡単に決定できました。 。もう1つの副作用は、13と評価されたものはおそらく情報が不十分であり、さらに分類する必要があるということです。私たちが生の時間を使っていたら、こんなに簡単で簡単だったことは真剣に疑っています。

プロダクトオーナーは、利害関係者の言語を話し、必要に応じてストーリーポイントと工数（または他のユニット）の間で翻訳できる必要があります。POの期間中、1ストーリーポイント= 4工数というハードデータがありましたが、明らかにすべてのチームは異なります。

編集：

1ポイント= 4時間という知識があれば、理論的にはプランニングポーカーデッキを4、8、12、20、32、および52に変更できます。しかし、これらの数字を扱うのは難しく感じます。「1日未満」、「1週間以上」など、単純に値を精神的に抽象化すると思います。そして、それを行う場合は、抽象単位に固執することもできます。 -ストーリーポイントが少ない。

推定者全員が推定値を調整することなく、推定値が時間とともに改善されるようにするためです。

見積もりに関与する全員が「OK .. 2人日みたいに見えますが、最後のスプリントはすべてを過小評価していたので、実際には2.5人日か3人か？」と考える必要がなく、いつものように続きます。「5ストーリーポイント！」

次に、以前のスプリントで実際に測定された達成度に基づいて、スプリントでチームが獲得できるストーリーポイントの推定値を調整します。「以前はスプリントごとに90〜110のストーリーポイントを処理してきました！」

これの背後にある理論は、開発者が絶対的なものを推定するよりも異なる開発者のタスクの相対的な複雑さを推定することに優れていると言うでしょう。特に、複数の人がいずれか1人で実行できるタスクを見積もっている場合（そして誰もが他の人と同じ速度で作業するわけではありません）。

シニカル代替案：開発者が時間の見積もりを下回らないことを言ったことがあります。予想よりも長い時間がかかった場合、あなたは行き​​ました。しかし、何かが予想よりも時間がかからない場合、開発者はそれをいじったり、金版を作成したり、やっかいな割り当てを与えられているので、ゆっくりと簡単に実行することができます。推定から実際の時間単位を取り除いて、これらの傾向を抑えることができます。シニカル代替を終了します。

あなたが具体的に言うように、人の日または人の時間です。そのため、タスクが5時間と推定され、6時間かかる場合、現在は遅いタスクです。

3ポイントのストーリーがあり、6時間かかる場合、6時間かかりました。遅くはなく、たった6時間かかりました。速度測定は、スプリントでそれらのポイントをいくつ取得するかの要因であり、その数は具体的ではないため変動する可能性があります。また、各タスクを測定するのではなく、すべてのタスクの合計を測定します。各タスクに数時間ある場合、各タスクを測定する誘惑があります。それが起こると、その時間内にフィニッシュしてもスプリントには何のメリットもありませんし、与えられたタスクの時間をかけてフィニッシュすることの結果です。

それは、ポイントの観点から考えることへの移行になる可能性があります。努力のレベルについてのアイデアを得るためだけに、アジャイルな使用済みTシャツのサイズを導入する前に私が働いていた1つの場所。ポイントはその延長です。

それは論争やポイントへの何らかのarbitrary意的な割り当てがないと言っているわけではありません。私たちのチームには、ほとんどの場合最も低い数の票を投じるメンバーがいて、タスクが1であり、ポイントインフレーションに苦しんでいるのは3であると考えると文句を言います。

抽象化は一種のポイントです。「マンデー」を測定値として使用すると、次のような落とし穴があります。

1. チームが使用する技術に精通していない場合、タスクにかかる時間をリアルタイムで見積もることは非常に困難です。彼らは良い相対的な推定値を与えることができる可能性がはるかに高い-例えば「タスクAはおそらくタスクBの2倍の時間がかかる」。
2. 異なる人々は異なるレートで働いています！「man days」を使用する場合、タスクが開発者から別の開発者に渡されるときの時間の見積もりを変更する必要があります。とにかく、どのくらいの作業が「マンデー」を構成するかを誰が定義しますか？

工数を見積もる場合は、簡単な計算です：

user points in story / average user points per developer per day = estimated man days

既に述べたように、ストーリーポイントは複雑さの相対的な尺度です。推定には、2のべき乗（1,2,4,8,16 ...）またはフィボナッチスケール（1,2,3,5,8,13,20 ...）を使用できます。支持されている開発者は次のようなことを言うのが得意です。

機能Aは機能Bのほぼ2倍の強度です

しかし、この機能を実装するのに「どれくらい」かかるかを言うのは本当に難しいです。それを速度でバランスさせます。したがって、何かが5であると推定されたが、13であることが判明した場合、速度を遅くすると、反復の速度が正規化されます（または再推定できます）。

今、別の選択肢があり、それは「理想的な日」と呼ばれます（いくつかは人の日に似ていますが、それがあなたが意図したものであるかどうかはわかりません）そして私はそれを好むかなりのチームを知っています。理想的な日は次のように解釈されます：

それが私がオフィスに来てから必要な休憩だけを取り、中断せずに、「ストーリーを実装する」ために必要なすべてを持っている場合、つまり会議、メールへの応答などの周辺活動がない場合、

多くの有名なアジャイル伝道者の一人であるマイク・コーンは、物語のポイントと理想の日々との以下の比較を提供します

ストーリーポイント

• クロスファンクショナルな振る舞いを促進します。つまり、チームはUIからDBに至るまでの実装の複雑さからストーリーを推定します。
• SPの見積もりは衰えません。つまり、数か月後には5ポイントのストーリーは5ポイントになる可能性が高いですが、理想的な1日の見積もりは、特定のプログラマーの獲得した開発スキル/スピードによって変わる可能性があります
• SPはサイズの純粋な尺度です。つまり、サイズのみであり、複雑さを反映したサイズのみを反映しています。期間。期間などはありません。それが速度の仕事です。しかし、理想的な日ではそうではありません。実際、理想的な日では、暦日と混同する傾向があります。SPを抽象のままにしておくと、現実と比較する誘惑と戦うことができます。サイズの目安です。ナンセンスなし。
• 通常、理想的な日よりも高速です。最初の2、3の話では注意が必要かもしれませんが、いったん理解してしまえば、より速くなります。
• 開発者が異なれば、ストーリーを完成させるための理想的な1日の見積もりを異なるものにすることができます。3でも同じことができ、5でもできます。SPは全体的にほぼ均一です。彼らはいわば競技場を平準化します。

理想の日々

• チームの外で説明しやすい。明らかな理由で:)
• 上記のように、最初は簡単に推定できます。しかし、SPのコツをつかめば自然に

さて、どちらを選ぶかはチーム次第です。ただし、ここでのほとんどの答えと私の個人的な経験として、私はストーリーポイントを好みます。理想的な日々には、SPに対してそれほど多くの利点はありません（そして、Mike Cohnは、他の多くのアジャイルエバンジェリストと一緒にSPも提唱しています）。

ストーリーポイントは、チームのパフォーマンスの改善を長期にわたって測定するのにも役立ちます。さらに、パフォーマンスが向上しても、すべてを再評価する必要はありません。

マンデイを使用する次の例をご覧ください。

チームは、さまざまなタスクを工数で見積もります。しばらくは動作しますが、しばらくすると、当初考えられていたよりも多くのタスクでチームがより速く処理されることがわかります。したがって、チームはタスクを再評価します。しばらくは機能しますが、しばらくすると再び同じことがわかります。チームは再び多くのタスクでより速く処理されます。だから、あなたは再び再評価し、この物語は何度も何度も繰り返されます...

どうして？チームのパフォーマンスが向上したため。しかし、あなたはそれについて知りません。

ストーリーポイントを使用した同じ例：

チームは、ユーザーストーリーのサイズを推定します。いくつかのスプリントの後、チームはスプリントごとに約60ストーリーポイントを実行できることがわかります。後で、チームは60を超えるストーリーポイント（おそらく70）を達成したことがわかります。そして、チームはそのように継続し、次のスプリントのためにより多くのユーザーストーリーを引き出して配信します。

どうして？そのため、パフォーマンスが増加しています。そして、あなたはそれを測定することができます。また、チームのパフォーマンスが向上した後、すべてを再評価する必要はありません。

まず、人々は絶対的な推定よりも相対的な推定の方が優れています。星の相対的な明るさをマッピングして評価するバビロニア人は、良い例です。絶対的な数値は正しくありませんでしたが、非常に似た強度であっても順序はほとんど一致していました。

2番目の利点は、この演習を行う主な理由が会話を促進することであることです。正確な日に議論を開始すると、会話がすぐに混乱する可能性があります。

ナポレオンが言ったように、計画は価値がなく、計画は非常に貴重です。

第三に、プロジェクトマネージャーはすべての見積もりを編集する必要はありません。見積もりがたとえば130％ほどずれていたことが判明したからです。

ストーリーポイントは問題の複雑さを反映しているため、推定の正確さの信頼性（またはリスク）を反映しています。

ストーリーポイントが高いストーリーは、具体的ではないユーザーストーリーで多くのことが行われていることを示しています。

アイデアは、さまざまなストーリーポイントの適切なバランスを確認することです。すべてのストーリーポイントが高いストーリーを含む反復計画が表示されている場合、これにより、反復が期待どおりに実行され、反復のために他のストーリーを確認するか、ストーリーを分解する必要があるという確信がほとんど得られません。

マネージャーまたはプロダクトオーナーとコミュニケーションをとる場合、ストーリーポイントが高いということは、特定の機能をいつ入手できるかが非常に曖昧であることを意味します。これに対する解決策の1つは、ストーリーを分解することです。うまくいけば、プロダクトオーナーに進捗状況を繰り返し示すことができるように、ストーリーのポイントを組み合わせることでうまくいきます。

人の日は何かをするのにかかる時間を見積もる。推定するアイテムが非常に正確で測定可能な場合に最も適しています。特定の、よく知られた、反復可能なタスクは、人の数日で推定できます。

たとえば、営業担当者が1日に平均20のカスタマーコールを発信できる場合、各コールにかかる時間を計算し、それから1000コールを発信するのに何日かかるかを見積もることができます。

この例では、すべてのコールが事実上同じものであると想定できるため、コールの長さの中央値について統計的に具体的に考えることができます。

ストーリーポイントにより、反復で実行できるストーリーの組み合わせが決まります。それらは、異種の目標をあいまいな境界と組み合わせ、一定の時間枠内で何回実行できるかを測定するために使用されます。彼らは、それらを一緒に追加できるように、互いに比較した作業のチャンクの複雑さを推定します。

たとえば、チームはイテレーション1で合計23ポイントの5ストーリー、およびイテレーション2で20ポイントの8ストーリーを開発しました。繰り返し3。

1ポイントのサイズを決定する必要はありません。特に、同じサイズの各ストーリーの開発に同じ時間がかかるという仮定はありません。合計と反復ごとのポイントのみに取り組みます。繰り返しの長さについては言及しませんでした。

路上で人間まで歩いて「T-レックスはどれくらい大きかった？」と尋ねた場合 ほとんどの人間はT-rexが何であるか、それがどのくらい大きいかを知っていても、答えは変動しますが、ベースラインとの相対的なスケールがないため、誰も確かに知りません。

それが、予測で把握しようとしている認知行動であり、多くの方法論が「私はそれを持っている！.. iは正確な予測の秘密を持っている！」というヘビーオイルでサイクルを回します。実際に予測を行うと、「x日/時間/ポイントで完了できるように許可します」という意味で大声で言っています。つまり、そのイベントが実行される「タイムボックス」を作成するという意味です。

私にとって、Pointsは境界線を変更しているだけです。1日の終わりに「*スプリントごとに3週間あり、親指を吸う ...」そのサイクルで完了するための30ポイント！誰が私と一緒にいる！* "そして、あなたが予測モデリングに行くのと同じくらい深い-素晴らしい！..現実的には、任意の予算を設定しているだけなので、それだけです。また、「聖なるがらくた、私たちはスプリントする33pts、かなりクールだった」という感覚で完成した作品を振り返って振り返りますが、それについてはあまりできません。ベロシティを使用して、「15ptsに達しましたか？「しかし、ここでの危険性は、容量ではなく生産性を測定するためにVelocityを使用していることです。これは、私が理解していることから、リアクティブリリース管理（ストーリーポイント）に影響を与えます。

ポイントシステムは、あなたはまだ方程式に相対時間を添付していることに気付かないことはほとんどあまりにも巧妙で、あなたのすべては、あなたが期間+複雑=の周りにいくつかの隠しルールを制定するあなたの毎日のスタンドアップへの「スプリントサイクルを」合意」マックスはlongに取っていますそのタスクで「生来の腸感覚チームコード赤瞬間？

人間の脳は、長期/短期のリコールと混合した多くの作業メモリを含むため、予測できません。そのため、初心者の数学の学生に頭ではなく紙の上で分数をかけるように頼みます。相対時間で常に予測を検証します（たとえば、地質学者は、その立方メートルが地面から掘り出されて「完了」されるまで、予測モデリングを停止しません）。

あなたが予測していないならポイントシステムが働くと思います。サブチャンクアルゴリズムに基づく作業のチャンクに同意していますが、それは可能な限り予測に対する最も近いアプローチです。実際、リリース管理者は、テーマに適合する「バックログ」キューで自然な中断を探します（つまり、Silverlightでは、プロダクトマネージャーは、バックログを完了して最初に設定したテーマをまとめるまで待機します）。エンジニアリングチームが具体的に何をしているのかまったく知らなかったので、基本的な概要を説明しました。その後、その仕事を取り、それを中心にマーケティングイベントを作成しました（Microsoft Mix））

ベロシティ+時間に依存するスプリントサイクル内でベロシティの期待値のロックダウンを開始すると、「依存ゲーム」をプレイしているために悪化するのは今回だけです。また、チームの成長/キャリアの成長の可能性も殺しています。

ポイント対時間に対して支払う税金は、オンジョブスキルの開発/メンタリングまたは開発者の行動を追跡するために、代替の測定式を探す必要があるポイントです。

スキル/エフォートを付加する理想的な人物として「中央開発者」を見る必要があるので、他の開発者をその人物のベースラインにして、チーム内で進行中の成長をフェアリングする方法を決定できます。また、「速い」開発者がほとんどの水を運んでいるが退屈している、またはより長く働いており、期限の競合などのために認識/報酬がない状況を強調しています。実際にスタンドアップはこれを発掘しません。 「その人が苦労しているので助けよう」など、チーム内の悪臭を検出するためにそこにあります

次に、「キャリーオーバー」ストーリー、つまり、そのスプリントサイクルにまとまらないが、次のスプリントサイクルにスピルオーバーするストーリーもあります。時間を考慮している場合、ノックオン効果を簡単に作成できますが、相対時間を考慮に入れると、再び「時間ベースの予測/推定」に戻り、ポイントシステムはちょうど水を濁らせる。

あなたがポイントに行くなら、あなたは時間を完全に無視しており、私があなたに時間を忍び込ませる瞬間として完全に意味するのはあなたがアイデア/方法論をゲームしていることです。

エバンジェリストとして世界中を旅した、「私はチームの多くは、彼らがアジャイル予測コードを割ったことを大切に何に手を誓う見た...しかし、私はいつも私の舌をクリックし、微笑んで離れ思想と歩いええ...あなたはほとんどやったが、私たちが「時間」と呼ぶ愛人...彼女はただ残酷だ...」

Mike Cohnの著書「アジャイルの推定と計画」では、「理想的な日」またはストーリーポイントで推定することの利点と欠点について説明しているため、質問に対する簡単な答えは、ストーリーポイントで推定する必要がないことです。理想的な日に推定することがより自然な場合は、先に進んでください。

Story Point方式には、Man-day方式よりも少なくとも2つの重要な利点があると思います。まず、SPでの推定が簡単です。SPは相対的であり、人間のような人間は、マンデイ方式のような絶対的な推定よりも相対的です。

次に、SPで見積もると、「個別のマンデー」ではなく「チームSP」が得られます。「このタスクにどれくらい時間がかかるか」と尋ねると、シニア開発者は1日ですが、ジュニアには5日を与えることができます。それはマンデイであり、誰がそのタスクを完了するかによって決まります。所有者が強制的に変更される場合（そして変更される場合もあります！）、すべてを再スケジュールする必要があります。SPを使用しても、タスクを実行する人は同じです。

誰もまだパーキンソンの法則に言及していないことに驚いています。

作業は、完了するために利用可能な時間を埋めるように拡張されます。

基本的に、大規模なタスクについて何らかの時間単位で見積もる場合、開発者は見積もるのに時間がかかる傾向があります。Story PointやShirt Sizesのような曖昧な時間に見積もると、この落とし穴を回避できます。

ストーリーポイントの推定は、フィボナッチシリーズ1、2、3、5、8、13、21に続きます...

人間の脳は、サイズに基づいて物事を簡単にマッピングできます。例：ポストイットカードがあり、ストーリーポイント2を割り当て、3ポストイットカードのサイズは2 * 3 = 6ストーリーポイントを意味します。

ストーリーポイント6はフィボナッチ数列5と8の間にあり、5がより近い数であるため、ストーリーポイントは5になります。