現在、(指摘された)ユーザーストーリーに基づいてタスクを作成しています。次に、タスクをTFSのユーザーストーリーにリンクし、かんばんボード全体に移動します。これは一般的なアプローチのように聞こえますか?また、タスクについてどのように報告しますか?タスクが指定されていないため、速度が良くありません。スプリントで3つのタスクのうち2つを完了する可能性があるので、これについてどのように報告しますか?
ストーリーをタスクに分割し、それらのタスクを全面的に移動するというアプローチは、スクラムでは非常に標準的な方法です。
タスクはビジネスに価値をもたらさないため、TFSのタスクレベルでレポートする必要はありません。ビジネスに価値を生み出すのは完成したストーリーです。
ストーリーがスプリントの終了までに完全に完了していない場合、そのストーリーはバックログに戻って、将来のスプリントで再度計画する必要があります(優先順位によっては次のストーリーになる可能性があります)。
チームがほとんどのストーリーを完了するのに問題がある場合は、いくつかの理由が考えられます。
OK。ユーザーストーリーで解決策があると思います。それらをさらに細かく分類して、ビジネスにとって価値があるようにする方法を理解できます。私たちの問題の一部は、一度に多くの作業に取り組むことです。これは、数回のスプリントでは速度がほとんどなく、全員の作業が完了すると大幅にジャンプすることを意味します。私たちのアプローチは、すべてユーザーストーリーにリンクされているタスクを全面的に移動することです。 TFSでユーザーストーリーとタスクを作成します。タスクは子としてリンクされます。ビジネスがすべてのスプリントで進捗状況を確認する必要がある場合は、ストーリーが管理可能であることを確認する必要があります。また、チーム全体がストーリーに取り組んで、スプリントでそれを完成させようとする必要があります。物事があまりリラックスしていない場合は、ビジネスがタスクの進行状況を確認できる限り、ユーザーストーリーを実行させることができます。繰り返しますが、それがあなたのためにどのように機能するかについてのすべてです。重要な問題は、ビジネスが何をどのくらいの頻度で見る必要があるかということだと思います。また、かんばんには、タスクとそれに関連するユーザーストーリーが同じカードに記載されています。また、開発に関してすべてのタスクが完了すると、実際のユーザーストーリーカードがテストレーンに配置され、リンクされたタスクカードがボードから削除されると考えています。製品の所有者がTFSにユーザーストーリーをロードすると、リンクされているすべてのタスクのステータスが表示されます。興味のある方は、TFSでユーザーストーリーに使用する作業項目の種類は「機能的」です。タスクを追加する場合は、ユーザーストーリーを読み込み、必要に応じて子タスクを追加します。