Scrum for Team System v3 を使用して TFS 2010 をインストールしました。ワーク アイテム テンプレートでは、ストーリー ポイントを含むプロジェクト バックログ アイテムを入力する必要があり、リンクされたタスクを PBI の子として追加する必要があります。チームの個人を割り当てたり、残りの推定時間を更新したりできるのはタスク レベルです。
個々のタスクが時間を使用している場合、PBI 項目で使用されるストーリー ポイントの重要性は?
子作業項目タスクが時間ではなくストーリー ポイントのバーンダウンを使用するように、このテンプレートをカスタマイズした人はいますか? また、個々のタスクからのストーリー ポイントの総数が、ストーリー ポイントの合計の読み取り専用フィールドとして PBI 項目にまとめられるとよいでしょう。
御時間ありがとうございます。
私が勤務している会社でも、TFS 2010 と新しい Agile Template v5.0 を使用しています。私たちは次の方法でプロセスを進めており、ある程度の成功を収めています。これまでに行った中で最も困難なことは、ストーリー ポイントが時間の形式に直接対応するものではないという考えを全員に理解してもらうことです。
プロセスはリリース計画ミーティングから始まります。これは週に 1 回行われますが、一度も行ったことがない場合は、おそらく最初に 1 つから始めたいと思うでしょう。私たちには 3 つのチームがあり、プロダクト オーナーとチーム リーダーだけが会議に参加しています。このリリース計画ミーティングで、私たちチーム リーダーのみがプランニング ポーカーをプレイして、ストーリー ポイントをユーザー ストーリーに割り当てます。
次に、チームとプロダクト オーナーおよび利害関係者がスプリントで 1 つのユーザー ストーリーを実行することに同意するスプリント計画ミーティングを行います。ストーリー ポイントは、数回のスプリントの後で、1 回のスプリントで実際にどれだけ多くのことを実行できるかを示します。各ユーザー ストーリーについてプロダクト オーナーと話し合います。通常、スクラム マスターは、チームの説明を聞きながらユーザー ストーリーにタスクを追加します。
今、製品所有者と利害関係者は去ります。次に、チームは作業を分割し、各タスクに時間 (元の見積もり) を割り当てます。それが完了した後、チームは通常 2 週間で作業を開始しますが、スプリントが 2 週間に収まらない場合は、3 週間のスプリントを行うことができます。
作業中、元の見積もりに関係なく、完了時間と残り時間を調整します。これまでに 3 時間費やし、3 時間後にはさらに 2 時間かかると考えている場合、それがタスクの内容であり、元の見積もりが 4 時間であったことは問題ではありません。
「ボックスに入力」し、テンプレートを調整していないため、すべてのレポートとキューブが機能します。レポートに大きな調整を加える必要はありませんし、本当に優れた指標を取得するために何かを行う必要もありません。よりシンプルなテンプレートが必要な場合は、Visual Studio ギャラリーの「Microsoft Visual Studio Scrum 1.0」を参照してください。確かにシンプルですが、統合された Office ドキュメントの方法で提供されるレポートとサポートは少なくなります。
TFS アジャイル テンプレートを使用することになりましたが、作業項目タスクで「作業時間」を使用し、それらをストーリー ポイントとして参照することになりました。