我正在尋找一種方法來手動調整TFS任務startdates，使我的burndown顯示正確。TFS Burndown授權日期
本質上，迭代具有固定的開始/結束日期，並且一些用戶故事直到迭代完成時纔得到填充。
這使得burndown在道路上有一個凹凸，所以它看起來像我們低於目標。
我有TFS數據庫的完全訪問權限，並且想知道我需要寫什麼查詢才能將我的任務回溯到迭代開始。
我讀過的地方是它是System.AuthorizedDate控制burndown圖表。
任何幫助表示讚賞。 J
您在使用System.AuthorizedDate時正確無誤。
您將無法通過公共API更改System.AuthorizedDate。它不會讓你。並且您無法通過SQL更新命令更改System.AuthorizedDate日期並保持受支持的狀態。正式地，微軟不允許這樣做，並且仍然保持微軟支持你的能力，除非SQL在他們的指導下進行了改變，例如通過支持事件。
我懷疑微軟的支持事件會產生更新查詢，因爲它不是一個缺陷，我後來解釋它可能會把你放在一個非常糟糕的地方。您能否在適當的表上創建一系列更新來反向更新System.AuthorizedDate？毫無疑問。它甚至可能工作，但我不確定如果你敢這樣做，它是否會起作用。原因是工作項目按創建順序接收System.Id編號。我知道在版本控制中，系統中有一個期望值，即較高的變更集編號必須具有較晚的提交日期（無法記起確切的字段名稱），而不是任何較低的變更集編號。如果在系統中對工作項目有類似的期望，我也不會感到驚訝。您可能會發現，如果對SQL中的工作項目中的字段進行這樣的更改，會在各個位置呈現錯誤或意外結果 - 我可以想象未來的升級甚至更新只是簡單的轟炸而無法執行。這都是假設，因爲除非你希望你的環境處於不受支持的狀態，否則你不會通過SQL來改變它。
外部創建自己的burndown評估不同我不知道在這些條件下滿足您的期望目標的手段。