バックログのグルーミング中にタスクを推定する必要がありますか？
BA、開発、QAタスクに時間の見積もりを割り当てたとき、バックロググルーミングミーティングで驚いただけでしたが、ストーリーはまだどのスプリントにもスケジュールされておらず、リソースをタスクに割り当てていません。
次の理由から、これは私には逆に感じられます。
- 私は自分の危険なタスクを見積もることができます。
- とにかく、スプリントの計画中に見積もりを確認/修正します。
- 各タスクは、作業を行う予定の人が推定する必要があります。 （開発者は真偽不可能です）
この時点で本当に労働時間レベルの精度に見積もろうとしていますか？
この質問のディスカッション はノーと言います。バックログはストーリーで作成され、タスクでは作成されないためです。そして これ は時間スケールに対処します。どちらも関連しますが、私は特に、割り当てられていないタスクを推定するトピックに取り組みたいと思います。
[サイドノート：<3 <3 <3あなたのコメントと回答。私はそれらのほとんどに賛成票を投じたいと思いますが、私のアカウントはあまりにも新しいです：s）
この時点で、本当に労働時間レベルの精度を見積もろうとしているのでしょうか。
地獄いいえ、しかしそれはいつも起こります。
一部の理由は、ほとんどの場所がSortaAgileを使用しているためです。 SortaAgileはストーリーポイントを信じていません。個人が異なる速度を持っているとは信じていません。そして、それは確かにチームの関与を信じていません。
アジャイルが重要なビジネス上の質問に答えるのに本当に悪い仕事をしているという理由もあります：「いつこれが行われるのですか？」。まあ-それは本当にアジャイルのせいではありません。開発者は、明確な範囲を取得し、その範囲の暫定的な完了日を交渉するために、ビジネスを押し戻すのに十分なソフトスキルを持っている必要があります。そのための詳細な見積もりは必要ありません。期待を設定する能力が必要です。アジャイルはプロジェクトマネージャーではなくアジャイルを推進しているので、おそらくアジャイルは開発者により多くの負担をかけます。理想的には、プロジェクトマネージャーがアジャイルで有能であることが理想です。それは... ncommonですが。
だからできる場所に押し戻してください。しかし、見積もりは請求書を支払わないことを覚えておいてください-経営陣との議論は請求書を支払わない。できることをしてから、ソフトウェアの作成に戻ります。
グルーミングセッションでタスクレベルの推定を行うことは悪い習慣です。グルーミングセッションの目的は、ディスカッションを詳述し、受け入れ基準を完成させることにより、何をする必要があるかを理解することです。これにより、チームは明確なビジョンを持ち、頭にあるものとそれらのストーリーを実現するために何が必要かを理解できます。
チームがストーリーを明確に理解したら、時間単位ではなくポイント単位で見積もることができます。見積りは、既知および未知の複雑さによって行う必要があります。ポイントで見積もる方法は、まったく別のトピックです。
私がよく知っている方法論をやっているようには思えません。通常、バックログにタスクはありません。どのようにタスクに優先順位を付けますか？すべてのタスクを実装せずにストーリーを完成させることはできないため、それらをバックログに入れても意味がありません。ストーリーは続く必要があります [〜＃〜]投資[〜＃〜]
この時点で、本当に労働時間レベルの精度を見積もろうとしているのでしょうか。
いいえ、これは "最後の責任のある瞬間" まで延期する必要があります。あなたが実際にそれを実装するために来るときまでに、物事は変わっているかもしれません、そしてあなたはそれをする必要がないかもしれません（そして実際、これはあなたのスプリント計画のケースのように聞こえます）。人々は通常、あなたが「ちょうど十分」にすることを勧めます
私は自分の危険なタスクを見積もることができます。
プログラマーは通常、タスクの見積もりがかなり得意ではありません。これが、人々が「理想的な労働時間」または単なるポイントをよく使用する理由です。
各タスクは、作業を行う予定の人が推定する必要があります。 （開発者は真偽不可能です）
開発者が根拠のないものであることは事実ですが、アジャイルチームは通常、共同でコードを所有します。 これはXPのルールの1つです。 開発者が異なるスキルを持っているからといって、特定のタスクに誰も取り組むことができないという意味ではありません。
バス係数 が高いようですね。