スクラムでタスクを推定する方法は？

ユーザーストーリーのバックログがあり、それぞれにストーリーポイントの推定数があるとします。今、スプリント計画を実行しています。

これで、ストーリーはタスクに分解されるはずであり、多くのスクラムリソースは、各タスクを人時間で推定する必要があることを示唆しています。この時点ではすべての質問についてチームが話し合っているため、タスクの見積もりに1分以上かかることはありません。ただし、タスクは1日より長くすべきではないため、8人の開発者による3週間のスプリントを想定すると、120タスクを意味し、見積もりにのみ2時間かかることは、私には少し多く思えます。

経験豊富なチームがタスクの見積もりをスキップまたはショートカットできることは知っていますが、まだその段階ではないとしましょう。

あなたの経験では、スプリントにはいくつのタスクがあり、それらすべてを推定するのにどれくらいの時間がかかりますか？（それらの半分だけを見積もることはあまり意味がありませんか？）

明確化：

答えはスプリントの長さとチームのサイズに依存するので、8人の開発者と3週間と仮定します。

言及された数値は経験則である可能性がありますが、それらがオフの場合（たとえば、より多くのタスク、それぞれを推定するために必要な時間の短縮）でも、推定には約2時間かかります。それで、おそらく質問は「計画会議の何パーセントが純粋なタスク推定のために予約されるべきであり、そして私たちがより良いことをすべきではないのか」であろう。

率直に言って、もしあなたがこの質問をしているなら、あなたは確かにスプリント計画の使用を完全に確信しているわけではないと思います。
スプリント計画のポイントは、特定のユーザーストーリーのセットにコミットするのが快適で、開始するのに十分な知識があるとチームが感じられる状態にすることです。1時間かかるか、4日中2日かかるか、または1日かかるかは、完全に要点を外れています。それが行われるときに行われます。
それを短くして、2時間に制限したいとします。彼らが情報を必要とするという事実は変わらないので、必然的に以前のスプリント計画で使われていた部分が残りのスプリントに塗りつぶされてしまいます。
結局のところ、重要なのは、チームがいくつかの作業に取り組み、実際にその作業を自分自身と他の利害関係者の両方の満足に提供できることです。残りはすべて問題ではありません。実際に価値をもたらすものに焦点を当て、バニティメトリックスに焦点を当てないでください。

シモンズ：どれだけ多くの文献がタスクを数時間で見積もらなければならないことを示しているとしても、私はそれが恐ろしく役に立たない、逆効果的なアイデアであると私はまだわかっており、私はこれだけではないことを知っています。

あなたの経験では、スプリントにはいくつのタスクがあり、それらすべてを推定するのにどれくらいの時間がかかりますか？（それらの半分だけを見積もることはあまり意味がありませんか？）

これは、雷雨の中にある雨滴の数を尋ねるようなものです。同じサイズの2つの異なる嵐について話しても、この質問に答える方法はまったくありません。チームサイズやスプリントサイズに関係なく、経験則はありません。

タスクの時間を見積もるポイントは、チームがストーリーをより正確に見積もることを学ぶことができるようにするためです。たとえば、見積もった2つのストーリーについて考えてみましょう。1つは2と推定され、もう1つは4または5と推定されます。それはあなたに何を教えますか？

私が言えると思う唯一の経験則は、チームの速度が安定している場合は、タスクを見積もる必要がないということです。速度が不安定であることが判明した場合は、推定スキルが弱いことが原因である可能性があります。見積もりの​​一種の健全性チェックとして、計画時にストーリーをタスクに分解することで、それらを強化できます。

あなたの質問では、チームはまだそこにいないと言っているので、見積もりは重要です。それが本当なら、それを行うのに費やす時間について心配しないでください。それには時間がかかります。あなたはあなたのチームに投資をしています。はい、最初はかなり時間がかかりますが、経験から学んでいただければ幸いです。あなたはそれが時間の浪費であることを学んだり、あなたが思っているほど見積りについて賢くないことを学んだりするかもしれません。

覚えておいてください：スクラムは従わなければならない一連のルールではなく、作業の計画と整理に役立つ一連のツールです。これらのツールがあなたの生産性の邪魔をしているときはいつでも、あなたはそれらの使用をやめるべきです。彼らがそうするように見えるのではなく、実際にあなたの生産性の邪魔になることを確認してください。

8名の開発者による3週間のスプリントを想定すると、120のタスクが必要であり、見積もりにのみ2時間かかることは、私には少なからず感じられます。

これは、8人の開発者が次の3週間を計画するために15分を費やすことを意味します。多すぎる？それは毎日のように立ち上がるようなものです。

見積もりです。最初のスプリントを計画します。良いメモと測定をしてください。あなたの最初のスプリントはおそらくマークから外れます。これが問題である場合は、次の問題を改善するために必要な時間と必要な手順を入力してください。タスクに予想以上に時間がかかっていますか？各開発者は、所定のスプリントで期待どおりの数のタスクを実行できますか？

実際に何が行われているか、どのくらい時間がかかったかについて、率直で正直であること。人々が恐れているならば、彼らはただシステムを賭けます。計画の決定は悪いデータに基づいて行われます。あまりに多くのタスクが1日以上かかる場合（または、タスクが実行する必要があると思われる場合）、それらが十分に小さい部分に分割されているかどうかを判断します。

