スクラムで、ストーリーポイントとタスク時間が相関しない場合はどうすればよいですか？
私たちの開発チームはスクラムプロセスにかなり慣れていないため、メソッドを改良してそれをより有効に活用できるようにしたいと思います。特に、ストーリーポイントと作業時間の相関関係はあまり良くないことに気づきました。つまり、ポイントの高いストーリーよりもポイントの少ないストーリーのほうが、合計タスク時間に分解されることがよくあります。
現在、これらは2つの別個の推定プロセスであり、時間を使用してスプリントの残りの作業のみを推定し、ストーリーポイントを使用して速度を計算し、リリースサイクルの長さまたは対処できる機能の量。ただし、スプリントポイントとタスク時間の相関関係が適切でない場合、これらのいずれかまたは両方を見積もるのは適切ではありません。
費やした時間を記録するのではなく、残りの作業時間のみを調整するため、問題が最初のタスク時間の内訳なのか、ストーリーポイントの推定なのか、簡単にはわかりません。
だから、私の質問は、これに対処する必要があるかどうか、そしてどのように？私はこれに対処し始めるいくつかの方法を考えることができます：
- タスクに費やした時間を記録し、この情報をフィードバックとして使用して、過小評価または過大評価されたユーザーストーリーを遡及的に特定することにより、見積もりプロセスを改善します。 しかし、この情報を記録する必要があるとは確信しておらず、抵抗が予想されます。
- 計画フェーズでは、タスク時間の内訳プロセスの後に外れ値を特定し、これらをさらに調べます。このようにして、ストーリーの複雑さを誤って判断したのか、タスクの内訳にいくつかの努力が欠けているのか、単純なタスクの長さを過大評価しているのかを特定できます。 しかし、これは2つの推定作業を結合することになると思います。これは、どちらを行うにも適切なことではないと思われます...これは、計画段階のストーリー。それ以外の場合、誤って判断されたストーリーについてはあまり実行できません。
- これにアプローチする別の方法は、推定プロセスを強化する方法を独自に組み込んで、推定の重要性についてチームの意識を高めることです。次に、ストーリーポイントと最初のタスク時間の内訳の間の相関関係を、私たちがどのようにしているか、そして私たちが作業を続ける必要があるかどうかの指標として監視し続けます。 私はこれが最善のアプローチだと思いがちですが、あまり積極的ではありません。
この問題に取り組むための最良の方法は何ですか、このコンテキストで推定プロセスを強化するために他にどのような提案がありますか？
あなたが言ったように、それらは異なる目的で使用されるため、それらは実際にはうまく連携しません。
時間が経つにつれて、チームはより適切な見積もりを行い、ストーリーポイントごとの速度がより正確になります。
あなたの解決策についての私のコメント：
タスクに費やした時間を記録し、この情報をフィードバックとして使用して、過小評価または過大評価されたユーザーストーリーを遡及的に特定することにより、見積もりプロセスを改善します。
Velocityは、現実に対する開発者の推定を調整するために設計されました。速度を適切に使用すると、平均して3つまたは4つのスプリントの不確実性が「調整」されます。
計画フェーズでは、タスク時間の内訳プロセスの後に外れ値を特定し、これらをさらに調べます。このようにして、ストーリーの複雑さを誤って判断したのか、タスクの内訳にいくつかの努力が欠けているのか、単純なタスクの長さを過大評価しているのかを特定できます。
ここでも、「ミスジャッジ」は、スプリントごとに得られる時間と経験によって調整されます。
これにアプローチする別の方法は、推定プロセスを強化する方法を独自に組み込んで、推定の重要性についてチームの意識を高めることです。次に、ストーリーポイントと最初のタスク時間の内訳の間の相関関係を、私たちがどのようにしているか、そして私たちが作業を続ける必要があるかどうかの指標として監視し続けます。
それも時間をかけて行われます。ポーカーセッションの計画は、経験とともにますます生産的になります。
開発者の観点からすると、自分の人生の時間を見積もることはできません。かなりうまくいくかどうかを見積もることができます。
そうは言っても、私がストーリーポイントで見積もりを出すとき、基本的にそれは難しいまたは簡単な仕事だと言っています。 SPこれは（PM）にこれが難しい作業であるという考えを与えることになるので、Imで作業しているときは私を一人にして、早く完了できるようにするか、Imで心の麻痺する作業をする、それで、もしあなたが質問をするならば、振り返ってください。
また、あなたはあなたの開発者とそこのスキルレベルを知っているので、もしあなたがジュニア開発者を持っているなら、彼に3を与えないでください、しかし1は彼が溺れないようにしてください。
次に、いくつかの例を示します。
簡単（1sp）：関数時間をリファクタリングします。これは、言語によって、またそれが魔法の関数として使用されているかどうかによって、10分-2時間かかる場合があります。次に、テストなどがあります。
hard（3sp）：デプロイメントサーバーの時間を設定します。カスタムデプロイメントシステムの場合は1日以上。
だから、理論的には、私は1日3 spを行うことができますが、3つのリファクタリング関数はそれぞれ10分-30分かかりますか？時間管理については、SPの概念はガントチャートに変換されないので、必要に応じて時間の見積もりも取得します。
重要なことは、まず実際に問題があるかどうかを理解することです。
- ストーリーポイントは、チームがスプリントにどれだけ適合できるかを決定するために使用されます
- タスク時間は、スプリントの正常性を判断するために使用されます
したがって、アプリオリこれを心配する理由はありません。ただし、実際には、反復の初日では、残りのタスク時間とストーリーポイントの両方がスプリント全体の長さに関連付けられます。これにより、何らかの形の相関を測定するために使用できるポイント。
次の点を考慮します。
- スプリントは順調ですか？言い換えれば、チームは適切なポイント数に取り組んでいますか（少なすぎず、多すぎませんか）。
- 1反復の価値のあるポイントが1反復の価値のある時間と異なるか、または相関しないという兆候はありますか？
- 設計により、ポイントは時間より正確ではありません。あなたは単に洗練を目撃していますか？
- あなたのチームは、ストーリーを見積もるのが（まだ）あまりよくないのですか？
どうしましょう？振り返りを待って、この問題についてチームと率直に話します。
我々が理解する本当にタスク時間を追跡する必要があるか？平均速度を推定して、スプリントから別のスプリントにどれだけコミットすべきかを推測することはできませんか？結局のところ、これが本当に重要なことだからです。