当 Sprint 计划会开得很成功时，团队大多时候都能够完成迭代目标（但肯定不是所有时候）。那么有哪些危险信号能表明你们团队的 Sprint 计划会是痛苦的？能怎么扭转局面？
危险信号 1：Sprint 计划会冗长且痛苦
我也不喜欢每年去两次牙医那里洗牙，但我承认这是有价值的。
危险信号 2：大部分 Sprint 都未达成目标
团队不需要在每个迭代都完成所有工作，并完美达成 Sprint 目标，但大多数情况下，团队应该能够完成所有计划的工作。
有太多团队每个迭代都无法完成目标。如果大家觉得计划会冗长又痛苦，而会议最终又无法带来 Sprint 的顺利完成，则会让这种负面的感受加剧。
危险信号 3：Sprint 计划会毫无激情
Sprint 计划会遇到困难的第三个迹象是，团队成员在离开会议时，对即将开始的迭代工作没有产生热情和兴奋感。
如果 Sprint 计划会开得成功，大家应该会为即将着手完成刚刚花时间讨论的工作感到充满能量。如果你和团队中的伙伴刚刚完成了计划会议，却对接下来的工作兴趣寥寥，则说明你们的计划会还有改进的空间。
建议 1：让 Sprint 计划会保持简短
会议节奏要快，但不要让人感觉讨论仓促或是被打断。我一般会用90分钟来规划一个两周的迭代。如果两周的工作只用了30分钟来计划，那么你几乎一定没有考虑到充足的细节。反之，如果需要花费3小时来进行计划，那么大家就有权抱怨会议太冗长和痛苦了（危险信号一）。
建议 2：尽量减少花费在估算上的时间
举个例子，一个软件团队在开发一个简单的功能时，可能会拆分出1到2个编码任务，1个测试任务，1个设计任务，也许还有一个针对设计征求用户意见的任务。这些估算可以是很粗略的，仅仅是快速的猜测。团队只是用它来评估他们纳入 Sprint 的工作量是否合适，不会太多也不至于太少。
测试任务：6小时
设计任务：2小时
把每项任务的估算时间控制在一天以内。如果某项工作需要超过一天，鼓励团队成员把他们拆分成更细的多个任务，每个任务的估时都在一天之内。
估算时间应该包含每个参与的成员所花费的时间。前面的 用户设计评审 这个任务估时是3小时，但这并不一定是3小时的会议。它可能只是一个1小时的会议，但有三名团队成员都要参加。
等你的团队对于 Sprint 计划已经非常熟练了，可以尝试跳过估算的环节。只需要建一个任务列表，看看大家是否能够仅凭列表上的内容就判断出迭代工作量是否合适。
建议 3：不要事无巨细的计划
这么做一定会遗漏一些任务，但没有关系。
为了迭代顺利，确保不要把计划安排得太满，团队会在 Sprint 工作期间识别出新的任务，所以要留出一定的空间。
团队成员在两周的迭代里会完成300-360小时的有效工作，其中250小时是能够提前在 Sprint 开始时识别出来的，其余的内容会在团队工作过程中逐渐发现。
你的团队在 Sprint 计划会上做得如何？你们的会议是否漫长且痛苦？团队成员离开会议时是否充满活力，对即将开始的工作满怀期待？
如果你的团队在 Sprint 计划方面做得很棒，并且大多数时候都能实现 Sprint 目标，请在评论区分享你的秘诀。
注：部分图片来源于网络
原文地址：how-to-stop-struggling-with-sprint-planning
关于作者
