什么是Sprint规划？
Sprint规划是scrum中用来启动Sprint的事件。迭代规划的目标是定义Sprint能够交付的内容，以及如何完成各项工做。迭代规划须要整个scrum团队合做完成。markdown
与体育概念中的最后冲刺不一样，scrum中的‘冲刺’（sprint）要求团队一直保持极速状态以提供可工做的软件，与此同时还须要不断学习和提升。框架
在scrum中，Sprint是全部工做都得以完成的一段时间。只是在开始行动前，须要设置Sprint的相关条件：例如要决定时间周期的长度、Sprint目标以及从何处开始行动。Sprint规划会围绕Sprint中的应办事项和工做重点展开。若是组织得当，Sprint规划会还可以为团队营造一个充满激情和挑战并指引团队走向成功的环境。糟糕的Sprint规划可能会由于设定不切实际的目标，而致使团队的失败。学习
- 作什么——Product Owner阐述Sprint目标以及对实现目标有益的PBI。Scrum团队据此决定在即将开始的Sprint中须要作什么，以及要作哪些才能实现Sprint目标。
- 怎样作——开发团队根据须要交付的Sprint目标来规划具体工做。经开发团队和Product Owner协商一致后，最终获得一个基于价值和工做量的Sprint计划。
- 谁来作——Sprint规划必需要有Product Owner和开发团队的参与。Product Owner根据产品的价值取向来制定Sprint目标。而开发团队则须要弄清楚可否实现该目标。两者都必须参与，缺一不可，任何一方的缺席都将致使Sprint计划没法进行。
- 输入——Product Backlog是Sprint计划中很是重要的一个出发点，由于它提供了可能会成为当前Sprint一部分的“基本特征”表。除此以外，团队还须要查看增量中已完成的工做，以了解进度和剩余工做量。
- 输出——Sprint规划会议最重要的目的是让团队阐述Sprint目标，以及如何实现这个目标。这些内容将体如今Sprint的Backlog中。
Sprint规划会的前期准备
要举办一场精彩的Sprint规划会须要知足一些基本要求。Product Owner要作好充足的准备，结合前一次的Sprint Review会议中总结的经验教训、利益相关者的反馈以及他们对产品的愿景，奠基Sprint的基础背景。透明度方面，Product Backlog应是更新后的版本，确保清晰精准。Backlog Refinement是scrum中一个可选事件，由于有些backlog不须要进行梳理优化的。但对大多数团队而言，最好在sprint规划会前将团队聚在一块儿对backlog进行review并作出优化。优化
专家提示：
周期为2周的Sprint，要在中期举行一次backlog梳理会议。跳出当前的Sprint来思考下一个对团队来讲大有裨益。这样不只可以为Sprint规划作准备，还能够为评估当前的工做提供不一样的视角。blog
限制Sprint规划的时间
Sprint规划的时长应限制在每周两小时之内。因此，一个为期两周的Sprint，其规划会议将不会超过两个小时。这叫作“timeboxing”，即设定团队完成一项任务所需的最长时间，在这个前提下，进行Sprint规划。Scrum Master负责确保会议在规定时间内完成。若是团队在限定时间内达到了满意的效果，就能够认为会议顺利完成。时间限制仅强调最长时间，对最短期没有限制。事件
专家提示：
将Sprint目标做为Sprint规划的重点，不要将过多的精力放在Backlog的细节上。 聚焦目标而非具体的工做，才能让团队有更多的精力找到实现目标的最佳方案。开发
聚焦结果而非具体工做
在作Sprint规划时，团队很容易陷入“细节困境”，纠结于哪一个任务应该先作，由谁作，以及完成这项任务须要多少时间等。对于比较复杂的工做，初期掌握的信息有限，且大部分判断都是基于假设。Scrum是一个彻底根据经验的过程，这就意味着不少工做没办法提早规划，而是要经过实践来学习，而后将学习到的信息反馈到整个开发流程中。
Sprint目标以一个比较高的水平对Sprint的目标进行阐述，而backlog列表也能够用结果导向的思惟来编写。用户故事是一种从用户角度描述工做的很是好的方式。以下图所示，用户故事应该将焦点放在客户最终想要实现的效果的缺陷、问题和改进上，而非观察到的问题。get
经过在用户故事中添加清晰、可测量的结果，团队能够清楚地衡量输出结果，知道何时才算完成。尽量提早了解团队聚焦的工做，这样团队中每一个人在启动工做时就不至于一无所知。例如，团队能够将没法肯定的事情定为须要在Sprint期间回答的问题，也好过让其保持不清不楚的状态。博客
专家提示：
没法肯定某事和让其保持不清不楚的状态是两回事。不要忽视未知事件，由于它们就是团队必须脚踏实地完成的艰苦工做。但也不要使用含糊不清的描述来掩盖或隐藏它们。相反，当你不了解某些事情时，要认清本身的无知，并将其列为须要进一步了解的工做。产品
预估是必要的，但不表明要伪装了解未知事项
Sprint规划须要必定程度的预估。团队须要明确Sprint中能或者不能完成的任务，即：预估工做量和实际工做量。工做量的预估常常与承诺相混淆。预估本质上是团队根据当前掌握的知识作出的预测。衡量工做量大小的方法如故事点（story points）和T恤尺码分类法（t-shirt sizing）分别为团队提供了不一样的视角来分析和看待问题。而它们并不是神器，不能帮助团队在还没有掌握足够信息的前提下发现真相。所以，未知因素越多，预估的正确性就越低。
良好的预估要基于相互信任的环境，在这种环境下，团队能够自由交换信息，在不断的学习和改进中对假设进行论证。若是工做完成后证实前期的预估是错误的，那么之后的预估要么变得大不少，以确保再也不出错；要么花更长的时间来进行预估，以免再次出错。
专家提示
团队能够尝试用不一样的预估方法，如T恤尺码分类法（t-shirt sizing）或故事点（story points）。由于不一样的方法分析问题的角度不一样。
Sprint规划最佳实践
Sprint规划期间，团队很容易陷入“细节困境”，致使他们忘了Sprint规划的重点是为接下来的Sprint制定一个“恰到好处”的计划。规划不该成为团队的负担，而应该帮团队专一于有价值的结果，并确保团队保持正常的运行轨迹。好的Sprint规划经过定义输出的结果和清晰的计划来得到成功。但也要当心过犹不及，Sprint规划中，要聚焦目标和恰到好处的Sprint Backlog，而不是面面俱到的规定Sprint中每一分钟的工做计划。接下来，就是肯定Product Backlog的顺序，以便团队提早完成Sprint目标时能接着进入后续的工做中。
Scrum是一个旨在解决复杂问题的流程框架，而复杂问题的解决须要一个经验积累的过程（即边作边学）。经验积累的过程很难预先计划，因此不要自欺欺人——要认可咱们不可能制定完美的计划。相反，能够专一于结果并投入到实际的工做中去，哪怕咱们正在尝试解决很是困难的问题，启动工做仍能够是一件易事。
文章来源：Worktile敏捷博客