タスクを自動化した後、反復タスクのストーリーポイントのサイズは変わりますか？

スクラムの状況は次のとおりです。

1. 特定のタスク（バックエンドのデータテーブルの実装）は頻繁に発生します
2. 多くの場合、テーブルには類似しているがカスタム機能があります
3. 各テーブルの実装には約1週間かかります（8ストーリーポイント）
4. 最終的に、チームは4週間かけて再利用可能なコンポーネントを作成します
5. 新しいテーブルの作成はほぼ瞬時に

私の質問： 出力/複雑度が変更されていないため、新しいテーブルストーリーはまだ8ですか？それとも、労力が最小限なので1ですか？

私の研究：ジェフサザーランドとスクラムトレーニングを受けたとき、ストーリーポイントは出力を測定するため、ストーリーはまだ8であるという理解を残しました。PMはまだ同じテーブルを取得していますが、5倍速く配信されています。それは本当の速度の改善です（同じ作業を行うがより高速）

しかし、私の理解が正しいことを確認したいと思います。何か助けはありますか？正式なスクラムの定義を探しています。私はscrum incのサイトを調査し、「半分の時間で2倍の作業を行うアート」を試してみましたが、私の理解が正しいか間違っているかを示すドキュメントが見つかりません。

ありがとうございました！

更新 私は本当に正式なスクラム当局による文書へのリンクを探していました。以下の答えの多くは単なる人々の意見なので、この質問は誤解を招くと思います。

更新1/22：SCRUM INCの応答

「同等の価値を提供するために同じままです。チームの速度は重要な尺度です。プロセスの改善により、速度が向上するはずです：https : //www.scruminc.com/velocity/ "--- Scrum Inc.レスポンスTwitter経由

私の短い答え：

スクラムの作成者であるジェフサザーランド博士は、スライド6の彼のポイント対時間ウェビナーでこの質問に直接回答しています。

ポイントとは？ポイントは、チームの出力の尺度です。相関関係がありますが、必ずしも努力と同じではありません。

Scrum Inc.のCEOであるJJサザーランドは、速度を正しくするためのレッスンで、より直接的に答えています。

チームが特定のストーリーを実装するのが上手になったからといって、ポイント値は変わらないはずです。

私の長い答え：

追加のソース。この質問は物議を醸しているので、他の回答で述べられている懸念のいくつかに答える研究があります：

はい。スクラムの目標は速度を上げることです

ソース1

速度は時間とともに変動する傾向がありますが、原則として、スプリントごとに約10％増加する傾向があります。- JJのサザーランド

ソース2

Scrum Incの「Velocityに関するレッスン」のスライド5は 、時間の経過とともに12倍改善された速度チャートを示し、Y軸として「ポイント」を使用してチャートに「出力改善」というタイトルを付けます。

ソース3

ScrumLab.scruminc.comにアクセスして、Metrics Webセミナーをご覧ください。これは、速度の改善、幸福度の指標、ポイントあたりの収益を使用して、会社のパフォーマンスを測定する方法を示しています。多くの遅いチームが、速くなるとがらくたを生み出すだけだと不平を言うのを聞きます。これは、製品所有者がポイントごとの収益を2倍にする責任を負わないためです。速度を2倍にし、ポイントあたりの収益を2倍にすると、会社は4倍の収益を上げます。これは皆を幸せにします。そのため、3つのメトリックが必要です。- ジェフサザーランド

はい。ストーリーポイント測定出力/生産

ソース1

プロジェクトデリバリーの管理指標は、ジェフサザーランドが彼の決定的な記事でストーリーポイントが時間よりも優れている理由で生産単位である必要があります

ソース2

経験値が大幅に増加し、ストーリーがより簡単に見えるため、チームがストーリーをより低い値で推定し始めた場合、Velocityは改善されないようです。これが、時間単位の見積もりが機能しない大きな理由の1つです。- スクラム社CEO、JJサザーランド

番号。速度を上げても予測可能性は損なわれない

まず、POまたはエグゼクティブの予測可能性は非常に重要ですが、生産性はさらに重要です。ほとんどのPOは、生産レベルを維持するか、わずかな予測可能性を犠牲にして生産性を大幅に向上させるかを選択した場合、生産性の向上を選択します。そうは言っても、チームがスプリント計画に昨日の天気の推奨スクラムパターンを採用している場合、トレードオフは誤った選択です。

常識を使用して...チームが週に10個のウィジェットを生成する場合、週に40個のウィジェットを生成する方法を見つけます。その速度は4倍に向上しました。POは、同じ時間内に4倍のウィジェットを取得しています。その平坦な速度を呼び出すことは、言葉の定義に反しています。

はい。チーム全体が不正行為をした場合、システムのゲームは可能です

最後に、システムをゲームすることは可能ですが、任意のシステムをゲームすることは可能です。スクラムは、注文されたバックログからプルし、個々の開発者ではなくチームベースで速度を測定することにより、個々の開発者のチェリーピッキングストーリーを最小限に抑えます。開発速度で開発を測定する場合、スクラムを実行していません。また、ストーリーをグループとしてグルーミングすることにより、見積もりを通じてシステムのゲームを軽減します。見積もりをサンドバッグするには、グループの前で行う必要があり、グループはあなたと共謀しなければなりません。しかし、システムでゲームをしたい場合は、どのプロセスを使用してもかまいません。スクラムは、一緒に目標を達成することに興味がある、意欲的で有能な4〜6人のチームに依存しています。しかし、システムをゲームするために仕事をだましている従業員がいる場合、あなたのプロセスは問題ではありません。

