平均スプリントよりも50％悪い状況をどのように処理しますか？

スクラムを正しく理解していれば、次のスプリントでチームが引き受けることができる仕事を決定する方法は次のとおりです。

1. 過去数回のスプリントで完了したポイントの数を平均します。

2. この量は平均速度です。次のスプリントでは、多くのストーリーポイントを取り上げます。

これは平均であるため、履歴が繰り返される場合、このスプリントは、ストーリーポイントが少なすぎる可能性が50％あり、ストーリーポイントが多すぎる可能性が50％あります。

50％のケースでは、できる限り多くのストーリーポイントを使用しました。

• スプリントを完了できません。これは、スプリントのコミットメントを半分の時間で満たさないことを意味します。

• 追いつくために余分に働く。問題は、これが一方向にしかラチェットしないことです。スプリントを達成し、完了したストーリーポイントの数はそれを反映します。私たちは常に時間をかけて終了するので、私たちの平均は常に多くのストーリーポイントを達成し、遅れている点まで上昇傾向にあります。

平均速度とスプリントのコミットメントについての私の理解は正しいですか？

もしそうなら、平均より遅れているスプリントの50％に対して何をすべきでしょうか？

そうでない場合、何が間違っていますか？

平均速度とスプリントのコミットメントについての私の理解は正しいですか？

うん、あなたはそれの要点を持っています。

そうでない場合、何が間違っていますか？

あなたが見落とし事はストーリーポイントは、あなたが得るものであるということです行わ。誰もがスプリントの最後までストーリーに取り組むことはほぼ不可能です。正しいことをしている場合、開発者のほとんどは、ストーリーがテストされている間、数日間「アイドル」状態になります（開発が本格化するにつれて、スプリントの真ん中にいるテスター）。

あなたの開発者は猫のビデオを見ているのではなく、バグを修正し、コード/ユニットテストを精査し、プロセスに関するドキュメントを追加し、バックログのストーリーや開発チームが恩恵を受けることはできても、ストーリーにうまく収まらないその他の便利なもの。

したがって、時間の50％を過大評価し、時間の50％を過小評価しますが、スプリントに失敗したり、残業したりする必要があるわけではありません。つまり、この雑多な作業を行う時間はあまりないということです（実際に見積もりを見逃さない限り）。しかし、雑多な作業は時間に敏感ではないため、それは大したことではありません。

平均速度とスプリントのコミットメントについての私の理解は正しいですか？

残念ながら、スクラムのスプリントプランニングに関するいくつかの情報について誤った情報を受け取っています。まず、開発チーム（DT）は

...組織が独自の作業を編成および管理するための構造化および権限付与。- スクラムガイド

この言葉は自己組織化です。これには、特定のスプリントで行われる作業を予測する作業が含まれます。DTには、各スプリントで何が機能するかが通知されるのではなく、独自の作業を選択する権限があります。DTは、予測を作成するために、過去の速度、洗練された製品バックログ、次のSprintのDTキャパシティなどの情報を必要とする場合があります。最終的には、スプリントで何が達成でき、何が達成できないかをDTが決定することが、予測に勝つべきです。彼らがどれだけの仕事をするかを彼らに伝えてはならない

コミットメントではなく予測であることに注意してください。Cワードは開発チームを悪用するために使用されていたため、スクラムガイドから削除されました。予測は優先語です。

ローエンドまたはハイエンドでスプリントの予測を逃す可能性に関して、私はそれが重要であるとは思わない。ある時点で、より多くの分析はより良い精度をもたらさず、私たちは今その時点を超えていると思います。

また、スプリントは「キャンセル」のみ可能です。決して失敗することはありません。スプリントの目標が完全に時代遅れで無関係になった場合にのみ、スプリントはキャンセルされます。これは非常にまれです。予測が正しくない場合は、落ち着いてスクラムを続けるだけです。振り返ってください。次のスプリント、あなたの予測は良くなります:)。

まず、ベロシティは以前のスプリントから得られます。または、過去数回のスプリントの平均ではなく、最近のスプリントの平均（昨日の天気）から得られることもあります。もちろん、チームや会社からの履歴データがない場合は、最初のスプリントで妥当な値を見つける必要があります。2回目のスプリントで、完成したストーリーポイントをスプリントに取り込みます。グラフ化すると、最初の数個のスプリントにバリエーションが見られる場合があります（たとえば、最初のスプリントで17、2番目で22、3番目で26、4番目で24）。チームワークと見積りプロセスを標準化すると同時に、プロジェクト（テクノロジー、ドメイン）をよりよく理解することが期待されます。

