我正在處理一個在TFS 2010中使用敏捷模板的項目，並試圖決定何時應該爲任務分配迭代。目前我有大量的用戶故事，並且這些用戶故事已經被分配了一個迭代。然後，我爲每個用戶故事創建了任務並將它們鏈接起來。什麼時候應該爲TFS 2010中的任務分配迭代
所以，我的問題是我應該分配一個迭代的任務，即使通過用戶故事已經被分配了一個迭代？我該如何處理與用戶故事無關的「一般」任務？例如，我可以創建一個任務，涉及更新控件的引用或執行代碼審查。這些應該分配一個迭代，是否值得管理兩類任務，即分配給用戶故事的那些任務和那些不是？
當您的團隊致力於完成這些任務時，將設置迭代。如果在檢查完決定推遲某些任務之後，請將迭代設置爲稍後的衝刺。
從MSF for Agile Software Development v5.0的excerpt MSDN上：
您可以指定區域和迭代領域對微軟解決方案框架（MSF）的過程模板基於 最多的工作項目。您 指定創建 工作項目時或在審覈產品或迭代待辦事項期間的區域和迭代字段的值。如果 您稍後將工作項目推遲，則應相應地更改其迭代 。
而且從工作項定義guide：
在該地區和迭代列表中，單擊相應區域和 迭代，或留空這些字段的 規劃會議在以後分配。
關於一般任務，有特殊的工作項目，如Issue (Agile)和Impendiment (Scrum)。
你絕對應該檢查出this資源，這是由A.Bjork提出的一種方式來處理你的問題。
我們傾向於將UserStories分配給未來的迭代，並且在迭代開始之前，在「計劃撲克」發生時 - 我們生成&將任務分配給團隊。
這樣做至關重要，因爲TFS能夠對您的工作保持適當的跟蹤：插入「小時」的唯一工作項是「任務」類型 - 因此，這是用於顯示工作效果的Burndown圖表的功能。
如果您在衝刺期間向團隊成員添加了另一個任務，那麼TFS將會將其視爲「計劃外工作」（模擬中斷！），並且會混淆您團隊速度的計算。
嘗試將長期運行的任務分解爲更小的任務，這些任務將適用於每個衝刺。例如，如果你有一個巨大的重構任務，你可以爲每個sprint分配幾個子任務，然後把傘任務分配給最後一次迭代 - 重構完成。
除了時間追蹤（僅基於任務）之外，您還需要在迭代積壓中添加對衝刺非常重要的所有其他工作項目，這樣您就可以在將來追蹤每個問題時，用戶故事等被考慮。