プロジェクト全体の完全性または速度に基づいて報酬を与える必要がありますか？
私が所属している開発チームは、数か月前から非常に大規模なプロジェクトに取り組んでおり、最近、アジャイルプラクティスを備えたかんばんボードをプロセスに実装し始めました。スループットが大幅に向上しました。そのとてもエキサイティングです！しかし、私たちは今、1つの苦労をしています。プロジェクトのチケットの総数はあり、スーパーバイザーは、チケットが100枚と50枚になったらインセンティブ（キャンディーとポップコーンボックス）をくれました。最初は素晴らしいアイデアのように感じましたが、新しいチケットは解決できる限り早く作成されたように感じられ、チームは私たちの進歩について気分が悪くなりました。だからここに私の質問があります：
プロジェクト全体の完全性または速度に基づいて報酬を与える必要がありますか？そして、完全性がある場合、どのようにしてそれをより到達しやすくしますか？
ああ、あなたは動くターゲットを撃ち、人々がそれが立っているふりをすることを期待しています！
あなたは目標に決心するべきです。残りのチケット数がメトリックである場合、特に外部で強制的にチケットを追加することは不公平です。
SCRUMでは、スプリントが計画されている場合、チームは全員一致で開始時にそのコンテンツにコミットします。その時点から、コンテンツはチーム自体によってのみ変更できます（またはスプリントはキャンセルされます）。そうでなければ、あなたはチームを制御不能に追いやり、真のコミットメントのすべての希望を殺します。
あなたはいくつかの同様の考えを採用するかもしれません。または、そのターゲティングシステムを削除し、問題を解決するために費やした健全な努力に報いるだけで、Xの進歩があったことを受け入れますが、その間にプロジェクトの範囲がそれ以上に拡大した可能性があります。
一方、マイルストーンを使用してスコープクリープを防止することをお勧めします。次のマイルストーンに新しいものを追加すると、元のメトリックスコアを維持することもできます。マイルストーンが完了したら、次のマイルストーンを計画できます。
システムを段階的に本番環境に提供していますか？そうでない場合は、システムの小さな部分でも導入することで士気を高め、顧客との良好な関係を構築することができます。これらの段階的な配信を行うことで、チームが集中できる期間が短くなり、目標がより到達可能であると感じるのに役立ちます。
報酬に関しては、速度に基づいて報酬を与えることはしません。ボスが修正されたバグごとにボーナスを与えると述べている古いディルバートの漫画を思い起こさせます。少しお祝いした後、ウォーリーは誇らしげに次のように宣言します。自分でミニバンをコーディングしてください。」チームに間違ったメッセージを送信すると感じる速度に基づいて報酬を与えるため、動作中のソフトウェアよりもメトリックを重視します。
乾杯！
SCRUM手法の使用を確約している場合は、固定のSprintバックログがあります。それは十分に確立されており、スプリントの期間中はバックログを凍結しておく必要があります。
バックログが凍結された後、このスプリントにチケットを含めることで、チケットのRoIが向上するという例外的なケースがある場合は、バックログを変更するのが理にかなっています。ただし、スプリント中にアイテムが適切な速度でクリアされているという理由だけでバックログにアイテムを追加し続けると、進行状況がマスクされ、プロセスが損なわれます。
ライフサイクルの間、多くのチケットが作成およびクローズされ、その数はこの期間中に増加または減少し続けます。
自分で解決したチケットの数は、解決した問題に関連する複雑さ、重要性のビューを提供しません。 2週間のスプリントで2つの複雑なチケットに行き詰まった場合、クローズされたチケット数のメトリックによって、かなり悪い評価になります。
チケット数はメトリックであってはなりません。バグのない機能リリースには、段階的にインセンティブを与える必要があります。そして、これらの増分は、スプリントとバックログの凍結に対して計画する必要があります。