それはあなたが調整しないということではありません。たとえば、休日の週である週がある場合は、必ず仕事が休みの休日を考慮してください。チームメンバーが休暇を取っていることがわかっている場合は、作業する人を少なくするように計画してください。もちろん、予定外のイベントも発生しますが、スプリントの回顧展でそれらを説明し、それが次のスプリントにもたらすストーリーポイントの数にどのように影響するかを決定できます。

何をするかについては、「スプリントを完了できなかった」と「すべてのストーリーを完了しなかった」とは異なります。私にとって、スプリントの失敗とは、最終的に出荷可能な製品を生産しなかったことを意味します-ストーリーが完全ではなく、ビルドがなく、顧客に付加価値を実証できない、またはユーザー。

何をするにしても、遅刻したり時間をかけて過度に働くべきではありません。これは持続可能なペース（アジャイルアライアンス、スクラムアライアンス）と呼ばれます。

問題がある可能性のある指標は次の場合です。

• あなたのチームは持続可能なペースで働いていません。スプリントのために計画されたストーリーポイントを完了するには、残業が必要です。スプリントを小さくして、圧力をかけずに時間通りに完了します。
• 時間の経過とともに速度が正規化されません。速度が決して変化しないことを期待する人はいませんが、スパイクやスイングに気付いた場合は、スプリントの回顧展でそれらに対処してください。それらの原因を特定し、根本原因に対処します。

アジャイルの方法論は会社によって異なります。ある実装では、別の実装とは大きく異なる場合があります。私はアジャイルのもとで2つの会社で働いてきました。私がいた最初の会社では、彼らはメトリックをかなり真剣に受け止めていましたが、2番目の会社ではまったくそうではありませんでした。あなたが知っているすべての人にとって、誰もあなたのメトリックに注意を払っていません。

とはいえ、スプリントの目標を達成できないこと、または不正確な見積もりがある場合に何が起こるかが心配のようです。この種の懸念と見通しは一般的だと思いますが、特に重要ではありません。何よりもアジャイルは、いくつかのことを行うソフトウェア開発システムです。

1. 開発者を動かし続ける
2. 透明性を高める
3. リフレクションと段階的なプロセス改善が可能

結局のところ、スプリントを誤って見積もったり、スプリントに失敗したりしても、それほど大きな問題ではありません。社内でチームの上位にいる人々は、チームが常に動いていることをより懸念しており、プロジェクトは論理的に完成しつつあります。

アジャイルの個人として、チームの残りの部分を参照して、効果的にどれだけの作業を完了しているかに最も関心を持つ必要があります。初心者の場合、生産性が高すぎるとは期待できませんが、雇用期間のある時点で、少なくともチームの何人かと同等である必要があります。仕事を出力していない場合、実際に仕事をしているわけではありません。

平均速度とスプリントのコミットメントについての私の理解は正しいですか？

平均速度はスポットオンです。私の経験では、これは長期の完了予測に非常に役立ちます-大量のバックログがあると仮定します。ただし、スプリント計画のコミットメントには役立ちません。

スプリント計画で従ったプロセスは、ストーリーをバックログの先頭から引き出し、チームがそれらを達成できるかどうかを決定することです。チームは、腸の感触、1/2日のタスクに分解、プロダクトオーナーからのプレッシャー、スプリントゴールとの整合、ベスト推測（速度に基づく）、またはそれらのすべての組み合わせに基づいてこれを決定しました。

ときどき、プロダクトオーナーがいくつかのアイテムをスキップして、さらにアイテムを追加できるようにしていることがあります。

チームと製品の所有者は、ストレッチするアイテムを事前に同意してから移動する場合があります。

これは素晴らしい質問であり、チームが改善するために非常に重要です。このトピックは欺de的であり、広く誤解されています。ストーリーポインティングの当初の目的は、ストーリーで定義された機能を完了するために必要な努力レベル（LOE）を推定するための迅速かつ許容できる正確な方法を見つけることでした。全体的な目的：チームに、プロジェクト（プロジェクトなど）を完了するのにかかる時間を予測または予測する方法を提供します。Velocityの理解は正しいです。完了したスプリントごとの平均ポイントです（本当に完了）。したがって、提供するプロジェクトがあり、それが250ポイントであり、チームがスプリントごとに平均25ポイントである場合、プロジェクトはおよそ10スプリントにプラスまたはマイナスのバッファー時間を要します。

