冲刺 (sprint) 计划
由 Mitch Lacey。所有者，Mitch Lacey 和合伙人，Inc，一家专门从事于敏锐和讨论调整和改进。
2012 年 1 月。
Sprint 计划不需要困难。通常有趣和整个 Scrum 团队的时间通过处理回答“我们可以提交什么？”的问题来生成同志爱，本文内容，作者有效的保持冲刺 (sprint) 计划焦点的示例和策略，并且，在计划冲刺 (sprint) 时，详细信息潜在的解决方案可以遇到常见问题。
应用于
应用程序生命周期管理；Team Foundation Server
本文内容中：
介绍
预测与提交
冲刺 (sprint) 计划什么？
我们如何完成它？
常见问题
方案：团队无法提交给产品所有者要求的所有情景。
方案：产品所有者不能正常准备。
方案：第 1 部分超过时间期限。
方案：第 2 部分超过时间期限。
方案：产品所有者不可用。
方案：团队不具备其需要的接收条件。
方案：产品所有者不了解完成的意义。
方案：ScrumMaster 或产品所有者在估算/影响该团队的估算/影响。
结束语
我们不计划。我们执行 Scrum，因此，我们只执行。
我始终能听到这种声音。人们认为 Scrum 和敏捷意味着没有计划、没有估计、没有会议，什么都没有！这可能更接近真相。在敏捷项目中我们计划各种级别：每日计划或每日站立，每周计划（冲刺 (sprint)，或迭代，积压工作），发布计划（产品积压工作）和更多可能。
让我们来关注计划冲刺 (sprint)。
预测与提交
在 2011 年的 summer，Ken Schwaber 和 jeff sutherland 修改他们的 Scrum 准则。在其中 Scrum 就知道移除了一个长建立行为，团队提交给产品所有者和客户。承诺由*“预测”*替换。他们声称该团队可能预测其工作但不对其提交。
当我了解其逻辑时，我希望提交以下原因：
用不同的思想放置团队而不仅是预测。如果团队预测，它表示不能满足每一件他们说他们可以做的事是可接受的行为。当团队可能从其预测中了解时，最后具有较少的估计变体，我发现团队“预测”需要减少变体为“提交”团体的比较。
预测或估计适于产品积压工作。但是，当团队将情景从产品积压工作移到冲刺 (sprint) 积压工作并将其分解时，他们添加另一级别的粒度，查看更细微的细节，这使得他们可以问自己：“我们可以提交这项工作么？”如果进行预测，团队就需要冒后退到惰性状态的风险，而不是说：“我们只需要预测，漏掉了什么东西也没问题，以后可以把它们都找出来。”
和在更小的说明，假设您是否向您的妻子、丈夫、合作伙伴显示“预测我们将在一起十年”和“我把自己托付给你”– 将正确的查看。
最后，有关常识的 Scrum。我建议您将承诺法和预测法都尝试一下。这是了解到的所有内容，而不是您使用的词，因此巧妙试用对您本人、您的团队及公司最合适的内容。
冲刺 (sprint) 计划什么？
我们保留冲刺 (sprint) 计划会议来计划“什么”团队将在即将到来的冲刺 (sprint) 中生成和团队将“如何”生成。虽然我们将其称为冲刺计划*“会议”*，实际上它由两个截然不同的部分组成。第 1 部分着重于要求团队生成什么以及由产品所有者和团队参与。第 2 部分着重于团队计划如何生成所需功能。虽然整个团队必须参加第 2 部分，由产品所有者的出席是可选的。如果，出于某种原因，产品所有者不参加第 2 部分，则产品所有者应保留问题的可用。
在冲刺 (sprint) 计划会议的第 1 部分中，产品所有者有机会描述需要的情景集给团队。这是这些场景的 哪些 部分上的深入会话。产品所有者显示该情景，显示如何通过接口进行交互和演练。此外可以查看基础结构或体系结构项目。其目标是使用足够的信息填充团队成员的协作标头，她们可以开始指定如何生成功能。团队将提出各种问题为 如何 满足收集信息 - 问题如下所示：
“什么是所有这些情景的验收条件？”
“您认为我们使用哪些数据源？”
“应如何在此组件查找接口？”
在冲刺计划会议的第 2 部分中，团队转移它的注意力到生成冲刺积压工作，在冲刺期间完成它们的情景列表和所需任务。若要生成积压工作，该团队将产品所有者按任务级别请求的各场景分解；每小时向各任务提供评估。在第 2 部分之前，团队承诺在冲刺期间，哪些情景它可以提交完成。
同时，冲刺 (sprint) 计划会议的两个部分可以在任意位置上采用 2 到 8 小时。我使用缩略的常规规则是每个部件应为冲刺长度的每周花费一个小时。这意味着，如果我运行一周的 sprint，会议需要总共小时（一小时的第 2 部分）第 1 部分和一小时。如果，另一方面，运行四周冲刺 (sprint)，会议采用总共八小时（第 1 部分四小时和第 2 部分四小时）。
我们如何完成它？
只要团队离开提交完成情景列表的冲刺计划会议，团队完成了冲刺计划的目标。但是，使团队中的每位成员都能在做出该承诺时感到舒适需要一些预先规划和简化。
产品所有者在冲刺计划期间有一个作业：参加会议可以描述希望情景集。团队的目标在于从产品所有者的角度理解，在产品所有者的远景中共享。Scrum 主管应确保团队提出足够的问题并捕获所有产生的数据，包括验收条件、草图和任何假设。在开始将这些问题分解为各项任务后，Scrum 主管还应让产品所有者知道该团队可能具有其他问题。虽然产品所有者显示点总值大致对应于团队的历史速度的情景，团队最终决定是否可能，事实上，采用任何基于在冲刺计划会议的第 1 部分和第 2 部分的内容的特定冲刺中的情景。
在团队已获取所有从产品所有者得到的信息后，它必须将情景分解为任务并创建冲刺 (sprint) 积压工作，获取所有情景、说明、验收条件、任务和估计特定冲刺 (sprint)。当有多种方式执行此操作时，我使用下列方法，利用所有团队成员的想法并在任务分解中向每个人提供语音。
如 ScrumMaster 或会议助手读取场景，并询问：“大家是否明白了？”团队应该明白，因为他们刚刚花费时间与产品所有人进行了讨论。如果团队中有人不了解，花些时间重新访问该情景，并询问有关产品所有者的任何必要的问题。
下一步，让每个团队成员获取一个便笺本。让每个团队成员编写在每个便笺的单个任务并在表元投掷它。
- 当每一个便笺扔到表的中部，该投掷者宣告任务。因此，如果书写“更新存储过程”，大声说出。这一点很重要，因为它将激发创意并使其他人说出：是的，我们也需要更新数据源”。此时，有人会在便签上写到；“更新数据库”，然后念出来并将其抛到中间。此集体研讨活动实际工作略去所有关联任务。不要考虑此时的副本。根据场景引发所有任务粘贴通常需要五到十分钟。
当在表上粘贴时，下面可以排序了。将它们全部放在墙上，回退一步，就会看到—许多粘贴！通过标识任何开始复制；重叠似乎是重复的所有粘贴。然后，查找似乎相互协调的任务，要么因为它们是相似的，或因为它们相互依赖。例如，如果两个粘贴有类似关系，请将其放在一起，但需要偏移，如下图所示:
.png "类似便条 - 偏移量")
如果两个任务非常紧密的相关到几乎完全相同，则差不多完全重叠它们，如下所示:
.png "类似便条 - 重叠")
通过排序 stickies，团队可以拣掉任务列表和可视化保持的那些之间的关系。
当任务排序时，下面可以估计了。我使用计划扑克技术来进行任务评估，有一点不同的是：牌的数量代表小时数而不是点数。我这样做，是因为人们容易因为与时间有关的无关紧要的细节而心神不宁，特别是处理大型任务时。有他们的惊慌的充分理由。公司太常将评估作为一根“棍子”以击败该团队。“您说需要 8 个小时，花费了您 12 个小时。错误是什么？”“您说需要 8 个小时，仅花费了您 4 个小时。您将填充您的评估。”
通过相同方式，卡片确保情景点估计抽象类，使用任务估计的卡片允许团队具有来自具有固定数量集可以选择在强制它们最终选择时。它还消除了热烈讨论的任务是否应估计在 6 小时或 6.5 小时或 7 小时。
无论最后的评估是什么，记住通过团队评估完成并旨在通过团队使用仅帮助增加其保密性和确定是否可以完成工作产品所有者请求基于速度。任务估计不是指标，不应尽可能地使用。不要使用估计作为对付该团队的武器。
既然估计了任务，那么团队必须确定其是否有能力承接更多工作。为此，您需要知道团队的能力，以及冲刺 (sprint) 过程中团队总的可用时间。如果您有一个完全私有的团队，确定容量很容易，但如果您有一个团队由多个项目之间拆分的兼职人员组成，获取就很难。请求每个人写下每天从事项目的小时数（或每个冲刺的总计）。 将所有数字加到一起以获取可用于团队的小时总数。假定团队工时结果为 200 小时。如果某一情景的任务总和估计使用 30 小时，则问团队，“我们可以接受更多工作吗?”在此初级阶段，答案显然是可以。
由于您具有更多的能力加载，继续移动到下一个情景和重复第一步到第五个步骤。
（有关如何使用 Team Foundation Server 完成此任务的信息，请参见 敏捷规划和迭代。)
有时，您将得到回答问题的一个困难时间，“我们可以选取更多工作?”这是因为，您处理您的团队容量。通过此工作，请考虑您不想加载冲刺到容量。如果您填充水到玻璃的边缘，则可能溢出。这一点也适用于冲刺。如果估计工时数占用所有可用时间，并且之后新的任务在冲刺 (sprint) 中标识，则将波及其它。您必须为紧急任务留出空间。
在假定冲刺 (sprint) 承诺时，有助于考虑从过去的冲刺 (sprint) 中追溯数据。在更多的工作中必须把团队一致？也许冲刺 (sprint) 计划期间团队可以提交更多。该团队是否正一致地无法以完成冲刺 (sprint) 的所有工作？在其解决不完整冲刺的根本原因前，团队与其承诺可能需要是比较保守。
为“将玻璃杯填充到多满”的问题给出一个数字的方法是考虑计划尺寸增长。计划尺寸增大测量实际小时数的消耗方式（与初始估计相比）。例如，假设我们团队具有的可用工时为 200 小时。基于估计，团队承诺将认为是 190 小时。在冲刺结束时，团队计算这些情景包含了 240 实际小时数的属性工作，从而计划范围增大 20%。
在发现此差异的团队应花费时间时在追溯期间调查原因：
在计划中，许多任务在未标识的执行过程中查看?
团队低估了其任务基于其当前技术组？
团队是否过度高的估计容量?
等等。
当确定是否可以承诺一个情景时，团队还应考虑在下一个冲刺计划会议期间增大其计划范围。回到我们的示例，如果团队仍估计容量为 200 小时，团队应减少总收入 20%，以根据历史数据补偿“预期”计划大小增长。换句话说，针对至少此冲刺 (sprint)，防止溢出，当团队到达 160 小时时，它应声明其在容量。
考虑计划范围增大是一种量化冲刺应是多完全的方法。 但是，请注意目标不完全匹配容量。相反，其将允许团队在提交给适当数目的情景时得以确信—该数目可以推动团队，而不将其过度加载。如果其他所有系数保持相等，计划尺寸增大只是大概确定下一个冲刺 (sprint) 的完整程度的一种方式。
当评估所有情景或通过情景使用所有的时间时，返回给产品所有者并分享团队已经提交来传递的冲刺 (sprint) 积压工作。立即启动冲刺—以便获取工作！
常见问题
在我的年份参考团队可以帮助他们采用 Scrum，我已经了解了许多防止成功的冲刺 (sprint) 计划的相同问题。虽然冲刺 (sprint) 计划似乎很直接，与 scrum 入门的团队往往去奋斗。本节详述了其中的许多问题及其可能的解决方案。
.gif "Hh765982.collapse_all(zh-cn,VS.110).gif")
方案：团队无法提交给产品所有者要求的所有情景。
您应预见此不常发生。只要团队可以支持来自本主题中前面所述的步骤四和五的数据的承诺，产品所有者应满足。您希望非常小心，以确保此提交故障不是填充过度和任务较大而造成的结果。Scrum 主管应挑战似乎过于保守的估计，以确保准确。产品所有者应对具有两位数估计的任何任务提问。估计时间比两个工作日长的所有任务应将其分解为较小的任务和重新评估。这确实适用于所有项目，特别是对一周或两周冲刺 (sprint) 困难的团队。
方案：产品所有者不能正常准备。
一个 Scrum 值是 respect。它是不恭的未准备参加会议。因此，如果产品所有者显示，而无需信息团队需要，因此团队应该做些什么？虽然一个选项是推迟会议，直到产品所有者准备就绪，这样做只鼓励避免相同行为出现。另一种方法是使用取消该冲刺。尽管这可以工作，它是谨慎使用的。
我发现最好的解决方案具有二重性。首先，产品积压工作应按照某种优先级排序，因此如果产品所有者没有特定场景集，团队和产品所有者可以讨论场景的优先级顺序，直到他们认为已经发挥最大能力（或超额发挥）为止。然后团队可以在会议的第 2 部分照常决定确切的承诺在会议的第2部分期间。
在会议后，scrum 主管应了解产品所有者未准备的原因。如果问题是缺乏合作，则 ScrumMaster 可使产品所有者了解准备好一套场景参加会议的重要性。如果，另一方面，此问题是产品所有者 无法 准备，或许因为团队未能帮助修改，ScrumMaster 也应帮助解决这些问题。
方案：第 1 部分超过时间期限。
另一个值为焦点。如果回顾会议的第1部分，则问题是缺乏重点。有时产品所有者是未集中的由于缺少准备，设置优先级或尝试解释许多情景。其他时间，缺乏焦点可能源自团队没有具体“方式”的“内容”谈话。
Scrum 主管应帮助沿着不能完全解释的产品所有者表任何情景移动操作，且该团队将详细实现讨论保留在第 1 部分外。解决无重点讨论的一个简单方法是使用秒表或计时器。
方案：第 2 部分超过时间期限。
同样，焦点。如果您可以访问大量的团队，有时有的专业可以限制需要在行中显示回滚会议的所有讨论。带来蛋计时器并保留对话到任务估计之间的一分钟或两分钟。其目标是准确的，而不是 100% 精度。
其他时间，第 2 部分期间缺乏焦点预示着执行冲刺 (sprint) 期间缺乏产品积压工作梳理。在修改时间，团队可以查看未来的情景，并与产品所有者合作添加情景或附加工作，以确定设计方向或解决架构问题。没有规则的产品积压工作梳理，冲刺 (sprint) 积压工作计划成为不实用和棘手。
方案：产品所有者不可用。
如果产品所有者出于某种原因不能参加会议，而且未指定代理，则就象产品所有者没有准备就来参加会议那样操作。通过顶部项目并提交到可以最佳的工作。您可能会临时更改会议的时间，以提供产品所有者的计划。不应该。转换会议的时间影响许多容纳一个必需的。它没有价值。
方案：团队不具备其需要的接收条件。
在第 1 部分中，我始终建议团队需要询问产品所有者：“这件产品的验收条件是什么？”或“我们需要做什么才能让您接受我们的工作？”，如果在第 2 部分没有问这类问题，那么团队将不知道如何结束这一场景。如果团队必须给予在第 1 部分听到的猜测，则团队会面临产品所有者在冲刺 (sprint) 结束时决定情景未完成的风险。为每个情景从开始请求验收条件。ScrumMasters—指导您的产品所有者提供此数据。
方案：产品所有者不了解完成的意义。
与团队需要验收条件一样，产品所有者需要最新团队表示的说明由“该情景执行”。执行列表始终广泛地发送，最新和可用的产品所有者。执行的过时列表使得难以计划，因为没有执行的操作的常见了解。确保执行更新的列表是每个冲刺评审或任务的部分。
方案：ScrumMaster 或产品所有者在估算/影响该团队的估算/影响。
产品所有者在会议的第 2 部分是受欢迎的，但应限制第 2 部分的产品所有者角色，阐明需求或发现特定问题。产品所有者不应在任务估计中影响如何实现情景和尚未发言的团队讨论。产品所有者需要信任团队完成工作。
如果产品所有者在这些准则之外行事，则 ScrumMaster 应教产品所有者成为更合适的角色。如果产品所有者拒绝接受一个更被动的角色，则 ScrumMaster 有权请产品所有者离开。
Sprint 计划不需要困难。这通常是有趣的和整个 Scrum 团队的时间通过回答问题“我们可以提交什么？”来生成同志爱，记住，如果您发现会议长期运行，根本原因问题可能是由此导致的。如果您是 ScrumMaster，通过确保产品所有者和团队修改产品积压工作保持会议重点集中。通过在会议前准备好情景验收条件，帮助产品所有者做好准备。最后，协助确保产品所有者和团队专注于手头的任务 - 确定他们可承诺为冲刺 (sprint) 做些什么。