開発者は、タスクに取り組むために1日8時間を十分に持っていない場合があります。マジックナンバー管理者が、丸1日分の仕事で丸1日の仕事をしていると感じてもらいたいと思っていることは何でもありません。

2週間後に3週間のスプリントを完了したか、スプリントの最後にタスクの75％しか完了しなかったことを発見するのは、恐ろしいことでしょうか？予期しないことから学びます（これは概算ですので、それらにこだわって、間違いとは呼ばないでください）。

目標は、特定の時間とリソースで顧客が何をしたいかという状況で顧客を幸せにすることです。このプロジェクトを完了するために必要なすべてのプログラマーから生きる意志を吸い込むことではありません。

だからあなたの質問に答えるために：あなたの最初のスプリントを推定するために最善を尽くしてください。それから学び、次のものを調整します。繰り返す。

私の意見では、見積もりの​​タスク時間はスプリント計画の時間を無駄にしていると思います。一般的に、推定値は間違っており、それらについて報告することに価値はありません。ただし、多くのアジャイルタスク追跡ツールはこれらの時間を使用してバーンダウンを生成するため、そこに何かが必要です。

時間を節約するために、私はこのプロセスに従い始めました：

1. タスクが作成されたらすぐに、作成された各タスクを「1時間」に設定します。
2. 開発者はスプリント全体でタスクに取り組むときに、タスクに1時間以上かかると考えた場合、より現実的な値に更新できます。
3. タスクが完了すると、残り時間でバーンダウンレポートが更新されます。

進行状況や順調に進んでいるかどうかを確認することはできますが、スプリントの計画時間を使用して、ストーリーを理解したり、実行する必要があるタスクを理解したりするなど、より価値のあるアクションを実行できます。

TL; DR

[H]スプリントには多くのタスクがあり、それらすべてを見積もるにはどのくらいの時間がかかりますか？

あなたの質問には可能な正解はありません。確かにいくつかの経験則を使用してタスク量の合理的な上限を計算できますが、ストーリーからタスク、またはタスクから工数の普遍的な変換率はありません。

たとえば、一般的に受け入れられている経験則では、完了/未完了のフィードバックループが緊密になるように、タスクのサイズは半日から2日間にする必要があります。フレームワークの要件ではないため、チームはこの経験則に違反する可能性があり、違反しますが、私がこれまで取り組んできた最も成功したチームはすべて、この規則の精神に従います。

スプリントごとのタスク

答えはスプリントの長さとチームのサイズに依存するので、8人の開発者と3週間と仮定します。

タスクの数はストーリーの数と各ストーリーの分解されたタスクの量と粒度に依存するため、これは公理的に間違っています。それにもかかわらず、健全性チェックの大まかな上限を計算できます。

あなたがアプリオリであることを仮定すると：

• 各タスクに必要な開発者は1人だけです（多くの場合そうではありません）。
• スプリントの30％がフレームワークのオーバーヘッドによって消費されます（この数はスプリントの長さによって異なります）
• 生産的な労働時間は通常、1日あたり6時間以下であるという事実にファッジファクターを適用していません。

その後、各スプリントのタスクに割り当てる開発者ごとのタスクに利用可能な10.5「日」があります。さらに仮定：

• 8人の開発者
• すべての開発者は交換可能です
• タスク間にキューイング活動や依存関係はありません
• 完了したアクティビティの定義を明示的なタスクとして含めている

次に、推奨されるタスクサイジングルールに従うと、チームに3週間のスプリントごとに21〜148タスクの容量が与えられます。

工数の見積もり作業を回避

ここでの簡単な解決策は、理想的な工数でタスクを見積もることを回避し、問題のある（そしてしばしば不正確な）仮定を船外に投げ捨てることです。持続可能速度を超えるストーリーをスプリントに受け入れないだけで、時間を見積もることなく、スプリント計画の問題のほとんどを解決できます。

ストーリーが2〜3日以内の適切なサイズの完了/未完了のタスクに分解されるようにすることで、ストーリーポイントの見積もりよりも複雑なストーリーを誤って受け入れたかどうか、またはそこにあるかどうかをすばやく確認できますスプリント計画中に文書化し、製品所有者と再調査する必要がある隠された作業でした。

健全なチームは、スプリントバックログの分解タスクに約半日を費やしています。スプリント計画の後半でこれを行うために時間をかけないと、エンタングルメント、予期しない依存関係、またはスプリントの後半での計画外の作業が明らかになる可能性が高くなります。

4時間のスプリントバックログ会議は、3週間のスプリント期間の3％未満であり、スクラムフレームワーク内でほとんどの設計およびアーキテクチャ分析が行われます。タスク分析を短期間で変更することで、これを2％まで削減することは、プロジェクトのリスクに値するものですか？私はノーと言いますが、あなたのマイレージは異なる場合があります。

8名の開発者による3週間のスプリントを想定すると、120のタスクが必要であり、見積もりにのみ2時間かかることは、私には少なからず感じられます。

すべてのチームメンバーが各タスクの計画に参加するわけではないため、あなたの仮定は正しくありません。実際、ストーリーの場合、すべてのメンバーがすべてのストーリーの見積もりに参加しますが、タスクの場合は、通常、数人のチームメンバーが各タスクを見積もります。

したがって、例で2人のメンバーがそれぞれタスクを見積もる場合、すべてのメンバーを見積もるのに約30分かかります。