使用Scrum 2.1流程模板，我注意到TFS中的Sprint Backlog查詢返回sprint的產品待辦事項項目和任務列表，但列表看起來相當稀疏，因爲我查看了它。在查詢定義中稍微查了一下之後，我意識到它首先在子鏈接上匹配，並根據迭代篩選子節點。這很重要，因爲幾個任務沒有被分配一個迭代，因此正在積壓。產品積壓項目和任務是否有不同的迭代路徑？
這讓我想到了 - 因爲衝刺的主要焦點在產品Backlog項目上，並且PBI旨在在單個衝刺期間啓動和完成，那麼爲什麼它對於任務有不同的迭代？有理由嗎？同樣，Sprint Backlog查詢是否有這樣的結構？
當你到達Sprint的結尾時，3/4 PBI已經完成實施並被接受，而最終的PBI完成2/3任務時，你需要作出一些困難的決定。你是否：
a）試圖撕掉最後一個PBI的代碼？
b）調用整個Sprint失敗並重新開始？
c）將未完成的子任務移動到下一個Sprint？
這是支持選項（c）。可能不是Scrum.org會推薦的內容，但這是它支持的場景。
這取決於你如何使用TFS來規劃你的衝刺。如果您打算使用TFS 2012 Agile Planning功能的全部範圍，則需要維護工作項迭代。 Scrum的板功能不受Sprint Backlog中查詢（或任何其他查詢的這個問題），它是由scheduling and areas settings在團隊的管理控制（在球隊的主場可用）：
迭代取決於PBI的大小：如果一個PBI（包括其所有子任務在內）可以適合單個sprint，則應該將迭代設置爲sprint（例如：\Release 1\Sprint 4\）。
如果PBI足夠大以跨越多個衝刺完成，請在發佈級別（例如：\Release 1\）及其子任務的迭代保持到衝刺級別。
如果在衝刺結束時你有一個可行的功能，剩下的工作應該分解成一個新產品待辦事項和與新PBI相關的任務。
如果你不這樣做，你最終會管理一個部分完成的PBI集合，這很難追蹤並拋棄你的報告。
我不知道你將如何有效地修改你的積壓和做sprint計劃，而無需將剩餘的工作分成新的PBI。
如果您經常遇到這種情況，請考慮將您的PBI分解爲更小的工作塊。請記住，理想的PBI大小是在您將PBI投入衝刺的3-5天內（我的規模爲3個故事點）或更小的範圍。
這裏是一個很好的博客，講述大小：http://www.agileforall.com/2009/12/agile-antipattern-taking-on-large-stories/
主題，討論規模和包括3-5天的引用：When to create PBI's from a feature request and where to draw the line into splitting them up?
在PBI以某種方式交付和不完整的情況下，是的，我可以看到這個工作;然而，我們對推動滿足所有驗收標準的工作非常嚴格，所以這實際上並沒有發生在我們身上。當我們沒有完成時，我們不推廣不完整的工作，而是根據剩餘的工作重新估計PBI，這有助於磨練我們的速度測量，因爲A）我們沒有得到先前的衝刺，B）根據我們還沒有做的工作，我們將在下一次衝刺中爲它分配努力。 – bwerks 2013-07-11 06:00:50
你也可以給PBIs提供3分或更少的建議嗎？這是我們沒有用過的東西;我們的團隊通常會使用更高的數字，儘管可能會有效（所有PBI都由同一個人使用相同的決策流程進行估算），但如果我們添加其他不同的人經驗。 – bwerks 2013-07-11 06:04:38
在我的回答中，我應該用理想的日子代替故事點。您提出了一個好的觀點，即故事點的比例尺是特定於進行估算的組的。我回去並相應地修改了我的答案。我用來建立持久規模的最佳方法之一是提出一個相當於3-5天時間範圍的示例故事，並以此爲基礎制定規模。它可以很容易地在規劃的高潮中重現故事，並將其與您估算的項目進行比較。 – 2013-07-11 21:12:27
我們的目的是保持在進程所涉方案低，並執行它們在分支機構中，所以基本上我們可以在PBI沒有按時完成時免費獲得a）。 PBI和剩餘的任務將被重新調整到積壓待重新安排的時間，然後重新評估其餘的工作。所以基本上，是的; A和C的組合，除了PBI帶有它，所以它們仍然處於同一衝刺階段。 – bwerks 2013-06-03 15:42:30