チームはストーリーポイントを推定しています。ビジネスは実際の時間を必要としています
これは珍しいテーマではないと思います。ストーリーポイントを使用してユーザーストーリーを見積もるという2つのスクラムチームがあります（チームメンバーは数年のスクラム経験がありますが、現在のチーム星座はたった8か月前のものです）。しかし、会社のビジネス部門がユーザーストーリーに関連することは困難です。彼らは、実際の時間単位（または「ストーリーポイントを時間に変換する式」）を求めているので、準備が整ったときの計画を立てることができます（"フィーチャーXをいつ顧客に伝えることができるかを知る必要があります生産されます」）。
私と私のスクラムマスターの前任者はもちろん、「ストーリーポイントと実際の時間の間に明確な関係はない」と「ストーリーポイントは、チームがスプリントにどれだけ収まるかを決定するために使用される」と説明しました。確かに彼らがその答えにどれだけ満足していたかを推測できるでしょう。彼らはまだ、カレンダー時間で、バックログでその27番目のユーザーストーリーに到達する時期を知りたいと思っています。
いずれにせよ、私はいくつかの統計をまとめており、SP見積もりはwildlyに変換されます（スクラムボードソフトウェアで測定した場合、 「作業中」の列でチケットが費やす時間を追跡します。1-SPユーザーストーリーの場合、もちろん非常に短いタイムスパン（時折爆発）に大きなバイアスがありますが、特に2 -SPストーリー、それらは至る所にあります：「最も速い」と「最も遅い」完了の間には20の係数があります。3、5、8-SPストーリーの場合、スプレッドも1倍以上です。 2。
これは、（a）同様の複雑さの（あるべきもの）ユーザーストーリーを推定する上で、チームがより一貫性を保つ必要があり、（b）時間レポートの精度を向上させる必要があることを示します（つまり、チケットを会議中、昼食時、またはフーズボールをしているときの「作業」。
（a）と（b）の両方を改善する計画がありますが、これらのイニシアチブがもたらすよりも「具体性」がビジネスに期待されることは十分ではないと感じています。
ビジネス側の緩和に役立ついくつかの戦略、つまり、私たちの仕事に過度に干渉しないようにします（たとえば、個別の時間追跡の使用を課すことにより、IMHOはそれが馬鹿げているため、いずれにせよ、現在の「自動」追跡よりも正確さが劣りますが、同時に、ストーリーがいつ行われるかについての具体性の尺度を取得することを許可しますか？
（歴史的には、計画中にユーザーストーリーを作業項目に分解し、個別に見積もった実際の作業時間ですが、ここで話しているのは、バックログのユーザーストーリーではありません。そのレベルの詳細または内訳を持っている。）
更新：私のマネージャーは、ストーリーポイントごとに費やされた時間の一種のベルカーブ分布があるという予感がありましたが、私が照合したデータと彼が作成したグラフは、その概念を完全に混乱させました。 。 :-)
正解です。ストーリーポイントを時間に換算する式はありません。メートルからフィート、またはその逆のかなりのロスレス変換を取得できますが、3ポイントのストーリーはX時間かかるとは言えないため、5ポイントのストーリーはY時間かかります（Yで解決）。
HorusKolはこの次の部分に触れました。チームとしてのスプリント速度は、長期的な成果物を支援することができます。チームがスプリントごとに50ポイントであり、各スプリントが2週間であるとします。したがって、1スプリントあたり50ポイントに1年間に50週間を掛けると（休暇の場合は2週間の休暇を取ると想定）、現在のチームは12か月で最大2,500ポイントを獲得できます。
したがって、ビジネスには170ポイント分のストーリーと叙事詩が用意されています。チームのこれまでの速度50ポイント（これまでのすべてのスプリントの平均）で除算すると、3.4のスプリントが得られます。見積もりを行っているため、最大4つのスプリント（8週間）に丸めます。基本的に2ヶ月です。また、最後の3〜4回のスプリントを取り、別の見積もりを出すことも好きです。あなたのチームが最後の3つのスプリントでそれぞれ53、67、55ポイントを達成したとしましょう。これは58点に達し、そのレートは2.9スプリントです。つまり、基本的に3スプリントです。これらの170ポイントのタイムラインは6〜8週間のように見えます。
ビジネスに2か月を伝えます。 「6週間」としか聞こえないため、6週間から8週間は伝えないでください。ほとんどの月には約4.5週間あるので、8週間も伝えないでください。「4週間」と聞くと、すぐに「1か月」と思います。見積もりが約4週間になると1ヶ月になります。その後、数か月で作業します。あなたが1年以上ヒットした場合、正直に言ってその仕事を推定しないでください。それは無意味です。 1年で変化しすぎる可能性があります。
これは、ストーリーポイントを時間に変換するかなり正確な方法であることがわかりました。
個々のストーリーが完了するまでにかかる時間にはばらつきがあります。他の開発者よりも速く作業する開発者もいます。すべてのストーリーポイントをボウルに入れ、ブレンダーをオンにして平均を操作すると、これらの不整合を緩和するのに役立ちます。
ああ、そして最も重要な部分を忘れないでください：
切り上げする。常に。
おそらく、ストーリーポイントから時間の見積もりまで、いくつかの固有の変換があります。スプリントに十分な作業を選択したとどのように判断しますか？ 「チームは1週間に20ポイント（または40ポイントなど）を処理できる」と言ったことはあるでしょう。数回のスプリントの後、完了に基づいて修正できるはずです。つまり、15または25（または35または50または...）はスプリントを指しています-これはチームのvelocityです。
1-SPユーザーストーリーの場合、もちろん非常に短いタイムスパンに大きな偏りがあります（時折爆発する）が、特に2-SPストーリーの場合、それらはすべての場所にあります。20の係数があります。 「最も速い」と「最も遅い」完了の間。 3、5、8-SPストーリーの場合も、スプレッドは2倍以上です。
特定のストーリーを完了するまでの時間の多少の変動は、ポイント値内で問題ありません。速度は、最近の履歴の平均であることによってその不確実性を考慮します。
ただし、ポイントがどのように割り当てられているか、特にこのような大きな変動が発生している場合は2ポインターを注意深く調べる必要があるかもしれません。より高いポイントのタスクは不確実であるはずです（そして分解する必要があります）-しかし、2ポインター程度の小さなタスクはかなり一貫しているはずです。
同じポイント値を割り当てられたすべてのタスクは同様の労力を必要とするため、完了までにそのような時間範囲があることは意味がありません。
さて、あなたの回顧で最も時間がかかった2ポインターを見てください。たぶん、朝を取るべきだったはずの何かが10日間のスローガンになったのはなぜですか。その最初の朝に、「これは壮大になり、より小さなタスクに分解される必要がある」と言う何かにフラグが立てられたのでしょうか？もちろん、それが発生したらすぐに、必要な追加作業をバックログに入れて、残りのスプリントに干渉しないようにする必要があります。
また、チームがその項目をどのように過小評価しているかを確認してみてください-将来の項目をレビューしたことで、もっと上手くできますか？
はい、それに応じて配信日がプッシュされます。または、更新の機能のリストを変更して、配信に影響を与えないようにすることができます。しかし、その目的は、将来のポイント推定を改善し、より正確なタイムラインを得ることです。
それは天気予報のようなものです。離れるほど信頼性は低くなります。それは誰もが理解する類推です。推定値のエラーが加算されます。
営業は、顧客にスクラム用語で話すことを学ぶ必要があります。スクラムは単独では意味をなさず、会社全体で垂直方向に適用されることが想定されており、できればクライアントの領域にまで及ぶことが望ましい。
開発チームとしてのあなたはこれをしっかりとすべきです。あなたは彼らに期待と推測を与えることができますが、それが単一のスプリントを拡張するコミットメントであってはなりません。
あなたはすでに（非常に粗雑な）変換をしています：
スクラムスプリントは（通常）2週間です。
この2週間で約20ストーリーポイント相当の機能を完了することができます（または、他にどのようにして、1つのスプリントにパックされる機能と機能の数を決定しますか）、および以前のスプリントは確認します。その見積もり（最後の5つのスプリントで18、21、23、19、20ストーリーポイントに相当する機能を完了したとしましょう）。
機能X（およびそのすべての依存関係）が47ストーリーポイントと推定されているとしましょう。
そのため、それを最高の優先度で実装する場合は、約3スプリント、つまり6週間かかると見積もることができます（ただし、35点がDBである場合、見積りには誰が何を実行できるかを考慮に入れてください）仕事をし、あなたはそれを考慮に入れるためにあなたの推定速度を修正する必要があるDBの男だけを持っています）。
とはいえ、これらは大まかな見積もりであることをしっかりと伝えてください。スプリントが6週間ではなく2週間であるのには理由があります。予測がカバーする必要のある事項が多ければ多いほど、不確実性とエラーが発生しやすくなります。また、コストをしっかりと伝えてください。つまり、これはタスクを最優先することを意味し、他のタスクは処理されません。そうしないと、次のシナリオに遭遇する可能性があります。
「機能[〜＃〜] y [〜＃〜]はいつ完了するのですか？」
「次に焦点を絞れば... 12週間」
"12週間？！？ 4時間がかかると言っていました。"
「はい、ただし機能[〜＃〜] x [〜＃〜]を優先するように言われましたが、これはすべてのリソースをバインドして8週間かかると伝えました。」
"機能[〜＃〜] x [〜＃〜]および機能[〜＃〜] y [〜＃〜] =同時に？」
"うめき声"
このような質問を受けたとき、私はいくつかのことをします。
まず、過去について述べることで、未来についての質問に答えます。私は次のように言います1週間にこれらのストーリーのうち約2つを通過します。したがって、何も変更がなければ、ストーリー14は約14週間で完了すると予想されます。
第二に、私は顧客に直面している人々が取引スケジュールとリスクの責任を負うことを望んでいます。私は次のように言います覚えておいてください、エンジニアリングチームは50/50の見積もりに基づいて作業します。何も変わらない場合、機能27が14週間で準備できる確率は50/50です。おそらくあなたは望んでいないでしょう。そのリスクのレベルで何かを顧客に報告します。たとえば、90％の信頼度があるという見積もりを出しますか？次に、過去の証拠を確認して、次のように言う必要があります。 ストーリー27が25週間で完了する確率は90％です。
最後に、同僚が外部のコミットメントを行うと、会社は固定されることを同僚に思い出させます。ストーリー番号27について外部に約束すると、会社の敏捷性がすべて失われます。その後、特定の行動方針に取り組むことになります。誰かが変更リクエストをもって来たときは、いつでも答える必要がありますx日の前にストーリー27を終了することを約束しました。この変更は、お客様に連絡して、私たちのコミットメントが無効になったことを伝えた場合にのみ可能です。基本的に、1か月以上先の作業に特定のコミットメントを行うことは、多くの問題を伴います。
スプリントは定義された時間、たとえば2週間です。現在のスプリントと次のスプリントがあるように、一部のストーリーが2スプリントより先に行われると予測することはできません。次のスプリントのためにチームと話し合い、ビジネスによって優先順位付けされたストーリーを準備したと思います。したがって、次の4週間の作業は間違いないと言えるでしょう。
4週間を超えるものはすべて変更される可能性があり、ビジネスは時間で設定されていないロードマップを作成できます。これはスプリントごとに計画する必要があります。たとえば、epic1（グループ化されたストーリーのジラの束など）とepic2はスプリント47と48で実行し、epic3はスプリント49で実行する必要があります。 1つまたは2つがスプリントに収まるかどうかを確認します。タイムラインはとにかくずれます。 機能が機能していない場合、ビジネスはスコープを削減するか、必要に応じて後で改善できる完璧ではないソリューションを受け入れる必要があります（それは俊敏であり、計画に従うのではなく現実を受け入れる必要があります）。
将来のスプリントとそれらの主なトピック/エピックを使って、ニースガントチャート（つまり、ビジネスのようなもの）を作成できます。
私はすべてのスプリントをリリースするのが好きで、スプリントで終了したもの（または完璧ではないが、ビジネスによってリリースするために署名されたもの）でリリースを準備し、未完成のものは次のスプリントに進みます。この方法では、約2〜3週間のスケジュールでリリースを予測できます（リリース候補の最終的な修正には1週間）。
それは小さなチームでの私の経験であり、少量の外部依存関係であり、合理的なビジネスであると私は信じています。あなたの走行距離は異なる場合があります。
新機能の場合、必要な時間を見積もることはほぼ不可能です。
ソフトウェア開発の経験から、ほとんどの場合、実際に開発を始める前に見ることができない詳細があることがわかります。最良の場合、これらの詳細にはさらに時間がかかる可能性がありますが、最悪の場合、プロジェクトも失敗する可能性があります。その理由は、ソフトウェア開発自体の複雑さです。
これが、SCRUMが問題の複雑さ（ストーリーポイント）を推定するだけで、時間を推定しない理由です。唯一のチャンスは、複雑度の高い機能を小さな機能に分割することです。これにより、リスクを最小限に抑えることができます。
時間の見積もりはほぼ不可能であるため、ストーリーポイントを時間の見積もりに変換する公式はありません。速度は、非常に大まかな見積もりにすぎず、それ以上ではありません。
SCRUMでは、製品の所有者は各スプリントの前にバックログアイテムの優先順位を変更できます。したがって、SCRUMマスターは、複数のスプリントの見積もりを出すことはできません。彼は、次のスプリントでどのバックログ項目が重要になるかはわかりません。
SCRUMは、不可能なこと（計画できないことを計画すること）を行ったり、開発を高速化したりする方法ではありません。開発が時間切れになった場合の早期警告システムです。新しい要件にすばやく対応できます。
最初の投稿へ：
ほとんどのタスクを1 SP to 5 SP storiesに分割しました。タスクが類似している場合、速度の推定値はより良くなる可能性があります。チームはより経験を積むことができますが、新しいアイテムに常に新しい未確認のパーツがある場合は、不正確に対処する必要があります。
開発者は通常、開発以外の作業（例：ミーティング）にある程度の時間を費やすため、1日あたり8時間の開発を計画するべきではありません。 6時間。次に、他のタスクまたはより多くの時間がかかる作業項目の予備を取得します。
同僚が正確な見積もりを求めている場合（それ自体は矛盾です）、ソフトウェア開発に固有の問題を説明します。次に、アジャイルメソッドの利点を示します。