スクラムでチャートをバーンダウンするには、いくつかの方法があります。
一部の人々は、スクラムのバーンダウン チャートとして残された未完成のストーリーのストーリー ポイントを使用することを提案しています。
長所: 終了したストーリーのみがチャートを下げる
反対: チャートは最初は下がらず、その後急速に下降します
残りのタスク数を使用することを提案する人もいます
長所: チャートが下に移動し、フィニッシュ ラインの上にあるかどうかを確認できます
コントラ: 下に移動して、最後に 10 個のタスク (ハード タスク) が残っていると言うことができますが、まだ 1 つのストーリーは完了していません。完成したストーリーのみが製品所有者にとって良いものであるため、失敗しました。
未完のストーリーのポイントと未完のタスクチャートの両方を持つことが解決策ですか?
スプリントのバーンダウンに残り時間を使用しています。チームは毎日進捗状況を確認できます。平らな部分がある場合は、実際に発生したものよりも。
リリース バーンダウンでは、ストーリー ポイントを使用しています。リリース計画は、機能の完成度に関するものであり、時間はスプリント レベルで追跡されます。プロダクト オーナーは完成したストーリーに関心があります。
タスクの数が無駄です。この数は、開発者に「自由」を与える場合は特に、毎日変更できます。合計時間を変更することなく、タスクをより小さな部分に分割できます。そんな統計は役に立たない。それは何を示していますか？スプリントの目標に影響しますか?
私の意見では、タスクの追跡は、追跡に対する最適なアプローチではありません。私の経験では、ストーリーが実際にそのタスクの合計になることはめったにありません。
また、ストーリーを見積もる際にブレインストーミングを行うことに価値を見出していますが、ストーリーを追跡する衝動がまったくないほど十分に小さいストーリーを使用することを好みます。実際、特定されたすべてのタスクの半分が完了したとしても、スプリントが何らかの価値を提供することを保証するものではないため、完了したタスクの功績を認めることは非常に誤解を招く. 利害関係者が最終的に関心を持っているのは、予測された価値のどれだけが実際に提供されるかということです。
したがって、ストーリーを追跡し、ストーリーをさらに細分化することで、より正確なフィードバックが得られ、価値のない配信のリスクが軽減されます。
実際、小さなストーリーで作業する場合、スプリントのバーンダウン チャートにはあまり価値がありません。カードの壁のストーリーが「すること」から「進行中」、「完了」へと移動するのを見るだけですべてがわかります。あなたが必要とする情報。ただし、私の経験では、リリースのバーンダウンは非常に価値があります。
通常、依頼したクライアントのストーリーに対して時間 (見積もり、実際、完了までの見積もり) を追跡する必要があります。これにより、いくつかのことが可能になります。
また、完了したストーリーを独自のバーンダウンのために追跡しますが、指摘されているように、これはスプリントの開始時にプラトー効果につながる可能性があり、有用な情報をほとんど教えてくれません (並行して十分に行っていないこと以外は) ）。
Burndowns (or even "burn ups") should only indicate work remaining.
If you've half done a story you can't ship it, and it doesn't count. If you end the spring with a story half-done - tasks that were done in it don't count if you're measuring velocity.
Just chart stories left to be completed.
This is a tougher measure but there's no use massaging the figures - scrum is supposed to communicate bad news so that things will get fixed.
タスクを含めないと、行が横ばいになり、何も行われていないように見えるので、両方を行います。
ストーリーが完了するまでに 2 日かかる場合、2 日間は横ばいであり、チームが黙っているかどうか、または作業が増加した (したがって、タスク時間が急増する) かどうかを判断する方法はありません。
もちろん、タスク ラインは、ストーリーの完成に貢献せずに急落する可能性があります。これは、開発者が自由にタスクを選択できる場合に発生する可能性があるアンチ パターンです。
タスクのサイズが異なる可能性があるため、残りのタスクの数を追跡することはあまり役に立ちません。
チームが 10 個のタスクを完了し、バックログ アイテムがない状況に陥ってはなりません (実際、これは 10 人の開発者がいる場合に発生する可能性があります)。すべての開発者は、バックログを完了するまで、別のバックログ アイテム (ストーリー) からタスクを取得するべきではありません。彼が最初に行ったストーリーも含まれます - 他のストーリーからのタスクが、開始されたストーリーからの残りのタスクよりも難しい場合のイベント。
バーンダウンには「残り時間」を多用しました。チームは常に、時間によるバーンダウンの追跡は時間追跡システムに近く、管理のオーバーヘッドを追加し、人間をロボットに変換しない限り、実際には正確ではないことに気付きます.
タスクのバーンダウン (合計タスク、新しいタスク、完了したタスク) を使用しています。はるかに優れています。完了したタスクや新しいタスクのサイズがわからないのは事実です。しかし、チームは毎日ミーティングを行っており、そこで問題が発生します。また、大きなタスクを作成しないようにチームを指導しています (最大 4 ～ 6 時間)。また、日別の新しいタスクと完了したタスクを含む別のグラフを追加しました。チームは、タスクごとのバーンダウンは、時間を使用するよりも理にかなっていることを発見しました。
チームがタスクでストーリーを分解することの価値を理解したら、ストーリーによるバーンダウンを試してみたいと思います。そのため、最大 5 または 8 ストーリー ポイントの小さなストーリーを作成します。Jeff Sutherland のブログによると、これはチームのパフォーマンスを向上させるための大きな一歩です。
また、バーンダウンはあくまでも「進捗状況をひと目で表したもの」であることをお伝えしておきます。チームと PO にとって最も重要で、さらに関連性が高いのは、タスクについて毎日言及されていること + ストーリーの進捗率 + 障害のリストです。しばらくすると、経営陣とチーム メンバーはバーンダウン (またはバーンアップ) をあまり気にしなくなります。
スプリントのバーンダウンに残り時間を使用する - スプリントの計画中に、完了の定義に従って、ストーリーを完了するためのすべての作業を見積もります - 毎日、開発者とテスターは、すべての作業の残り時間を再見積もりします (上向きまたは下向きに変化します) - 追跡残り時間によるスプリントのバーンダウン - スプリントの進捗状況の優れた指標
バックログのすべてのストーリーを分類するのではなく、スプリント計画ワークショップの次のスプリントのストーリーのみを分類するため、これはリリース バーンダウンには適していません。そのため、ストーリー ポイントのバーンダウン (ポーカー セッションの計画中にチーム全体で導き出された相対的なサイズと複雑さの値) を使用します。これは、リリースに向けた進行状況を示す優れた指標です。
タスクを使用するのは、はるかに粒度が高いためです。ストーリーの完了のみをグラフ化すると (2 週間のスプリントごとに 5 ～ 10 回実行します)、1 日または 2 日ごとに変化が見られるだけであり、おっしゃるように、スプリントの開始時にはほとんど変化しません。
私のチームが見つけたもう 1 つの便利な点は、「To Do」、「In Progress」、「Ready for QA」、および「Validated」のそれぞれに 1 つの線を含む積み上げ折れ線グラフを使用することです。このようにして、バックアップを作成しているプロセスの任意のフェーズを簡単に確認できます。