バックエンドテーブルストーリーは、8ポイントの労力を必要としません。

「ストーリーポイントは、要件を完了するための労力の相対的な見積もりを提供するために、個々のスクラムチームによって決定および使用される相対的な測定単位です。」

scrum.org

バックエンドテーブルのストーリーを8点で推定し続けると、スプリントごとのエフォートの測定として速度をゆがめます。

また、1点の労力しか必要としないことがわかっている作業に8点を割り当て続けることは、不誠実です。

速度の増加は目標ではありません。目標は信頼できる計画です。

ストーリーポイントは、フィードバックループのツールであり、時間の経過とともに、典型的な速度を教えてくれます。これにより、スプリントで実際に採用できるポイントがわかります。速度は時間の経過とともに少しドリフトする可能性がありますが、変化が速すぎると役に立たなくなります。速度が突然増加しても、まだ何をしているのか分からないということだけがわかります。したがって、速度を一定に保つ必要があります。これは、推定が適切であり、次のスプリントに適している可能性があることを示しています。

あなたは出力が一定ではないことを知っています、あなたは今あなたがはるかに速くテーブルを作成できるという事実を知っています。したがって、ストーリーポイントを成果物にリンクすることを主張すると、計画サイクルの目的が完全に無効になります。

繰り返しになりますが、速度は生産性とは関係がなく、速度の増加は祝う理由にはなりません。ストーリーポイントは、最終的にはスプリントのチャンクです。それをより現実的にするために、一部のチームは、誰もが理解できるよく知られているタスクを定義し、それを標準のストーリーポイントタスクと呼んでいます。言うまでもないことですが、標準的な作業が簡単になると、すべてが変化し、誰もが1つのストーリーポイントの新しい意味に適応する必要があります。正しくて便利な方法は、チームにとって同様に挑戦的な新しい標準タスクを定義することです。

ストーリーポイントは、ストーリーの実装にどれだけの労力が必要かを反映しています。彼らは努力の予測です。努力量が減れば、ポイント数も減ります。

ポイントは推定に役立つツールであることを忘れないでください。それ以上でもそれ以下でもありません。報酬や成果を測定する指標ではありません。これらは、ストーリーの目標を達成するために必要な作業量を推定する方法にすぎません。

このタスクは、最初は8ポイント、つまり約1週間かかったと言います。ここで、スプリントが1週間の長さであるとしましょう。そのため、計画では、8ポイント分のストーリーを引き出すことになります。このストーリーを8ポイントに保つと、スプリントでこの1つのストーリーを完了することのみを計画できます。実際の時間が40時間ではなく1時間の場合、残りの39時間はどうするのでしょうか。ストーリーポイントが不正確なため、スプリントの非常に貧弱な計画を作成しました。

ストーリーが1ポイントとしてより正確に表現されている場合は、現在の1週間のスプリントでさらに7ポイントを引き込むことができます。それはあなたの現実をより厳密に反映しているようです。したがって、ストーリーのサイズを変更することは、計画を立てるのに役立つので意味があります。

あなたは質問の中で速度を向上させたいという願望を述べましたが、それは実際にあなたがすべきことではありません。少なくとも、文字通りの意味ではありません。あなたの生産性は自然に向上しますが、速度の値を計画するために、かなり一定に保つ必要があります。

効果について考えてください。あなたが5人のチームで、スプリントの速度が100ポイントで、全員が20ポイントを処理することを合理的に期待しているとします。これで、このタスクは簡単になりましたが、まだ8ポイントを獲得しています。チームメンバーの1人は、これらのタスクのうち5つをつかんで2日で実行し、残りの8日間は自分の足を机に置き、40ポイントのタスクを処理して全員を打ち負かし、ボーナスを獲得します。他の誰もが上司に噛まれます。

問題がなければ、このタスクのポイントを変更しないでください。そのような状況は望んでいません。

同じ数のポイントを持つすべてのタスクは、開発者に同じ量の時間がかかると予想されます。

そして、私はここでのナサニエルの答えに完全に同意しません。ポイントを維持すると、一部のタスクはより速く実行されますが、他のタスクは実行されないため、速度は完全に予測不可能になります。そのため、加速タスクのあるスプリントはあなたに巨大な速度を与え、次のスプリントは再びダウンします。

それはまた、あなたが推定する方法ではありません。私が10のかなり似たタスクを持っていることがわかっている場合、そもそもそれらに同じポイントを与えません。「タスクを実行し、同様のタスクを迅速に実行するためのツールを構築する」ことを目的とした最初のポイントには多くのポイントを与え、次に繰り返されるタスクにははるかに少ないポイントを与えます。

ジュニア開発者が開始するとき、または開発者が別のチームから参加するときとは別の状況です。開発者が学習するため、他の時間に速度を上げます（最初に仕事をする方法、または特定のことについて知る必要があるすべてのビット）事業）。