スプリントの最後にJiraチケットを複製する-努力とポイントを引き継ぐ
私は、しばらくの間、方法論のようなアジャイルスクラムでJiraと協力してきました。よくあることは、チケットが見積もられて開始されることです。スプリントの終わりまでに、作業の95％が完了します。通常、最終的に発生するのは、このチケットが次のリリース反復にドラッグされて5％完了することです。
これに関する私の問題はそれです：
- スプリントで起こっていることの画像を歪めます
- 反復で実際に発生した労力の量を反映していない
- 持ち越される努力の量を過大評価する
- これは、関与または必要とされる努力を反映していないため、人々をやる気にさせます。
これに対する1つの解決策は、スプリントの最後にチケットを複製してから、ポイントバスーンに次の推定値を再割り当てすることです。
- 何が行われたか
- あと何をすべきか
例えばあなたが8ポイントで指されているチケットを持っていると言ってください、そしてそれはいくつかのマイナーな変更を除いてほとんど終わっています。チケットは90〜95％完了していると言えます。次に、チケットを複製して1として持ち越し、前のチケットを1つ減らして、前のイテレーションに残します
スプリントの最後に90％-95％完了した大きなチケットがたくさんある場合は、何か問題があります：
レッドフラグ＃1：多くのものがスプリントに詰め込まれているが終了していない
危険信号＃2：大きなチケットがたくさんあります
レッドフラグ＃3：何らかの理由で、これが「最後の」進行状況の10％に影響します
最初にそれらに対処しましょう：
1：残されたチケットを繰り返し持っている場合、速度を過大評価するか、タスクのストーリーポイントを過小評価します。両方のことが時々起こり得ますが、これは永続的な状況であってはなりません。
2：95％の「ビッグ」チケットが多数ある場合は、多くの「ビッグ」チケットがあることを意味します。これは、タスクを十分に細かく分解していないことを示している可能性があります。
3：10％が足りないことについてどういうわけか私は不思議に思っています...多くのタスクの最後で永続的に問題が発生している（テスト担当者がテストを実行できない、ハードウェアが不足している）か、90％を完了するタスクです3日で作業が完了し、残り3日で残りの10％。 90％が本当に90％を意味し、ボトルネックがないことを確認します。
今あなたに質問します：
いいえ、行いませんnotチケットのクローンを作成し、番号を変更します。経験から学び、チケットをより小さく、より良いチャンクに分割します。一握りの半日チケットが持ち越されると、それが発生する可能性があります（特に、スプリントが終了する前に時間に余裕があり、より多くのタスクを引き込んだことに気付いた場合）、ただし、半日はわずかスクラム計画の誤差範囲。
[〜＃〜] done [〜＃〜]でないタスクには、利害関係者に対して-ゼロの値があることに注意してください。 90％だけ水密であるボートは（長い間）動作/フロートせず、90％だけである機能も機能しません[〜＃〜] done [〜＃〜]（つまり、実装され、テスト済み、など）
完全に完了していないストーリーを次のイテレーション（またはバックログ）に置くことの背後にある考えは、チームが未完成の作業の功績を認めるべきではないということです。これにより、イテレーションが終了する前に実際に作業を完了するインセンティブがチームに与えられます。
スクラムのバーンダウンもこのように機能します。関連する価値が完全に作業を終了することによって実現された場合にのみ、燃焼ポイントが表示されます。 95％完了とは、作業が完了しておらず、利害関係者に引き渡す準備ができていないことを意味します。そのため、なぜ（ポイントを燃やすことによって）支払いを受けるのでしょうか。そして、あなたはそれが95％完了したと言いますが、私の経験では、これらの最後の数パーセントは残りよりもはるかに時間がかかるので、95％完了はおそらく残りの作業の7ポイント（8点中）に対応します。
ある反復から次の反復に作業を引き継ぐことが一般的であり、チームの動機に影響し始める場合は、作業が反復内に完了しない理由に対処する必要があります。
人が作業を完了するのに十分なコラボレーションを行っていない可能性があります（新しいタスクを開始するのは、他のタスクを実行するために最終レビューを行うよりも楽しい）、またはストーリーが単に大きすぎる。
あなたが8ポイントで指されているチケットを持っているとしましょう、そしてそれはいくつかのマイナーな変更を除いてほとんど終わっています。チケットは90〜95％完了していると言えます。次に、チケットを複製して1として持ち越し、前のチケットを1つ減らして、前のイテレーションに残します
チケットが計画されたスプリントの終わりまでに終了しない場合、それは本質的に問題ですか？いいえ。なぜですか。 推定値に欠陥がある可能性があるため。遡及のポイントは、開発計画の不変の客観的に完全な測定を達成できると考えるのではなく、予測できなかった問題を繰り返し改善することです。
同じ哲学を使用して、チケットの95％が完了したことを明確に述べることはできません。そして、それを不動の事実のように構築することは確かにできません。
スプリントとチケットは、分割できない単位にすることを目的としています。つまり、小数ではなく整数値でカウントします。何かが1スプリントより長くかかる場合、2スプリントが必要であると言います。 1.25スプリントがかかったとは言いません。
同様に、チケットはユニット全体です。終了するか、終了しません。 95％は事実上何も意味しません。
できる一部のサブディビジョン（95％）が完全に完了し、他のサブディビジョン（5％）が完了しない方法で、チケットをさかのぼって分割し始めますか？承知しました。開発者がどの部分が完了し、どの部分が完了していないかを知ることは役に立ちますか？もちろん。しかし、それはチケット内の簡単なドキュメントによって実現でき、それ以上のチケット管理は必要ありません。チケットを細分する技術的な問題はなく、純粋に数字のジャグリングトリックです。そうすることの唯一の利点は、あなたが提供しようとしている実際の製品に焦点を合わせるのではなく、スプレッドシートで数値をよく見せることです。
スプリントは、繰り返し行われる「プロジェクトの状態」の評価を実施するためだけでなく、頻繁に行われるprevent継続的な評価のためにも存在し、実際の開発作業から著しく気が散ることになります。不可分な単位であると思われるものに対していくつかの数の魔法をかけようとすることは、数を美しく見せるためだけであり、その哲学に違反します。