Ken Schwaberなどの一部の著名人は、速度とポイントは中長期の予測にのみ使用されることを示唆しています。彼らは、スプリントで実際にできることの2番目の「健全性チェック」としてタスク時間を使用することを提案しています。そのため、各スプリントのポイント数は、キャパシティによって異なる場合があります。他の人（私を含む）は、成熟したチームが容量を正確に予測できる非常に一貫したサイジングパターンに落ち着き、最終的にタスク時間は無駄な追加の負担になると考えています。（チームがポイントとストーリーのサイズを正確に理解するまで、少なくとも6〜12スプリント、IMHOで新しいチームを実行することが重要です。）

最初の小さなエラーは、チームが速度を知り、その多くのストーリーポイントを取り込むべきだと言ったことです。実際、コーチはチームに10％から20％を差し引き、代わりにそのレベルにコミットすることを推奨しています*。したがって、チームがスプリントごとに25ポイントを完了する傾向がある場合は、スプリントを25ポイントに満たすのではなく、20〜22ポイントで停止します。覚えておいてください：他の仕事が終わったときに物語を持ち込むことは完全に素晴らしいことです。したがって、22ポイントに「コミット」して28ポイントを完了することができます。それは素晴らしいことです。チームが「サンドバッグ」をして、常にコミットしている状態にしないように注意してください。私たちがもっとできるかどうかを確かめるためにストレッチをすることは何の問題もありません。

さて、スプリント間の分散についてのあなたのポイントに。20ポイントを1スプリント、次に50、22、45、15、60を完了するチームを見るのは非常に一般的な（しかし最適ではない）パターンです。偏差を計算すると、50％のスイングを示す場合がありますスプリント後に100％スプリントに。チームが1つのスプリントでわずか15ポイントを完了し、次に次のスプリントで60ポイントを完了するのはなぜですか？

それは、チームが何ができるかを本当に知らないことを意味するかもしれません。（ねえ、私たちは最後のスプリントで50ポイントを完了しました、私たちはこのスプリントを再び行うことができます）。

または、製品所有者がチームにオーバーコミットを強制している、またはスプリント開始後に作業を追加しているなどを示している可能性があります。

この予測可能性の尺度は、スクラムマスターがチームの注意を引き付けて注目するための重要な尺度です。 多くの場合、1回のスプリントで数ポイントを完了し、次のスプリントで多くのポイントを完了した理由は、「不完全な仕事の波動」と呼ばれるものです。非常に一般的なパターンを次に示します。

製品の所有者は、日付を満たすよう圧力を受けています。そのため、チームは多くの作業を完了する必要があると感じています。彼らは新しいチームとしてスタートし、彼らが実際に何を成し遂げることができるのか確信が持てません。

そのため、スプリント1はスプリントを計画しており、フォーミングフェーズにあるため、すべての作業を完了できません。実際、彼らは仕事よりも不完全な仕事を持っています。不完全な作業は開始されていますが、不完全です。次のスプリントに移動し、今回は不完全よりも多くの仕事をしました。次のスプリントまでに、大量の不完全な作業がDONEに落ち、チームの自信が高まります。

製品所有者は興奮しているので、彼らは再び負荷を増やします。このスプリントの終わりには、膨大な量の不完全な作業と、失望するほどの量の完了した作業があります。

ここでは、スプリント後の完了と不完全な交互のスプリントの波が見え始めます。チームが何が起こっているのか理解していない場合、このパターンは数か月間続く可能性があります。しかし、平均では、スプリントごとに約24ポイントを完了します。では、彼らがオーバーコミットをやめたらどうなりますか？

彼らはまだ24から26ポイントを完了しますが、持ち越し作業が削減されることに注意してください。今では、チームの士気を損なう不可能な量の作業を完了しようとして圧倒される代わりに、チームはプロセスの改善を開始できます。

Done-vs-Incompleteでの大きな変動なしに、時間の経過とともに速度が増加し始めます。

チームに「余裕時間」を与えない場合、彼らは無駄のない、より速く、より良い仕事をする時間を持てなくなります。たとえば、Dev-Opsは発生しません。テストの自動化-だれにその時間があるのか​​！？しかし、これらはチームが速度を上げるために取り組む必要のあるものです。