我正在寻找一种方法来手动调整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评估不同我不知道在这些条件下满足您的期望目标的手段。