Let’s say product X is worth 10 story points. Development starts in sprint Y, but is not completed in time. What do you with the story points when calculating sprint Y’s velocity?
Would you:
a. Allocate 0 story points for sprint Y and 10 points for the sprint it is eventually completed in;
b. Determine the story points for the remaining work (let’s say 3) and allocate the difference to sprint Y (7 in our example); or
c. Something else?
Thanks in advance!
「瞬間」または「平均」速度のどちらを気にするかによって異なります。個人的には、必要以上に複雑にすることはせず、それが完了したスプリントに追加するだけです。過去 3、6、および 12 か月間でスプリントごとに完了した平均ポイント数を調べて、平均ベロシティを計算します。願わくば、これらが最終的に収束し、1 つのスプリントでどれだけのことを達成できるかを把握できるようになることを願っています。
スプリント Y に 0 ポイントを割り当て、最終的にストーリーが完了したときに 10 ポイントを割り当てます。物語は終わったか、終わっていないかのどちらかです。中間点はありません。50% の完了は避けたいと考えています。そうしないと、チームが多くのストーリーを途中で実装し、完全には実装しない可能性があります。
スプリント中にストーリーを完了せず、次のスプリントで完了することはまったく問題ありません。ただし、スプリント レビュー中にこのストーリーをプロダクト オーナーに提示しないでください。
特定のスプリントに十分なストーリーがある場合、そのストーリーがこのスプリントで完了するか、次のスプリントで完了するかは問題ではありません。物事は平均化されます。
また、ベロシティはリリース時期の推定に役立ち、チームのパフォーマンスの尺度ではないことをチームと利害関係者に説明することも重要です。
チームは、結果がいつ生み出されるかではなく、彼らが生み出す最終的な結果に基づいて判断されるべきです。
適切に優先順位付けされたバックログと組み合わせることで、顧客が必要とする高品質のソフトウェアを作成できます。
これはスプリントのアイデアの 1 つです。「完全性」は、完了したかどうかの 2 要素です。時間の経過とともに、チームの見積もりが改善され、この質問の関連性が失われます。
ここでの状況は満足のいくものではありませんが、現時点では、未完成のストーリーの作業が残っていると見積もっています。約 20% 以下の場合は、ストーリーとスプリントのポイントをそのままにします。それ以上の場合は、ストーリーを終了する必要があるかどうかを PO に尋ねます。そうであれば、ストーリーを新しいスプリントに移動します。しかし、これはいくつかの理由で満足できるものではありません。最初の大きなストーリーまたはリスクの高いストーリーは、スプリントの開始時に開始して、未完了を回避できるようにする必要があります。2 つ目は不正確な (しかしおそらくよりスムーズな) 速度推定値であり、今後はあまり役に立ちません 3 つ目は厳密ではなく、チームは 2 歳の子供のようで、わずかな弱点を示し、それを悪用したいと考えています。
最後に、時間の経過とともに厳格さが厳しくなり、チームはある程度足を踏み入れ、物事を処理する最良の方法を学んでいます。速度にはすでに大きなばらつきがあります。ほとんどのチームは、各スプリントにどのような要因 (休日、病気など) が影響したかについて、すべてのスプリントについてコメントしています... 完全に悪い :(