生成和管理产品积压工作

项目
07/19/2013

由 Mitch Lacey。所有者，Mitch Lacey 和合伙人，Inc，一家专门从事于敏锐和讨论调整和改进。

2012 年 1 月

本文内容，Mitch Lacey 解释了产品积压工作的重要性，描述如何使用好的积压工作，并提供创建一些更好的实践和维护你的积压工作。

应用于

应用程序生命周期管理；Team Foundation Server

本文内容中：

介绍
产品积压工作
- 用户情景
- 估计
- 优先级
鲜活产品积压工作
- 修改
结束语

产品积压工作是按优先级排列的，需要所有特性和功能完成项目。好的产品积压工作是在所有正常运行的敏捷团队中心并具有以下特征：

优先确保团队首先生成最重要的功能。
通过团队估计可以提供产品所有者阐明和启用他回答问题，如“这些情景将在什么时候完成？”
它包括所有工作必须完成的项目。
它是实时文档，不断地更改和发展反映当前项目的现状。

好的产品积压工作不会自动确保优秀的软件。但是，缺少好的产品积压工作通常会产生不完整的软件，这种软件不符合您的客户和利益干系人的要求。

管理产品积压工作是一项全天工作。简单的技术可帮助更改任何有严重影响的内容，有效促使团队成员、客户和股东的交互进程、迭代进程的耗时流程。它是重要的，因此，若要了解实心技术来帮助您生成、设置优先级别和维护您的产品积压工作。

产品积压工作

产品积压工作是按优先级排列的，需要所有特性和功能的实时主列表完成该项目。产品积压工作通常要求用户情景 (即.. 要求)，bug、执行任务 (峰值) 和工程改进。这些项包括在通常称为情景点的抽象单位中。

产品积压工作包括随着时间的推移项目将要求和演变的所有工作。因此，它们不仅包含产品的新功能，还包含花费团队时间的 bug 修复和任何研究。团队将执行的所有工作必须来自产品积压工作：这是项目的前门。如果产品积压工作包括所有工作，则产品所有者、团队和管理人员最了解剩余工作，并可将最后一分钟惊讶的可能性降到最低。

在所有项目开始，您很可能不会很好准备列表清理，估计显式定义的产品积压工作项和设置优先级。相反，您可能有情景注意卡的堆栈和可能有一个功能规范或两个。作为产品所有者，得到一些排序顺序是您的工作，以便团队能够启动估计积压工作。

用户情景

第一步是将所有概念和注释转换为用户情景，这表示所需的功能的最终用户需功能（该软件的应进行的操作），但不是实现详细信息（如何创建满足这些要求的软件）。每个用户情景的标题应遵循该格式，“作为 <user>，我想要 <functionality>，以便 <reason>”。

故事卡示例

像产品积压工作本身一样，每个用户情景都将随时间推移而发生演变。在项目过程中，您的团队将对这些情景进行优先级排序和估计，为其添加详细信息，以及将这些情景分解为更小的情景或将它们一起删除。实现带到冲刺中的那些并向您的客户提供。

若要读取有关用户情景的更多信息，请参见创建或添加到产品积压工作和演示图板使用 PowerPoint 的积压工作项。

在将所有概念和注释转换到用户情景后，就可以估计并排优先级。

估计

按照定义，评估不精确。但是，如果有足够的时间、实践和整个团队的参与，您可以更善于进行相对准确的评估。第一步就是聚集整个团队，对产品积压工作项进行评估。当团队估计每个情景时，它们将其与抽象度量的单位的相对大小进行评估，并调用情景点。

估计由于以下两个原因很重要:

他们帮助回答“我们的完成时间”这一问题。
他们帮助产品所有者确定各项的优先级。

估计给予产品所有者和团队特定情景的成本的建议，依次，可帮助产品所有者确定情景的优先级相对其他人。越大项目的估计，越大开销将是实现基于时间和资源。因此，如果该项为高成本，可能会降低可能高于产品所有者希望的项的优先级。

团队可以使用计划扑克、用墙的方法或其他技术按照情景点估计该工作。有关估算技术和情景点速成课程的更多信息，请参见估计和梳理和估计积压工作。

在团队估计所有情景后，就可以确定优先级。

优先级

所有产品积压工作根据业务价值和风险设置其优先顺序。产品所有者将挤压工作上的每个项与其他项比较，确定其相对优先级。为此，产品所有者考虑各项的大小、其业务价值及任何关联风险。项按优先级的递减顺序排序。高优先级项目出现于产品积压工作的顶部或接近顶部，而较低优先级的项则处于底部或接近底部。团队在最高优先级的项中选择即将开始的冲刺 sprint 工作，因此，最重要的项目首先完成。

并不是积压工作中的每个项目都大小相同。一些在一个冲刺 (sprint) 中完成，但是，其他很大的团队不正确确保所包含的或它将花费实现它们。这是可行的。当项目移动更接近积压工作的顶部时，团队将使它们更小和更集中，以便更好的了解他们在即将开始的冲刺中解决的工作。

