チームはストーリーポイントを推定しており、ビジネスは実際の時間を必要としている

これは珍しいテーマではないと確信しています。ストーリーポイントを使用してユーザーストーリーを推定する大丈夫な仕事をしている2つのスクラムチームがあります（チームメンバーは数年のスクラム経験がありますが、現在のチームの星座はわずか8か月です）。しかし、会社のビジネス部門がユーザーストーリーに関連することは困難です。実際の時間単位（または「ストーリーポイントを時間に変換する式」）が必要なため、いつ準備が整うかを計画できます（「Feature Xが生産中であることを顧客に伝えることができる時期を知る必要があります」 "）。

私と私のスクラムマスターの前任者は、もちろん、「ストーリーポイントと実際の時間の間に明確な関係はない」と「ストーリーポイントはチームがスプリントにどれだけフィットできるかを決定するために使用される」と説明しました。彼らがその答えにどれほど満足しているか推測できることを確認してください。彼らは、カレンダーの時間に、バックログの27番目のユーザーストーリーに到達する時期を知りたがっています。

いずれにせよ、私はいくつかの統計情報をコンパイルされている、と私たちのSP推定値はに変換乱暴に異なる実時間費やした結果（チケットは列「に取り組ん」に費やすどのくらいの時間を追跡し、当社のスクラムボードソフトウェア、によって測定されます）。1-SPユーザーストーリーの場合、もちろん非常に短い期間（ときどき爆発する）への大きなバイアスがありますが、特に2-SPストーリーの場合、それらはいたるところにあります。 「最速」と「最遅」の完了間。3、5、および8 SPストーリーの場合、スプレッドも2倍以上です。

これは、（a）チームが（同様の）複雑さのユーザーストーリーの推定においてはるかに一貫性を保つ必要があること、および（b）チームが時間レポートの精度を向上させる必要があることを示します（つまり、会議中、昼食時、またはフーズボールをプレイしているときに「作業中」）。

私は（a）と（b）の両方を改善する計画がありますが、これらのイニシアチブがもたらすものよりも「具体性」をビジネスが期待しているだけでは不十分だと感じています。

ビジネス側を和らげるいくつかの良い戦略は何ですか？それは私たちがどのように仕事をするかをあまり邪魔しないようにするためです（たとえば、個別の時間追跡の使用を課すことによって現在の「自動」追跡）、同時にストーリーがいつ行われるかについての具体性のある程度の測定値を取得できるようにしますか？

（歴史的に、計画中にユーザーストーリーをワークアイテムに分割し、実際の作業時間で個別に推定しましたが、ここで話しているのはバックログのユーザーストーリーで、そのレベルの詳細やブレークはありません-ダウン。）

更新：私のマネージャーは、ストーリーポイントごとの時間のベル曲線分布のようなものがあるという予感がありましたが、私が照合したデータと彼が作成したグラフは、彼の考えを徹底的に否定しました。:-)

ストーリーポイントを時間に変換する公式はありません。メートルからフィートへのかなり無損失の変換を取得できますが、3ポイントのストーリーにX時間かかるとは言えないため、5ポイントのストーリーにY時間かかります（Yを解決）。

HorusKolはこの次の部分に触れました。チームとしてのスプリント速度は、長期的な成果物に役立ちます。チームがスプリントごとに50ポイントであり、各スプリントが2週間であるとします。したがって、スプリントあたり50ポイントに年間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週間があり、人々が「4週間」と聞くとすぐに「1か月」だと思うので、8週間も言わないでください。見積もりが約4週間に達すると、1か月になります。その後、数か月で作業します。1年以上ヒットした場合は、正直に言ってその仕事を見積もらないでください。無意味です。1年で変化しすぎることがあります。

これは、ストーリーポイントを時間に変換するかなり正確な方法であることがわかりました...とにかく時間です。

個々のストーリーを完了するのにかかる時間にはばらつきがあります。一部の開発者は他の開発者よりも速く作業します。すべてのストーリーポイントをボウルに入れ、ブレンダーをオンにして平均を使用すると、これらの矛盾を緩和できます。

ああ、そして最も重要な部分を忘れないでください：

切り上げする。常に。

おそらく、ストーリーポイントから時間の見積もりへの固有の変換が既にあるはずです-スプリントに十分な仕事を選んだとどのように判断しますか？おそらく、「チームは週に20（または40またはそれ以上）ポイントを処理できる」というようなことを言ったことがあるでしょう。数回のスプリントの後、完了に基づいてそれを修正できるはずです。つまり、15または25（または35または50または...）がスプリントを指します。これがチームの速度です。

