创建大规模产品积压工作
您的团队可创建产品积压工作（常常包含用户情景）来表示其客户需要和看重的层面。 在项目过程中，您的团队将向用户情景中添加详细信息，将它们分解为更小的情景，设置其优先级并进行估计，最后，实现这些情景并将结果交付给客户。 通过编写有趣的用户情景并持续更新产品积压工作，您的团队可以更高效地向客户交付价值。
Bill Wake 使用缩写词 INVEST（独立、可协商、有价值、可估计、小型和可测试）总结了构成优秀用户情景的要素。 有关更多信息，请参见以下网站：XPlorations。 Mike Cohn 在他的一本书中讨论了如何编写用户情景，您可以从以下网站下载相关章节：User Stories Applied for Agile Software Development（《用户情景在敏捷软件开发中的应用》）。
当您的团队创建用户情景时，请通过回答以下问题确保它代表客户价值：
用户身份
用户需要执行的操作
用户需要执行该操作的原因
在大多数情况下，您的团队可通过创建有效的标题来实现此目的。 Mike Cohn 建议采用“作为<用户>，我需要<操作>，以便<原因>”形式。 在示例“作为一名客户支持代表，我需要访问客户信息，以便能够更快地响应客户的问题。”中，您可以看到此方式。在许多情况下，原因都很明显。 例如，“作为一名素食主义者，我可以过滤我的视图，以便只看到素食菜单。”
此外，在定义用户情景时，还应该允许按照任意顺序实现这些情景。 但是，使用户情景完全独立并非始终可行。 Bill Wake 和 Mike Cohn 都介绍了您的团队应对令用户情景独立这一难题时可采用的方法。
如上文所述，有价值且独立的用户情景构成了产品积压工作。 首先对这些用户情景进行估计并设置其优先级，然后您的团队开始处理级别最高的用户情景。 在您的团队实现某个用户情景之前，该用户情景必须具有下面列表中的特征： 您的产品所有者将致力于确保级别最高的用户情景符合这些条件，然后再将它们带到冲刺 (sprint) 计划会议讨论。
足够小，以便能够在冲刺 (sprint) 中实现
将要实现的用户情景必须足够小，以便在冲刺 (sprint) 中完成。 您的产品所有者将与您的团队一起协作分解那些过大的用户情景。 例如，用户情景“作为一名客户支持代表，我需要访问客户信息，以便能够更快地响应客户的问题”可能太大，而无法在冲刺 (sprint) 中完成。 可将该用户情景分解为诸如“作为一名客户支持代表，我需要通过使用客户的电话号码访问客户的名称和最近的通话摘要”和“作为一名客户支持代表，我需要访问客户完整的通话记录，以便我可以更详细地调查当前问题”之类的情景。
足够详细，以便能够对实现情景所需的工作进行描述和估计
在将用户情景包括在冲刺 (sprint) 中之前，在情景点中对这些情景进行估计。 这些估计为有意地粗略估计，主要用于管理积压工作和帮助准备冲刺 (sprint) 。 在冲刺 (sprint) 开始时，您的团队会将用户情景分解为实现该情景所需的任务。 您的团队将与产品所有者一起在产品积压工作梳理会议上确定，哪些情景需要更多的信息，然后才能将它们分解为各项任务，从而估计工时。 您的产品所有者可以收集这些详细信息，并将它们记录到用户情景的描述中。
请注意不要向用户情景添加不必要的详细信息。 用户情景应该是与产品所有者和客户会谈与协商的基础，会谈与协商将持续到用户情景已完成并被接受。 太多详细信息可能会暗示精度不准确，从而损害协商。
已定义验收条件
冲刺 (sprint) 结束时，您的客户或产品所有者将用户情景视为已完成接受它，或者拒绝它。 在冲刺 (sprint) 开始之前，应尽可能明确地说明客户的验收条件。 当然，可能会因为某些意料之外的原因不接受用户情景。 但是，您的团队与客户为帮助定义验收条件进行的会谈将有助于确保您的团队了解客户的预期。 验收条件可用作验收测试的基础，以便您可以更加高效地评估是否已完成用户情景。
长篇故事和主题
人们通常认为用户情景应该比较小， 对于将要实现的用户情景来说，情况正是如此。 不过，级别较低的情景可以较大些。 事实上，使这些情景保持较大是防止您的产品积压工作变得太大而无法管理的一种好方法。 当用户情景的优先级别达到产品积压工作的最高级别时，可以将其分解为较小的用户情景。 将较大用户情景视为长篇故事和主题将很有帮助。
长篇故事是非常大的用户情景，表示极大工作量。 当您分解长篇故事时，可以创建许多主题和其他较小的用户情景。
主题是相当大的用户情景，通常比将要在冲刺 (sprint) 中实现的情景要大。 在您的团队实现主题之前，必须将其分解为较小的用户情景。
当您设置产品积压工作的优先级时，分解接近最高优先级的长篇故事和主题，然后对较小的新用户情景设置优先级。 完成操作后，最高优先级的用户情景应该足够小，以便能够实现。 在按优先级排列的积压工作中具有较低优先级的大多数用户情景通常较大。
附加工作
您的团队有时候需要执行直接实现用户情景以外的工作。 此项工作被称为“附加工作”。 附加工作的三种常见类型为研究、Bug 积压问题和过程或工程改进。 若要在 Team Foundation 中创建附加工作，请创建一个用户情景工作项，将类型设置为“附加工作”，然后在产品积压工作中同时设置它与其他用户情景的优先级。
研究
当用户情景存在一些未解决的问题，而且必须先回答这些问题才能将用户情景完全分解为各项任务并对其进行估计时，将会进行研究。 例如，假定团队在冲刺 (sprint) 计划会议期间遇到这样的情景，“作为一名常飞旅客，我可以预订奖励机票”。 经过讨论之后，他们发现有无法回答的问题。 团队创建一个用户情景，以表示附加工作。“ 作为团队成员，我可以理解‘预订奖励机票’的含义，因此我可以编写情景以包含在将来的冲刺 (sprint) 中。”团队会确定其愿意专门用于此项研究的小时数，并将该小时数记录为附加工作的时间期限。 在该迭代期间，无法执行在附加工作期间编写的任何情景， 必须使用产品积压工作将这项工作安排到未来的迭代中。
Bug 积压问题
修复 Bug 的最佳时间是在发现 Bug 时。 如果您无法在发现它的当天修复它，则应创建一个 Bug 工作项，以确保不会失去对它的跟踪。 请注意避免累积 Bug。 如果您的团队累积了 Bug，则创建一个用户情景，并将这些 Bug 链接到附加工作，这样就可以对它进行估计，并与其他用户情景和附加工作一起设置优先级。
过程或工程改进
您的团队将进行过程或工程改进，以帮助其取得成功。 通常，在冲刺 (sprint) 追溯和每日讨论会议期间确定要进行的改进。 例如，您的团队可能需要通过单元测试改进代码覆盖率，或缩短持续集成服务器上的生成时间。