与评估，定性初始产品积压工作可以是吓人的。考虑最终产品、风险和成本，如何有效地平衡存在竞争关系的利益干系人要求？幸运的是，使任务更简单的多种方法存在，包括创新 Games 和相对权重。有关这些及其他方法的更多信息，请分别参见优先级和梳理和估计积压工作。

无论您选择什么优先级设置技术，您必须对工作排序以确保团队生成给定的最大值的功能到业务、利益干系人和客户。如果不优先考虑该工作，则您提供较低优先级而不是高优先级的用户情景并且当资源和时间表更改时，您未完成用户情景的风险增加。

（有关积压工作项性质的更多信息，请参见创建或添加到产品积压工作和敏捷规划和迭代。）

鲜活产品积压工作

到目前为止，我们已经描述了从不做任何评估和按优先级排列产品的积压工作的关注。和要求文档不同，产品积压工作不是在项目开始时创建继而被留在架上的。相反，产品积压工作的发展，展开和收缩带有项目的现状。某些产品积压项将变得无关和需要移除。其他将冒泡到图面并需要将其分解为较小的情景。出现附加要求时，将添加、估计新的用户情景并为其设置优先级。

团队和利益干系人设计创建和管理产品积压工作，但是该产品所有者对其具有最终责任。产品所有者必须确保积压工作是干净的、按优先级排列的以及是最新的，以便客户与团队对项目发布都具有工作计划的清晰图片。甚至项目已全面展开后，产品所有者仍需要执行大量工作在形状上保持产品积压工作:

添加新情景并设置优先级别
要求团队估计新情景并再次估计早期组件作为它们更好地了解
与团队一起检查即将到来的用户情景，以在必要时将项分解
会见客户和利益干系人以评审和添加要求

任何人都可能在任何时间将项添加到产品积压工作，但是，只有产品所有者可以设置优先级别。产品所有者也是可以将优先级分配到情景的唯一人员。团队的其他成员和利益干系人在添加情景时应保留优先级空白，即使使用提示他们这些信息的电子工具。

当添加情景时，产品所有者将基于他的理解程度给其优先级的初步评估。他与情景创建者讨论了该情景，以便更好地理解代码，这样他便可以反过来回答来自团队的问题。在每个冲刺过程中的一个排序时，产品所有者将满足团队讨论新情景和合作地评估这些事件，以便相比于积压工作中其他情景他可以更准确地设置优先级别。此过程称为修改积压工作。

修改

如上所述的产品积压工作梳理必须定期发生。

在 Scrum 中，团队应花费 5%-15% 其时间在修改活动的 每个冲刺 (sprint)。团队必须了解新增功能的内容，以便可以分解任何按优先级增加的大型情景，估计任何已创建的情景，并为即将到来的情景执行一些紧急设计和计划。若要确保发生这种情况，产品所有者和团队应在每个冲刺 (sprint) 计划会议期间留出冲刺 (sprint) 期间的一段时间一起修改积压工作。若要了解有关冲刺 (sprint) 计划的更多信息，请参见冲刺 (sprint) 计划和规划迭代。

在第二个周内，在一个两周冲刺期间，我希望召开此会议。这向产品所有者提供足够时间在用户与利益干系人之间进行有意义的会话，了结业务中的更改并明确用户情景以及新或按优先顺序增加的情景。它也是逻辑时间在冲刺 (sprint) 可以启动预测下一冲刺 (sprint) 期间。您可以决定何时召开会议。要点是在完成修改活动的冲刺期间授予足够的时间。

在典型的梳理会议期间，产品所有者显示新增功能，更改任何内容和他的以下几冲刺计划。除了估计新情景和还必须完成分类情景，团队在此会议期间可以查看该系统的当前体系结构和可以计划或设计即将到来的功能。在此过程中，这些情景估计经常更改，并且，新情景可能会出现，因为大型情景已分解为较小的情景。

此过程看起来很简单，但是，它可能有点困难。为帮助平稳运行，产品所有者必须准备回答问题。冲突紧跟着发生，如果，例如，产品所有者将在下次冲刺时为情景计划执行，但无法提供团队需要提供一种好估计的清晰度。在您的冲刺 (sprint) 计划会议期间，如果发生这种情况，ScrumMaster 应教给产品所有者关于他应从客户和利益干系人那里给团队带来哪些信息。

在每个梳理会议结束时，产品所有者应发布更改到利益干系人和客户，以便每个人都可以看到新增功能的内容，显示和更新发布计划。

好的产品积压工作帮助确保生成的软件具有最重要的功能，在客户和利益干系人的对话中欧标识并在您的用户情景中定义。为了创建和维护好的产品积压工作，您需要保留有效地与利益干系人/客户组和团队衔接在常规基类型的每个冲刺 (sprint) 上。

生成好积压工作不确保良好的系统，但缺乏好积压工作几乎最终确保您具有不执行客户请求的系统。换句话说，积压工作不保持最新将几乎始终导致项目失败。

产品所有者是一项全天工作，并且积压工作是其责任。仔细为该角色。在好的状态中保留产品积压工作—您的客户将感谢您。