私の会社では、3つの異なる開発チームがあり、新しく開始されたスクラムです。彼らは主にスクラムを行う際に同じ道をたどりますが、スプリントバーンダウンチャートになると、行動は異なります。
1つのチームがストーリーポイントを(その中に推定ポイントを含めて)収集し、それらをタスクと推定ポイントに分割しました。つまり、10ポイントのストーリーには3つのタスクがあり、それぞれ4、1、および5ポイントが推定されます。彼らはタスクを完了すると、バーンダウンチャートをそれぞれ更新しました。結果は、比較的スムーズなバーンダウンチャートでしたが、失敗したストーリーの場合、それはどういうわけか誤解を招きました。実際にはエンドユーザー向けではない進歩が見られました。
反対に、他のチームはタスクのポイントを推定せず、ストーリーが完全に完了したときにバーンダウンチャートを更新しました。その結果、階段の形状図ができました。数日間、チームは進歩せず、突然大きな一歩を踏み出しました。
問題は、バーンダウンチャートを作成するための正しい方法は何ですか?どのアプローチがそれに近かったのですか?
バーンダウンチャートの対象者は誰ですか?
2番目の方法は、ストーリーの完了後にクレジットを取得する方法であり、スクラムの背後にあるアイデアと一致しています。不完全なストーリーの扱いについて、ソフトウェアエンジニアリングに関していくつか質問があります( 1 、 2 、、 4 ) 。タスクではなくストーリーは、ユーザーにとって価値のあるものを表します。一歩下がって、スプリントをストーリーのコレクションであり、一定量の機能を提供することを約束する場合、それらのストーリーの完了を示すものとしてバーンダウンチャートを表示すると、製品の所有者とユーザーがどれだけ近いかを示すのに役立ちますあなたはそれらの責任を果たすことです。
最初の方法では、タスクの完了後にクレジットを取得するので、内部使用、特にスクラムマスターとプロジェクトチームの方が便利です。これらは、タスクの観点から考え、このビューの情報をフィードバックとして使用して、スプリントの見積もりと計画を改善できる人々です。
聴衆に適切なアプローチを使用することを検討してください。わからない場合は、質問して話し合ってください。無駄のないアプローチによるものですが、無駄を省いてください。アーティファクトを作成し、効果的である必要がある儀式を用意し、他の利害関係者とチームとして協力して、それらのアーティファクトと儀式を決定します。
個人的に私は最初の方法を好みます。これにより、進捗状況と実行された「作業」の感覚が向上します。また、「ユーザーストーリー」への分割はいくぶん恣意的です。現在のスプリントに予定されていた作業量と実際にどれだけの作業が行われたかを確認したいと思います。
しかし、それは問題ではありません。各チームは、自分に最適なスイートを選択する必要があります。これはアジャイルの背後にある最も基本的なアイデアの1つです。チームはそれ自体を測定および管理するための最良の方法を見つけます。
2番目の方法の背後にある動機もわかります。彼らは、実際に行われた作業をあまり気にせず、ユーザーのためにどれだけの機能や機能を完了したかを気にします。これは、短くてシンプルなストーリーや、技術的な観点からの単純なプロジェクトにより適しているようです。