タスク間の「技術的な」依存関係が原因でバーンダウンが発生します。各タスクにさらに焦点を当て、追加のオーバーヘッドを受け入れる必要がありますか？
新しい機能が登場します。必要な機能をカバーする9つの異なるユーザーストーリーで構成されています。これらのうちの3つを以下に示します。
- ユーザーとして、私は人を追加できるはずです...
- ユーザーとして、私は人を編集できるはずです...
- ユーザーとして、私は人を削除できるはずです...
これらの3つの問題は、それぞれ約20spになります。
課題は、これら3つの問題が実際には1つの問題として扱われることです。したがって、火曜日に20 spが燃焼し、木曜日に20 spが燃焼し、次の月曜日に20 spが燃焼するというニースのバーンダウンを行う代わりに、最終日（月曜日など）に60spが燃焼するのを確認できます。
理論的には、（私は信じています）これは間違っています。実装される各問題は、問題が完了したら本番環境にデプロイできるように「アトミック」である必要があります。これは理にかなっています。上記の私のシナリオでは、編集や削除を行わなくても、本番環境に「追加」をデプロイできます。
ただし、技術的な観点からは、3つの実装を「組み合わせる」ことは理にかなっています。または、少なくとも追加して編集します。それらは多くのロジックを共有しており、最初に「追加」を完了してから翌日「編集」を開始する場合は、「追加料金」が必要になる場合があります。
問題は、これを継続して、これらの場合に腐敗したバーンダウンを行う必要があるのか、それともより多くのオーバーヘッドを考慮して理論的な部分に焦点を当てる必要があるのかということです。 「原子」の問題。
それとも他のことを考えるべきですか？
最善の方法は、アトミックな性質に固執することです。つまり、最後にすべてではなく、一度に1つのユーザーストーリーに取り組むことです。
関連しているがアトミックなストーリーを一度に実行すると、いくつかの問題が発生する可能性があります。テストするストーリーが落ち込んだ後、突然のフラッドが発生し、テストのワークロードが不規則になる可能性があるため、テストがより困難になり、時間がかかります。また、バグがどのストーリーに関連しているかを見つけるのが難しくなることも意味します。
ただし、あなたの例では、これが常に可能であるとは限りません。ユーザーを追加するストーリーは、他の2つのストーリーよりも前に完了する必要があります。これは、ユーザーを追加できずにユーザーの編集/削除をデバッグすることが難しいためです。
アトミックストーリーの重要性は、ストーリーが完了した後にアプリケーションをデプロイできる状態にする必要があることです。ビルドが壊れていない、すべてのテストに合格しているなどです。つまり、その時点でのアプリケーションが機能完了、これは1つのストーリーが終了したことを意味しますが、機能全体がまだ機能しているとは限りません。編集や削除をせずにaddをデプロイしたいですか？おそらくそうではありません... FEATURE（複数のSTORIESで構成できます）が完了したときにデプロイします。 1つの機能= 1ストーリーの場合もあれば、1つの機能= 12ストーリーの場合もあります。
アトミックストーリーは、複数のストーリーを同時に処理できることも意味します。これは、大規模なチームでは重要です。その意味で、追加と編集は相互に依存しているため、アトミックとは見なされません。それは何も悪いことではなく、次に「編集」ストーリーを実行する必要があるという事実を考慮して、最初の「追加」ストーリーのコードを書くことにも問題はありません。
これらの種類の機能については、「追加」の話に重きを置く見積もりがよくあります。このストーリーでは、データベーステーブルの作成、新しいドメインオブジェクト、新しいページの作成などを行います。 「編集」ストーリーは、テーブル、オブジェクト、ページなどがすでにあるため、ストーリーポイントがはるかに少なくなります。見積もりの際には、これを考慮に入れています。
バーンダウンについて：ストーリーポイントに基づいてバーンダウンを描画することはありません。スプリントで何百ものストーリーを実行しているのでない限り、タスクに基づいてバーンダウンする方が理にかなっています。ストーリーはストーリーポイントで見積もられ、チームが必要と考える作業量を示します。これにより、ある程度の計画が可能になります（「スプリントにいくつのストーリーを収めることができるか」）。次に、チームはスプリントのストーリーをタスクに分割し、それらをバーンダウンします。年次ステータスレポートのようなことをしているとき、ストーリーポイントを焼き尽くすことができます。