平均よりも悪いスプリントの50％を処理する方法は？
私がスクラムを正しく理解していれば、次のスプリントでチームが実行できる作業をこのように判断します。
私は過去のいくつかのスプリントの完了したポイントの数を平均します。
この量は平均速度です。次のスプリントでは、その多くのストーリーポイントを引き受けます。
これは平均なので、履歴が繰り返される場合、このスプリントは、ストーリーポイントが少なすぎる可能性が50％であり、50％である可能性がありますストーリーのポイントが多すぎます。
50％のケースでは、次のような多くのストーリーポイントを取り上げました。
スプリントを完了できません。これは、スプリントのコミットメントを半分の時間で満たすことができないことを意味します
追いつくために余分に働きなさい。問題は、これが一方向にしかラチェットしないことです。私たちはスプリントを達成し、完了したストーリーポイントの数はそれを反映します。私たちは常に終了しているため、時間の経過とともに、平均は、常に多数のストーリーポイントを達成し、遅れをとるポイントまで上昇します。
平均速度とスプリントのコミットメントについての私の理解は正しいですか？
もしそうなら、平均よりも遅れているスプリントの50％に対して何をすべきでしょうか？
そうでない場合、何が間違っていますか？
平均速度とスプリントのコミットメントについての私の理解は正しいですか？
ええ、あなたはそれの要点を持っています。
そうでない場合、何が間違っていますか？
見落としているのは、ストーリーポイントは（doneを取得することです。スプリントの終わりまで、誰もがストーリーに取り組むことは不可能です。あなたが正しいことをしている場合、ほとんどの開発者は、ストーリーがテストされている間（そして開発が本格化しているため、スプリントの最中にテスターがいる）数日間「アイドル」になります。
開発者が猫のビデオを見ているのではなく、バグの修正、コード/ユニットテストの改善、プロセスに関するドキュメントの追加、バックログ内のストーリーのデザインや、開発チームが恩恵を受けることができるが、ストーリーにうまく適合しない他の何十もの有用なもの。
つまり、時間の50％を過大評価し、時間の50％を過小評価するとしても、スプリントに失敗したり、時間外に作業しなければならないという意味ではありません。これは、本当に見積もりを見落とさない限り、このような雑多な作業を行う時間があまりないことを意味します。しかし、雑多な作業は時間に敏感ではないので、それは大したことではなく、物事は長期的には均等になるでしょう。
最初に、速度は以前のスプリントから、または場合によっては最近のいくつかのスプリント（昨日の天気）の平均からであり、過去のすべてのスプリントの平均ではありません。もちろん、チームや会社からの履歴データがない場合は、最初のスプリントに対して妥当な値を考え出す必要があります。 2番目のスプリントでは、完了したストーリーポイントをスプリントに取り込みます。グラフ化すると、最初のいくつかのスプリントの変動が見られる場合があります（たとえば、最初のスプリントで17、2番目のスプリントで22、3番目のスプリントで26、4番目のスプリントで24）。チームワークと見積もりプロセスを正規化し、プロジェクト（テクノロジー、ドメイン）をよりよく理解するときに、それが期待されます。
それはあなたが調整しないと言っているのではありません。たとえば、休日の週が1週間ある場合は、必ず休業日を考慮してください。チームメンバーが休暇を取っていることがわかっている場合は、より少ない人数の作業を計画してください。もちろん、予定外のイベントも発生しますが、スプリントの回顧でそれらを説明でき、次のスプリントに持ち込むストーリーポイントの数にどのように影響するかを決定できます。
何をすべきかという点では、「スプリントを完了できませんでした」は「すべてのストーリーを完了しなかった」とは異なります。私にとって、スプリントの失敗は、出荷可能な製品を最後に生産しなかったことを意味します-ストーリーが完全ではなく、ビルドがなく、顧客に付加価値を実証できないか、ユーザー。
あなたが何をするにせよ、あなたは時間の経過とともに遅くまたは過度に働くべきではありません。これは持続可能なペースと呼ばれます（ Agile Alliance 、 Scrum Alliance ）。
問題がある可能性のある指標は、次の場合です。
- あなたのチームは持続可能なペースで働いていません。スプリント用に計画されたストーリーポイントを完了するには、残業する必要があります。追加のプレッシャーなしでスプリントを小さくして、予定どおりに完了します。
- あなたの速度は時間とともに正規化しません。速度が決して変化しないとは誰も期待していませんが、スパイクやスイングに気づいた場合は、スプリントの回顧でそれらに対処してください。それらの原因を突き止め、根本的な原因に対処します。
平均速度とスプリントのコミットメントについての私の理解は正しいですか？
残念ながら、スクラムでのスプリント計画に関するいくつかのことについて誤った情報を提供されています。まず、開発チーム（DT）は
...組織によって構造化され、権限を与えられて、自分の作業を整理および管理します。 - スクラムガイド
このことばは自己組織的です。これには、特定のスプリントで実行される作業を予測する作業が含まれます。 DTは各スプリントで何が機能するかについては通知されず、独自の作業を選択することができます。 DTは、予測を作成するために、履歴速度、十分に洗練された製品バックログ、次のSprintのDT容量などの情報を必要とする場合があります。 最終的には、DTがスプリントで何を達成でき、何を達成できないかを決定することで、予測が優先されます。どれだけの作業を行うかを知らされるべきではありません。
また、予測であり、コミットメントではないことに注意してください。c-Wordは、悪用に使用されていたため、スクラムガイドから削除されました開発チーム。予測が優先用語です。
ローエンドまたはハイエンドでスプリントの予測を見逃す確率については、それが重要であるとは思いません。ある時点で、より多くの分析を行っても精度は向上しませんが、現時点ではその点を超えていると思います。
また、スプリントは「キャンセル」のみ可能です。失敗することはありません。スプリントがキャンセルされるのは、スプリントの目標が完全に陳腐化し、無関係になった場合のみです。これは非常にまれなケースです。予測が正しくない場合は、落ち着いてスクラムをオンにしてください。ふりかえってください。次のスプリント、あなたの予測は良くなるでしょう:).
アジャイル方法論は会社ごとに異なり、1つの実装では別の実装とは大きく異なる場合があります。私は2つの会社でアジャイルのもとで働いてきました。最初の会社では私は彼らの測定基準をかなり真剣に受け止めましたが、2番目の会社ではまったくそうではありませんでした。つまり、誰もあなたのメトリックに注意を払っていないことを知っています。
とはいえ、スプリントの目標を達成できないことや、見積もりが不正確な場合はどうなるのか気になるようです。この種の懸念とOutlookはよくあることだと思いますが、特に重要ではありません。アジャイルは、とりわけ、いくつかのことを行うソフトウェア開発システムです。
- 開発者を動かし続ける
- 透明性を高めます
- リフレクションと段階的なプロセスの改善を可能にします
結局のところ、スプリントを誤って見積もったり、スプリントに失敗したりしたとしても、それほど大きな問題ではありません。社内でチームの上にいる人は、チームが一貫して動いていることをより懸念しており、プロジェクトは論理的に完了しています。
アジャイルの個人としては、チームの他のメンバーとの関連で効果的に完了している作業量に最も注意する必要があります。あなたが新しい場合、あなたはあまり生産的であると期待することはできませんが、あなたの雇用期間のある時点で、あなたは少なくともあなたのチームの一部と同等であるはずです。仕事を出力していなければ、実際には仕事をしていません。
平均速度とスプリントのコミットメントについての私の理解は正しいですか？
あなたの平均速度はその場にあります。私の経験では、これは完了の長期的な見積もりに非常に役立ちます。しかし、スプリント計画のコミットメントにはそれほど役立ちません。
スプリント計画のために私が従ったのは、バックログの一番上からストーリーを引き出して、チームがそれらを達成できるかどうかを決定することです。チームはこれを、直感、1/2日間のタスクへの分解、プロダクトオーナーからのプレッシャー、スプリントの目標との一致、最高速度（速度に基づく）、またはそれらすべての組み合わせに基づいて決定しました。
場合によっては、製品所有者がいくつかの項目をスキップして、さらに追加できるようにすることを許可しています。
時々、チームと製品所有者は、先に進むためにストレッチアイテムに同意します。
これは素晴らしい質問であり、チームが改善するために非常に重要です。トピックは欺瞞的であり、広く誤解されています。ストーリーポインティングの本来の目的は、ストーリーで定義された機能を完了するために必要な努力のレベル（LOE）を推定する、迅速かつ許容可能な正確な方法を見つけることでした。全体的な目的：チームが作業（プロジェクトなど）を完了するのにかかる時間を予測または予測する方法を提供します。 Velocityの理解は正しいです。これは、完了したスプリントごとの平均ポイントです（本当に完了）。したがって、配信するプロジェクトがあり、それが250ポイントであり、チームがスプリントあたり平均25ポイントである場合、プロジェクトは約10のスプリントにプラスまたはマイナスのバッファー時間を要します。
Ken Schwaberなどの一部の著名人は、速度とポイントは中長期の予測にのみ使用することを推奨しています。彼らは実際にスプリントで何ができるかについての第二の「健全性チェック」としてタスク時間を使用することを提案します。したがって、各スプリントのポイント数は、容量によって異なる場合があります。その他（私を含む）は、成熟したチームが容量を正確に予測できる非常に一貫したサイジングパターンに落ち着き、最終的には作業時間が無駄になる追加の負担になると考えています。 （チームがポイントとストーリーのサイズ設定を正確に理解するまで、新しいチームが少なくとも6〜12のスプリント、IMHOを実行することが重要です。）
最初の小さな誤りは、チームは速度を知っており、そのように多くのストーリーポイントを取り入れるべきだと言ったことです。実際、コーチはチームに10％から20％を差し引き、代わりにそのレベルにコミットすることを奨励しています*。したがって、チームがスプリントごとに25ポイントを完了する傾向がある場合は、スプリントを25ポイントに満たすのではなく、20〜22ポイントで停止してください。覚えておいてください。他の作業が完了したときにストーリーを取り込むのは完全にすばらしいことです。したがって、22ポイントに「コミット」して28を完了する可能性があります。それは素晴らしいことです。チームに「土のう」を勧めず、常にコミットするように注意してください。もっとストレッチできるかどうかを確認するためにストレッチすることに問題はありません。
さて、スプリント間の差異についてあなたのポイントに。 1つのスプリント、次に50、22、45、15、60の20ポイントを完了するチームを確認することは非常に一般的です（ただし、最適ではありません）。偏差を計算すると、50％の変動を示す場合がありますスプリント後は100％スプリントします。チームが1つのスプリントで15ポイント、次に次の60で完了するのはなぜですか？
それは、チームが何を成し遂げることができるか本当に知らないことを意味するかもしれません。 （ねえ、私たちは最後のスプリントで50ポイントを完了しました。このスプリントをもう一度行うことができます）。
または、製品の所有者がチームにオーバーコミットを強制している、またはスプリントの開始後に作業を追加しているなどの可能性があります。これらは、完了したポイントでこの激しい変動を引き起こしている可能性のあるアンチパターンの一部にすぎません。
この予測可能性の測定は、スクラムマスターが観察してチームの注意を引くための重要な測定です。 
多くの場合、彼らが1つのスプリントでいくつかのポイントを完了し、次のスプリントで多くのポイントを完了した理由は、私が「不完全な作業のローリングウェーブ」と呼んでいるものです。これは非常に一般的なパターンです：
製品の所有者は、日付を合わせる必要に迫られています。そのため、チームは多くの作業を実行する必要があると感じています。彼らは新しいチームとしてスタートし、実際に何ができるかわかりません。
つまり、スプリント1はスプリントを計画しており、フォーミングフェーズにあるため、すべての作業を完了することはできません。実際、彼らは仕事よりも不完全な仕事をしています。不完全な作業は開始されましたが、不完全です。それは次のスプリントに移動され、今回は未完成よりも多くの作業を行っています。次のスプリントまでに、その大量の不完全な作業が完了し、チームの自信が高まります。
製品の所有者は興奮しているため、再び負荷を増やします。このスプリントの終わりに、彼らは膨大な量の不完全な作業と、失望した量の完了した作業を持っています。
ここでは、スプリント後に交互のスプリントと完了したWAVES of Doneが表示され始めます。チームが何が起こっているのか理解していない場合、このパターンは数か月続くことがあります。しかし、平均して、スプリントごとに約24ポイント完了します。それで、彼らがオーバーコミットをやめたとき、何が起こりますか？
あなたは彼らがまだ24から26ポイントを完了することに注意しますが、キャリーオーバー作業は減少します。これで、チームの士気を損なう不可能な量の作業を完了しようとすることに圧倒される代わりに、チームはプロセスを改善し始めることができます。
時間の経過とともに、速度は増加し始めますが、完了対未完了の作業に大きな変動はありません。
チームに「余裕のある時間」を与えない場合、チームは無駄をなくし、より速く、より良くするための作業を実行する時間がありません。たとえば、Dev-Opsは起こり得ません。テストの自動化-そのための時間は誰にありますか？しかし、これらはまさにチームが速度を上げるために取り組む必要があるものです。