搜索
关闭此搜索框。

让你的 Sprint 计划会告别痛苦

Sprint 计划会(Sprint Planning)常常是整个迭代中最长的会议。但实际上计划会并不需要开一整天,甚至半天也用不着。一个两周的迭代可以在90分钟内进行很好的规划,且并不匆忙。
Sprint 计划会如果开得好,会让团队充满活力。当团队带着完成迭代工作的计划和达成迭代目标的使命感离开会议时,空气里也弥漫着令人愉悦的兴奋。

当 Sprint 计划会开得很成功时,团队大多时候都能够完成迭代目标(但肯定不是所有时候)。那么有哪些危险信号能表明你们团队的 Sprint 计划会是痛苦的?能怎么扭转局面?

危险信号 1:Sprint 计划会冗长且痛苦

第一个危险信号是 Sprint 计划会冗长且痛苦,团队成员怨声载道。我几乎能听到你们在说,所有的会议都是痛苦的,也许吧。但即便大家并不享受会议的过程,也应该认识到 Sprint 计划会是有价值的。

我也不喜欢每年去两次牙医那里洗牙,但我承认这是有价值的。

危险信号 2:大部分 Sprint 都未达成目标

团队不需要在每个迭代都完成所有工作,并完美达成 Sprint 目标,但大多数情况下,团队应该能够完成所有计划的工作。

有太多团队每个迭代都无法完成目标。如果大家觉得计划会冗长又痛苦,而会议最终又无法带来 Sprint 的顺利完成,则会让这种负面的感受加剧。

危险信号 3:Sprint 计划会毫无激情

Sprint 计划会遇到困难的第三个迹象是,团队成员在离开会议时,对即将开始的迭代工作没有产生热情和兴奋感。

如果 Sprint 计划会开得成功,大家应该会为即将着手完成刚刚花时间讨论的工作感到充满能量。如果你和团队中的伙伴刚刚完成了计划会议,却对接下来的工作兴趣寥寥,则说明你们的计划会还有改进的空间。

建议 1:让 Sprint 计划会保持简短

现在我们来聊聊怎么能让你的 Sprint 计划会不再痛苦,并且做得更好。我会分享三个建议。
首先,让 Sprint 计划会适当的简短。你不希望这个会议开得非常匆忙,否则一定会遗漏过多的工作,从而导致无法完成实现 Sprint 目标需要的所有待办事项。“行动迅速但不急不躁” 的建议也适用于此。

会议节奏要快,但不要让人感觉讨论仓促或是被打断。我一般会用90分钟来规划一个两周的迭代。如果两周的工作只用了30分钟来计划,那么你几乎一定没有考虑到充足的细节。反之,如果需要花费3小时来进行计划,那么大家就有权抱怨会议太冗长和痛苦了(危险信号一)

建议 2:尽量减少花费在估算上的时间

第二个建议是,创建一个 Sprint Backlog,包含一系列的任务和每个任务大致的估算时间。但不要花太多时间在任务或者估算上。

举个例子,一个软件团队在开发一个简单的功能时,可能会拆分出1到2个编码任务,1个测试任务,1个设计任务,也许还有一个针对设计征求用户意见的任务。这些估算可以是很粗略的,仅仅是快速的猜测。团队只是用它来评估他们纳入 Sprint 的工作量是否合适,不会太多也不至于太少。

编码任务1:6小时
编码任务2:6小时

测试任务:6小时

设计任务:2小时

用户设计评审:3小时

把每项任务的估算时间控制在一天以内。如果某项工作需要超过一天,鼓励团队成员把他们拆分成更细的多个任务,每个任务的估时都在一天之内。

估算时间应该包含每个参与的成员所花费的时间。前面的 用户设计评审 这个任务估时是3小时,但这并不一定是3小时的会议。它可能只是一个1小时的会议,但有三名团队成员都要参加。

得出这些任务和估算不应该花费太多时间,肯定不至于让你的计划会变得漫长而痛苦。请记住,它们真的只需要是一个快速猜测,而且也并非一直要这么做。

