如果你’ve遵循本系列的前2个步骤，现在您应该 让您的产品积压 并有 使用斐波那契点估算其大小.
下一步– Step #3 –是计划您的Sprint。
冲刺计划研讨会
召开Sprint计划会议。确保全体团队参加会议。包括所有角色。业务分析师（如果有）。测试人员（如果有）。产品的Scrum团队中的所有开发人员。非常重要的是产品负责人。
您必须做的第一件事（在您的第一次Sprint计划会议中）是确定Sprint的持续时间。这个决定应该作为一个团队来考虑。
确定您的冲刺持续时间
这是一个重要的决定。 Scrum建议30天。可能是对的。但这一点似乎被敏捷团队练习Scrum广泛采用。
最佳冲刺持续时间取决于许多因素。我最近看过的东西建议一个开发团队’s ‘cycle time’直接反映了其流程的成熟度。我想我同意那句话。
一个流程不成熟的团队会发现Scrum的强度以及Sprint计划，测试，部署和审查的开销对于一个短的Sprint周期来说是相当繁重的。而具有非常成熟的流程的团队（例如，自动化测试，自动化部署以及’如果在Sprint计划中变得非常快），那么短周期可能会很舒适。
I’d建议范围在1周到1个月之间。 1周可能是有史以来最短的一周，尽管如果您真正掌握敏捷实践，为什么不在发布每个新功能时就发布它’s ready? (if that’适用于该产品）。 1个月肯定是最长的。
适用于快速发展的产品或市场，例如基于Web的产品–没有集中部署，没有部署或用户培训的地方–1个月似乎是一生！我个人喜欢快速移动产品的2周Sprint。
Mike Cohn是敏捷开发的重要代表之一。见麦克这里’的文章提供了进一步的建议 如何选择最佳迭代长度.
保持冲刺持续时间一致
无论您选择哪种Sprint持续时间，我的建议都是保持一致。
实际上，这比长度本身更重要。因为它’这种一致性使您可以进入节奏。它’这种一致性使您的过程非常可重复。因此，可以帮助您以团队的方式迈入大步。而且’的这种一致性使您可以开始了解通常可以在Sprint中完成多少产品待办事项点。
一旦您’您已经决定，现在可以在每次Sprint之前都设置一个冲刺计划研讨会作为定期约会。
选择Sprint的目标待办事项
现在轮到你’ve确定了您的Sprint持续时间。接下来，您必须确定Sprint的目标…
查看产品待办事项的顶部，为Sprint设定合理的目标似乎是什么？您能否表达一个总结下一个Sprint目标的目标，还是至少从产品积压列表的顶部选择团队认为可以在Sprint持续时间内实现的部分项目/功能？
选择Sprint的目标积压。团队决策。
包含比您认为可以实现的更多的内容。它’重要的是在计划期间准备更多的物品，以防团队提早完成。这些项目可以清楚地识别为 伸展任务 产品负责人不应期望它们完成。只有Sprint的性能超出预期时，您才可以做这些事情。
在将来的Sprint中，您将可以使用Scrum团队’以前的Velocity可以帮助您做出此决定。速度是指在Sprint中交付的产品积压点数。在采用Scrum时，这往往会在早期大幅度波动。但是随着团队进入节奏，它会安定下来，并在将来为您提供合理的规范以使您的目标积压基础。
明确冲刺要求
获取产品待办事项清单上的每个项目。它’重要的是要有条不紊地进行检查，一次检查一项…
产品负责人介绍每个项目，并从功能的角度解释他/她如何看待它的工作。
整个团队将详细讨论该项目。整个团队都会询问有关该功能的问题，以便确定其功能和工作方式。
讨论的结果应记录在白板或活动挂图上，或者随着讨论的进行，有人可以在笔记本电脑上写笔记。交互式或可打印白板是此过程的理想选择。
您可以使用所需的任何形式的写作要求。但是，在Scrum和任何敏捷开发方法中，重要的原则是在需求开发之前就逐个功能地编写需求。
以轻量级和可视化的方式编写需求。 敏捷 requirements should be barely sufficient。事实上，这些功能将在接下来的几周内进行开发并通过现场团队进行测试，从而使这一切成为可能。
考虑写作‘User Stories’，是XP（极限编程）的概念。它’超出了本文的范围，无法详细解释用户故事。但是基本概念是使用此构造编写功能：
作为[用户类型]，我想[做任何事情]，所以我可以[实现什么目标]。
可以通过UI草图，线框或视觉效果来备份故事。注释草图以描述功能。用关于它会如何的陈述来备份它 已确认 （或经过测试）。这将有助于提前识别方案’s developed.
有关用户故事的更多信息，Mike Cohn撰写了一本书， 用户故事 Applied.
下一页…
明确了针对Sprint的所有产品待办事项的要求后，下一步是 步骤4：Sprint计划/估算任务…
凯莉
也可以看看：
