私は、アジャイル思考ではない大規模な企業の一部である小規模なアジャイル開発チームで働いています。現在、私たちはスクラムを実践しており、時折、スプリントのコミットメントを超えています。
私の質問は、スプリントのコミットメントを超えた場合、バーンダウン チャートをどのように処理しますか? 次の 2 つのオプションが考えられます。
私のチームにとって究極のソリューションは、ビジネスにとって明確で、開発者にとって真の価値をもたらすものです。これまでのところ、これらのソリューションはいずれも完全には機能していません。
私の意見では、バーンダウン チャートがマイナスになることはありません。仕事が終わったら、何もせずに椅子に座ったままにします。つまり、バーンダウンはゼロのままです。
実際に何かを行う場合は、それをタスクのリストに追加する必要があります。つまり、バーンダウンは上昇し、スプリントのワークロードに追加したタスクが完了すると再び下降します。
スプリントが終了する前に元のワークロードが完了しているスプリントは、新しいタスク (バグ修正などの単一のタスク、または 1 つ以上の新しいユーザー ストーリー) が再び追加されると、小さなスパイクが表示されるはずです。もっと余裕があります。
ただし、チームでこれが頻繁に発生する場合は、ベロシティを常に過小評価しているように見えるため、最初からより多くのタスクに取り組み始める必要があります。早期に終了してより多くのタスクを引き受けることが悪いことだと言っているわけではありませんが、これが多くのスプリントで発生する場合は、チームが最初からコミットしていないことを示しています。彼らがスプリントに失敗することは絶対にないと確信しています。
それがあなたの製品所有者にとって問題ないなら、それでいいのです。私がプロダクト オーナーで、あるチームが常に早く終了するのを見たら、最初からより多くのタスクにコミットしてもらうようにします。これは、意図したよりも少し耳障りに聞こえるかもしれません。
バーンダウンは、スコープがコミットメント内に残っていることを示します。配信超過のためにコミットメントに何かを追加する場合は、チャートに記録している数値にそれを追加します。その結果、配信超過のチームは、ゼロに向かって進み、チャート化されたタイムボックスの終わりまでそこにホバリングするバーンダウンが発生します。
実際に提供しているものを示すために、代わりにバーンアップまたは累積フロー図を検討してください。
編集
スプリントに項目を追加すると、残りの作業の見積もりを更新して、スプリント バーンダウン チャートに反映します。
代替テキスト http://www.movingsummit.co.uk/images/burndown_chart.JPG
しかし、他の回答で指摘されているように、これは、残りの作業の見積もりが変更されたことを示しており、理由ではなく (作業を再見積もりしたのか、それとも作業を追加したのか?)、完了した作業の累積ではありません。ただし、これは問題ではないかもしれません。
完了した作業の累積を表すには、バーンアップ チャートの方が適しています (リリース レベルでバーンアップ チャートを使用します)。ワークロードに対するバーンアップにより、完了した作業の進捗状況と、要件の増減 (およびこれが完了の予測にどのように影響するか) を表すことができます。
代替テキスト http://www.movingsummit.co.uk/images/burnup_chart.JPG
Y軸を延長すると、スプリントの目標を超えていることが誰にでも明確になります。あまりやり過ぎないので、通常は大きな問題ではありません。
それが定期的に発生する場合、またはかなりの量を超えた場合は、見積もりプロセスに問題があります。おそらく、あなたはビジネスの「非アジャイル」な側面に対処することに過度に慎重です。みんなを連れて行ってみてください。
バーンダウン チャートの Y 軸をゼロ未満に拡張することは、リリースの進行状況を追跡するための十分に確立された方法です。
リンクされた画像では、リリース バーンダウン チャートを見ることができます。リリース スコープに追加されるものはすべてゼロを超えています。
スプリント バーンダウン チャートに対してまったく同じことを行うことはお勧めしません。残りの作業に新しい作業を追加するだけで、明らかにバーンダウンがしばらく進行します。スプリント バーンダウン チャートを提示するためにホワイトボードを使用している場合は、適切なコメントで新しいストーリー/要件を追加した時点の場所にラベルを付けることをお勧めします。そうすれば、何が起こったのか、なぜバーンダウンが発生したのかが完全に明らかになります。
バーンダウンで持続的にマイナスになる場合は、常に過大評価していることを示しているため、作業が「早すぎる」ことになります。これを修正するには、推定値に 1 未満の係数 (つまり、0.75、3/4) を掛け始めます (これの正しい用語を忘れました - それは「スケーリング」ですか?)。これを 1 ～ 3 スプリントで実行し、結果にどのように影響するかを確認します。各開発者に適切な要因を得るには、数回の反復が必要になる場合があります。これは、通常のスプリントにより多くの時間を費やすことができることを意味し、早期に終了する必要はありません。
私はここで異議を唱えます :-) 次のシナリオを考えてみてください: チームはストーリーの作業を開始し、特定の量の作業が計画されていないことに気付き、その作業を完了するためにタスクを追加します。バーンダウンは上昇しますが、正確には正当な理由ではありません。その場合、スコープの変更ではなく、「間違った見積もり」であり、チームの観点からは何の違いもありません。メッセージはまだ次のとおりです。「これは完了する必要がある作業の量」。
プロダクトオーナーはどうですか？配信超過であることをどの程度伝えたいですか? チームが 2 つのケースを区別し、ふりかえりでそれらを使用して、次回の見積もりを改善する方法を分析したり、最初からより多くのことをコミットしたりすることは、どの程度重要ですか? 代替のバーンダウン チャート ( http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown ) を定義するために同様のアプローチが使用されているため、チャートのベースを変更してさらにバーンダウンすると、範囲が拡大し、バーンアップすることが明確に示されます。スプリントのどこかでストーリーに取り組み始めたときに、チームが新しいタスクを発見したのかもしれません ;-)
チャオ
アンドレアト
