梳理和估计积压工作
基于敏捷做法，在产品所有者将创建一个产品后的高级计划，您的团队或修改积压工作和估计项目。 通过定义更精细的项目修改积压工作，添加项表示附加工作，如处理，或者解决处理 bug。 在估计工作量级别之前，您的团队必须与同意成功为每个项目含义。
遵循虚拟 Fabrikam 纤程团队成员的本主题继续 指南，在创建产品积压工作并运行冲刺 (sprint) 周期与敏捷做法。 团队使用 team Web access 积压工作和任务的页。
茱莉亚，作为产品所有者，获取了她的高级可视化对象，并模式客户支持门户网站为一系列积压工作项目中 创建或添加到产品积压工作所述。 团队现在可以修改和估计积压工作。
备注
如果您使用 Visual Studio scrum 2.0 过程模板，请创建 产品积压工作项 描述用户情景、要求，或者该项目的某个可交付结果的一部分。如果您使用 MSF for agile software development，您创建 用户情景。如果使用 MSF for CMMI process improvement，您创建 要求。
主题内容
检查验收条件和估计工作量
获取峰值或非层工作于积压工作
支持估计的工作量其他资源
要求
若要执行本主题中的过程，您必须具有：
Visual Studio 高级专业版、Visual Studio 旗舰版 或 Visual Studio 专业测试工具版。
您必须是团队成员，因此，您必须具有 编辑此节点中的工作项 权限设置为 允许。 默认情况下，因为团队组是团队项目的 参与者 组的成员，团队的所有成员拥有此权限。
若要查看 积压工作 页，您必须属于 team Web access 的 完全 访问权限组。
有关更多信息，请参见管理我的个人资料和查看我的权限和对 Team Web Access 中的功能的访问权限。
检查验收条件和估计工作量
提供尽可能详细的信息，以描述不仅积压工作项或 bug，还描述用于验证的标准该项是否执行或 bug 已修复。 对于验收条件是显式定义的，您的团队可以一起协作然后评估根据处理其每个积压工作项采用。
.png "验收条件和积压工作项中的工作量")
打开 Team Web Access，导航到团队项目的主页或协作，然后选择 查看积压工作。
双击要查看的工作项，或者选择并按 enter。
检查并更新 说明 和 验收条件 字段时积压工作项或 bug 的团队共识。
提示
基于过程模板可能有所不同这些字段的名称用于创建团队项目，例如，含验收条件的描述 或 说明。
有关验收条件:在迭代或冲刺 (sprint) 结束时，您的客户或产品所有者将用户情景视为已完成接受或拒绝它。 在冲刺 (sprint) 开始之前，应尽可能明确地说明客户的验收条件。 当然，用户情景可能不适用于非预期的原因不接受。 但是，在定义验收条件的团队和客户之间的对话将有助于确保您的团队了解客户的预期。 验收条件可用作验收测试的基础，以便您可以更加高效地评估是否已完成用户情景。
基于估计方法您的团队使用，请输入 工作量的值。 在项目的早期阶段，您只需要粗略估计。
备注
基于过程模板可能有所不同这些字段的名称用于创建团队项目，例如，工作量 混乱，情景点 for agile 和 大小 CMMI 的。
有关情景点:在他的书籍，敏捷估计与规划，Cohn 定义情景点 mike 指定这种：“情景点度量单位是表示用户情景的总大小，函数或其他部分工作”。Cohn 解释情景点不直接转换为小时数的特定数字的相对值。但情景点可帮助团队量化用户情景的基本大小。这些相对估计不够精确，因此只需少量工作即可确定它们，但随着时间推移它们将越来越精确。通过用情景点进行估计，您的团队现在将能够提供用户情景的基本大小，在以后团队成员要实现用户情景时可以更细致地估计工时数。有关更多信息，请参见估计。
选择 保存并关闭 按钮。
获取峰值或非层工作于积压工作
您的团队有时候需要执行不是用户情景或产品要求的一个直接实现的工作。 此项工作被称为“附加工作”。 附加工作的三种常见类型为研究、Bug 积压问题和过程或工程改进。 若要创建高峰出现 Team Foundation，请创建积压工作项或用户情景，并可以选择包含“附加工作”在标题中，与其他用户情景一起然后按优先级排列它在产品积压工作。
.png "在产品积压工作页上添加面板")
在产品积压工作页中添加面板中，键入说明在需要执行的峰值或非层工作的 标题 字段，然后选择 添加 按钮。
提示
如果添加 panel 未出现，请选择 添加项目 链接打开所示。
定义以下操作的考虑非层工作：
处理:当团队具有有关必须回答的用户情景时的未解决的问题，在用户情景完全分解为各项任务并估计之前，应对实现的该处理回答这些问题。 例如，在查看团队确定情景，“作为一名常飞旅客，我可以预订奖励机票”有若干未回答的问题。 团队创建项目，“就象团队成员，我可以理解“书籍机票”表示”。以表示。 团队可估计在与其估计其他积压工作项的单元需要研究工作。
重要
需要调查的积压工作项都不应添加到当前迭代，直到团队完成该处理。在单独的未来迭代应安排处理工作和积压工作项发生。
bug 积压问题:修复 bug 的最佳时间是在发现 bug 时。 如果无法当天修复它每次找到它，创建 bug 工作项，以确保不会失去对它的跟踪。 请注意避免累积 Bug。 如果您的团队累积 bug，请创建一个用户情景，并将这些 bug 链接到附加工作，以使峰值可以与其他用户情景和附加一起进行评估和优先级。
过程或工程改进:您的团队将进行过程或帮助驱动以帮助成功的工程改进。 在日常 scrum 会议期间，这些改进通常用于标识在检查展的冲刺 (sprint) 期间或。 例如，您的团队可能需要通过单元测试改进代码覆盖率，或缩短持续集成服务器上的生成时间。
对于每个附加或非层中工作您的团队访问的项执行，如“”第 2 步到第 5 步中确定团队的检查验收条件和估计工作量所述的理解将执行的工作并估计该工作。 有关更多信息，请参见创建或添加到产品积压工作。
支持估计的其他资源
您可以将有关敏捷估计做法的访问其他信息从以下资源：
敏捷估计:在从 mike Cohn 网站的敏捷估计提供一个表示。
在本教程中的相关主题
主页 | 创建积压工作 | 查看和管理您的 Kanban 键盘的积压工作 | 计划迭代 | 运行迭代 | 完成迭代