双击以后，我们将会看到“Iteration Backlog”工作簿，如下图所示。在这个工作簿中，你可以管理来自于那些工作表的所有迭代——把任务安排到特定的迭代中，在“燃烧工作表”中，针对燃 烧图设置各个迭代的日期，为团队成员(私人事件或假期)设置中断，为团队成员做Capacity计划。(和2008版本相比，这是一个巨大的改进，仅次于 按等级划分的工作项)

　　通过Product Backlog，你可以通过选择“Configure”下拉列表修改underlying query。如下图所示：

　　当你从那个下拉列表中选择“List”的时候，你将会看到一个对话框，这个对话框可以让你选择不同的underlying query，如下图所示：

　　当我们选择Settings工作表的时候，我们可以为这个迭代输入一些日期，而且，这个工作表还可以计算天数，如下图所示：

　　接下来，我们可以选择“Interruptions”工作表，在这个工作表中，我们可以为计划的中断输入一些日期，以及这个特定的迭代中的一些假期。在“Capacity”工作表中，可以从各个capacity中减去这些日期。

　　接下来。我们看一看比较重要的“Capacity”工作表。仅次于“Burndown”工作表，在任何一个迭代中，这个工作表都是第二有用的工作 表。请注意，我已经安排到“Iteration Backlog”中的任务都反映在这里了，你也可以看到在“Interruptions”工作表中指定的假期也被考虑进来了(也就是说，对于这个迭代来 说，有效的工作时间是15天，而不是19天)。还有，Hours/Day字段被用来表示某个团队成员的“理想”工作时间(根据我的经验，一般是6个小时， 所以，开发者们进行估算的时候一定要注意，真正的估算值是不包括饮水机旁的闲聊时间，上洗手间的时间，或与其他重要的人进行沟通的时间的。)

　　在“Individual Capacity”图表中，绿色的区域是团队成员可以工作的时间的总数。在这个迭代中，蓝色的部分是实际被分配的工作量。在理想情况下，分配给一个团队成 员的工作应该和他可以完成的工作量相当。如果一个团队成员落后了，会通过Over字段(这个字段是基于每天录入的时间的，我稍后将会讨论这方面的内容)反 映在这个图表中，然后，这个工作表中的工作可以被重新调整。另外，任何时间你都可以回到“Interruptions”工作表，为某个团队成员增加更多的 时间，然后再回到”Capacity“工作表重新进行调整。

　　至于团队成员任务的时间录入，在客户的重压之下，这是我的主要工作。十分简单，不用每天都录入时间，燃烧图和报告都是没有意义的。在Task工作项中，你将会看到所有重要的字段，如下图所示：

　　一般来说，当团队成员们坐下来，把整个团队当成一个整体来进行估算的时候(我推荐这样做)，每个团队成员都会做一个初步的估算。当团队成员开始完成 某个特定的任务的时候，每天，他们都在推进这个任务，他们将会输入要完成这个任务，还需要多少个小时，以及在那天完成的小时数。原始的估算值不应该被改 变，因为TFS(Team Foundation Server)会使用它来计算还没有列入计划的工作。如果在某一天“Remaining”字段的值增加了，而不是减少了，那么就像我上面讨论的那样，这会 被反映到“Iteration Backlog”的“Individual Capacity”工作表中。

　　我们最后要介绍的工作表是“Burndown”，在项目进度方面，它是一个起决定性作用的视图。团队的主管每天都会使用这个视图来追踪某个迭代的项目进度。这里我就不详细讨论了，因为有很多地方可以学到如何更好地理解一个燃烧图。但是，以后我可能会添加一些新想法的。