等你的团队对于 Sprint 计划已经非常熟练了,可以尝试跳过估算的环节。只需要建一个任务列表,看看大家是否能够仅凭列表上的内容就判断出迭代工作量是否合适。

建议 3:不要事无巨细的计划

接下来是第三个也是最后一个建议:不要试图考虑所有事情。这真的能够为你节省计划会的时间。
是的,我刚刚让你列出每个产品待办项对应的任务,但团队并不需要在计划会上想清楚每一个任务。
让大家说出能想到的任务:编码、测试、确定怎么处理这个或那个,诸如此类。你会发现很快大家就想不出来了。
这时候可以停留5-10秒,看看是否有人有补充的任务。之后就继续讨论下一个产品待办项,创建它的任务列表和估算。

这么做一定会遗漏一些任务,但没有关系。

如果每个待办项再多给大家五分钟时间,可能再放点莫扎特音乐来帮助大家思考,也许会再得出一些任务项,但这不值得!快速识别出大家能想到的任务然后继续下一个。

为了迭代顺利,确保不要把计划安排得太满,团队会在 Sprint 工作期间识别出新的任务,所以要留出一定的空间。

假设你有一个6人团队,在运行2周或10天的迭代。你可以假定大家每天能够有效工作的时间在5-6小时之间(其余的时间花费在会议、讨论、公司事务等等)。那么一个6人团队,每人每天工作5-6小时,在10天的迭代中可以有300-360小时的工作容量。所以他们或许应该在计划会中规划大约250小时的工作。

团队成员在两周的迭代里会完成300-360小时的有效工作,其中250小时是能够提前在 Sprint 开始时识别出来的,其余的内容会在团队工作过程中逐渐发现。

Sprint计划会充满挑战,但对于团队来说,正确制定计划至关重要。

你的团队在 Sprint 计划会上做得如何?你们的会议是否漫长且痛苦?团队成员离开会议时是否充满活力,对即将开始的工作满怀期待?

如果你的团队在 Sprint 计划方面做得很棒,并且大多数时候都能实现 Sprint 目标,请在评论区分享你的秘诀。

注:部分图片来源于网络

原文地址:how-to-stop-struggling-with-sprint-planning

关于作者

【作者】Mike Cohn
Mike是敏捷联盟及Scrum联盟创始人之一,是帮助企业适应和改进敏捷过程及技术,以建立极致高效团队的专家。著有《用户故事与敏捷方法》,《敏捷估算与规划》,《Scrum敏捷软件开发》以及视频课程《更好的用户故事》。

 

火爆 售票中
Scrum.Org 主办
搜索
近期公开班
大规模敏捷顾问SAFe SPC认证课徽章
6月15-18日​
SAFe认证-SPC SAFe认证培训师导师班
Marsha Xue , Alex Guan 授课
领导大规模敏捷Leading SAFe认证徽章
7月13-14日
Leading SAFe领导大规模敏捷认证课
Scott Wang 王庆付 授课
专业Scrum Master (PSM I) 认证徽章
7月13-14日
专业Scrum Master (PSM I) 认证公开课
Derek Ding 丁志润 授课
Scrum.org专业Scrum产品负责人(PSPO)认证徽章
8月03-04日
专业Scrum产品负责人(PSPO)认证公开课
Derek Ding 丁志润 授课
scrum alliance csm认证徽章
8月03-04日
Scrum Master (CSM) 认证课
Lance Zhang 授课
safe scrum master
8月10-11日
SAFe ScrumMaster 官方认证公开班
Eric Liao 廖靖斌 授课
Scrum联盟acsm认证徽章
8月24-25日
高级Scrum Master(A-CSM)认证公开课
Jim Wang 王军 授课
0
0
小时
0
分钟
0
由Scrum.org主办的 2024中国Scrum大会 8月17日将在上海开幕
0
0
小时
0
分钟
0
预约回电
留下您的手机号,我们会在第1时间联系您。
热线电话:400-696-6280
Get in Touch
预约回电
预约成功,我们会尽快联系您。
Get in Touch