スクラム 2.1 プロセス テンプレートを使用して、TFS のスプリント バックログ クエリがスプリントのプロダクト バックログ アイテムとタスクのリストを返すことに気付きましたが、レビューしたところ、リストはかなりまばらに見えました。クエリ定義を少し調べてみたところ、最初に子リンクで一致し、反復に基づいて子をフィルタリングしていることに気付きました。これは、いくつかのタスクがイテレーションに割り当てられておらず、バックログに残っていたため、重要でした。
ただし、これにより、スプリントの主な焦点は製品バックログ項目にあり、PBI は単一のスプリント中に開始および終了することを意図しているため、なぜタスクが含まれていることが理にかなっているのだろうかと考えました。別の繰り返し？理由はありますか？また、Sprint Backlog クエリをこのように構成する理由はありますか?
スプリントを計画するために TFS をどのように使用しているかによって異なります。TFS 2012 Agile Planning機能をすべて使用する場合は、作業項目の反復を維持する必要があります。スクラム ボード機能は、スプリント バックログ クエリ (またはその他のクエリ) の影響を受けません。チームの管理 (チームのホームで利用可能) のスケジュールとエリアの設定によって制御されます。
反復は PBI のサイズによって異なります。すべての子タスクを含む PBI が 1 つのスプリントに収まる場合、反復はスプリントに設定する必要があります (例: \Release 1\Sprint 4\)。
PBI が複数のスプリントにまたがって完了するのに十分な大きさである場合は、そのイテレーションをリリース レベル (例: \Release 1\) に保ち、その子タスクをスプリント レベルに保ちます。
スプリントの終わりに到達し、PBI の 3/4 が実装されて受け入れられ、最終的な PBI で 2/3 のタスクが完全に実装されている場合、いくつかの難しい決定を下す必要があります。あなたは：
a) その最後の PBI のコードを抜き取ろうとしていますか?
b) スプリント全体を失敗と呼び、最初からやり直しますか?
c) 未完了の子タスクを次のスプリントに移動しますか?
これはオプション (c) をサポートしています。おそらく Scrum.org が推奨するものではありませんが、それがサポートされているシナリオです。
スプリントの最後に実行可能な機能がある場合、残りの作業は新しい製品バックログ項目と新しい PBI に関連付けられたタスクに分割する必要があります。
これを行わないと、部分的に完了した PBI のコレクションを管理することになり、追跡するのが難しく、レポートが破棄されます。
残りの作業を新しい PBI に分割せずに、バックログを効果的に整理し、スプリント計画を実行する方法がわかりません。
この状況に頻繁に遭遇する場合は、PBI をより小さな作業ブロックに分解することを検討してください。PBI をスプリントにコミットする時点で、理想的な PBI サイズは 3 ～ 5 日 (私の尺度では 3 ストーリー ポイント) またはそれ以下の範囲にあることを忘れないでください。
サイズについて説明しているブログは次のとおりです。
サイズについて説明し、3 ～ 5 日への参照を含むスレッド:機能要求から PBI を作成するタイミングと、それらを分割するための線引きはどこですか?