1-SPユーザーストーリーの場合、もちろん非常に短い期間（ときどき爆発する）への大きなバイアスがありますが、特に2-SPストーリーの場合、それらはいたるところにあります。 「最速」と「最遅」の完了間。3、5、および8 SPストーリーの場合、スプレッドも2倍以上です。

特定のストーリーを完了するための時間の変動は、ポイント値の範囲内で問題ありません。速度は、最近の履歴の平均であるため、その不確実性を考慮しています。

ただし、ポイント、特にそのような大きな変動が発生している場合は、これらの2ポインターをどのように割り当てているかを長く注意深く見る必要があります。より高いポイントのタスクは不確実であると想定されています（そして、分解する必要があります）-2ポインターほどの小さなタスクはかなり一貫している必要があります。

同じポイント値を割り当てられたすべてのタスクは同様の努力を必要とするはずなので、そのような範囲の時間があるとは意味がありません。

振り返ってみると、最も時間がかかった2ポインターを見てください。おそらく午前中に取るべきだったはずの何かが、なぜ10日間のスローに変わったのでしょうか？その最初の朝に「これは叙事詩になり、より小さなタスクに分割する必要がある」と言うために何かフラグが立てられたでしょうか？もちろん、それが発生したらすぐに、必要な追加作業をバックログに入れ、スプリントの残りの部分に干渉しないようにする必要があります。

また、チームがどのようにそのアイテムを過小評価しているかを試してみてください-今後のアイテムでレビューした方が良いでしょうか？

はい、配信日はそれに応じてプッシュされるか、更新の機能のリストが修正され、配信が影響を受けないようにすることができます。しかし、目的は将来のポイント推定を改善し、より正確なタイムラインを取得することです。

天気予報のようなものです。遠くに行くほど、信頼性は低くなります。それは誰もが理解するであろうアナロジーです。推定のエラーが合計されます。

セールスは、スクラム用語で顧客と話すことを学ばなければなりません。スクラムは単独では意味をなさず、会社全体に垂直に適用されることが想定されており、できればクライアント領域にまで拡張されることが望ましい。

開発チームとしてのあなたはこれについてしっかりしているべきです。あなたは彼らに期待と推測を与えることができますが、それが単一のスプリントを拡張するコミットメントであることはさせません。

このような質問を受けたとき、私はいくつかのことをします。

まず、過去について説明することで未来に関する質問に答えます。私たちは週にこれらの物語のうち約2つを通り抜けるようなことを言いたいと思います。したがって、何も変わらなければ、約14週間でストーリー27が完了すると予想されます。

第二に、私は、顧客に直面している顧客に取引スケジュールとリスクの責任を負わせたいです。私のような何かが言う、50/50推計に基づき、エンジニアリングチームの作品を覚えておいてください。何も変わらない場合、14週間で機能27の準備ができる可能性は50/50です。おそらく、あなたはそのレベルのリスクを伴う何かを顧客に報告したくないでしょう。たとえば、90％の信頼を持っているという見積もりを計算してほしいですか？次に、歴史的証拠を確認して、次のようなことを言う必要があります。ストーリー27が25週間で完了する確率は90％です。

最後に、同僚が外部のコミットメントを行うと、会社が固定されることを思い出してください。ストーリー27番について外部と約束すると、会社の俊敏性がすべて失われます。その後、特定の行動方針に専念します。誰かが変更リクエストであなたに来るときはいつでも、あなたは答える必要があります。この変更は、お客様に連絡して、コミットメントが無効になったと伝えた場合にのみ行うことができます。基本的に、1か月以上先の仕事に特定のコミットメントを行うには、多くの問題が伴います。

既に（非常に粗雑な）変換を行っています。
スクラムスプリントは（通常）2週間です。
たとえば、この2週間で約20ストーリーポイント相当の機能を完了することができます（または、1つのスプリントにパックされる機能の数と数を他にどのように決定しますか？）。過去5回のスプリントで18、21、23、19、20ストーリーポイント相当の機能を完了しました）。

機能X（およびそのすべての依存関係）が47ストーリーポイントと推定されているとします。
そのため、それを最も優先して実装する場合、約3スプリント、つまり6週間かかると推定できます（ただし、35のポイントがDB作業であり、あなたが持っているのがDBの人では、それを考慮するために推定速度を修正する必要があります）。

そうは言っても-それらが大まかな見積もりであることをしっかりと伝えてください-スプリントが6ではなく2週間である理由があります。予測がカバーする必要があるものが多いほど、不確実性とエラーが入り込みます。また、コストをしっかりと伝えます。つまり、これはタスクを最優先することを意味し、他のタスクは実行されません。そうしないと、次のシナリオが発生する可能性があります。

「機能Yはいつ行われますか？」
「次のことに集中したら... 12週間」
「12週間？！？ 4時間がかかると言っていました。」
「はい、しかし、あなたは私たちにすべてのリソースをバインドして8週間かかるだろうと言った機能Xを優先するように私たちに言った。」
「機能Xと機能Yを同時に使用することはできませんか？」
「うめき声」

スプリントは2週間などの定義された時間です。現在のスプリントと次のスプリントがあるように、2つのスプリントよりもさらに多くのストーリーが行われるとは予測できません。次のスプリントのためにチームと話し合い、ビジネスで優先順位付けされたストーリーを準備したと思います。確実に言えるのは、今後4週間の仕事です。

4週間を超えるものはすべて変更される可能性があり、ビジネスでは数時間で設定されないロードマップを作成できます。それはスプリントごとに計画する必要があります。いくつかのepic1（グループ化されたストーリーのジラのように壮大な）とepic2はスプリント47と48で行われ、epic3はスプリント49で行われるべきです。スプリントに1つまたは2つが収まるかどうかを確認します。とにかくタイムラインはずれます。機能が機能していない場合、ビジネスは範囲を狭めるか、必要に応じて後で改善できる完全ではないソリューションを受け入れる必要があります（アジャイルであるべきで、計画に従うのではなく現実を受け入れます）。

将来のスプリントとそれらの主なトピック/エピソードを使用して、素敵なガントチャート（ビジネスのようなもの）を作成できます。

私はすべてのスプリントをリリースするのが好きで、それからスプリントで完成したもの（または完璧ではないのにビジネスでリリースするためにサインされたもの）でリリースを準備し、未完成のものは次のスプリントに行きます。このようにして、約2〜3週間のタイムライン（リリース候補の最終的な修正のために1週間）で予測可能な配信を行います。

それは小さなチームでの私の経験、少量の外部依存関係、そして私が合理的なビジネスだと信じていることです。走行距離は異なる場合があります。

新機能の場合、必要な時間を見積もることはほぼ不可能です。

ソフトウェア開発の経験から、ほとんどの場合、実際に開発を開始する前に見ることができない詳細があることがわかります。最良の場合、それらの詳細にはさらに時間が必要になる場合がありますが、最悪の場合、プロジェクトも失敗する可能性があります。その理由は、ソフトウェア開発自体の複雑さにあります。

これが、SCRUMが問題の複雑さ（ストーリーポイント）のみを推定し、時間を推定しない理由です。唯一のチャンスは、複雑度の高い機能を小さな機能に分割することです。これにより、リスクを最小限に抑えることができます。

時間の見積もりはほぼ不可能であるため、ストーリーポイントを時間の見積もりに変換する公式はありません。速度は非常に大雑把な推定値にすぎず、それ以上ではありません。

SCRUMでは、製品の所有者は各スプリントの前にバックログアイテムの優先順位を変更できます。したがって、SCRUMマスターは複数のスプリントの見積もりを出すことはできません。次のスプリントでどのバックログアイテムが重要になるかはわかりません。

SCRUMは、不可能なことを実行したり（計画外の計画を立てたり）、開発を高速化する方法ではありません。開発が時間切れになった場合の早期警告システムです。新しい要件に迅速に対応できます。

最初の投稿へ：

ほとんどのタスクを1 SPから5 SPのストーリーに分割して管理すれば、すでに非常に優れています。タスクが類似しており、チームがより経験を積むと、速度の推定値が向上する可能性があります。しかし、新しいアイテムに未知の未知のパーツが常に存在する場合、不正確な状態で生活する必要があります。

開発者は通常、開発以外の作業（会議など）にある程度の時間を費やすため、毎日8時間の開発ではなく、6時間などの開発を計画する必要があります。その後、他のタスクまたはより多くの時間を要する作業項目のために予約を取得します。

同僚が正確な見積もり（それ自体が矛盾している）を得たい場合は、ソフトウェア開発に固有の問題を説明します。次に、アジャイルメソッドの利点を示します。