冲刺待办事项列表怎么建？创建流程与维护原则讲透

冲刺待办事项列表，英文叫Sprint Backlog，是敏捷项目管理里天天要用的一件东西。很多刚开始学PMBOK第8版的人，容易把它和产品待办事项列表搞混，也不知道它到底由谁来建、怎么维护。这篇就把它的创建流程和维护原则讲透。

一、先弄清楚它是什么

冲刺待办事项列表，是冲刺期间团队要完成的一组工作。它包含三个部分，一是这个冲刺要达到的目标，也就是冲刺目标，二是团队从产品待办事项列表里挑出来、打算在这个冲刺里完成的功能项，三是为实现这些功能项拆出来的具体开发任务。有的团队还会把完成的标准，也就是完成的定义，一起放进来，好让每一件事都有明确的验收边界。
它和产品待办事项列表的区别要分清。产品待办事项列表是产品要做的所有事情，长期存在，由产品负责人维护，里面的功能项按优先级排好队。冲刺待办事项列表只是这一个冲刺里要做的事，由开发团队维护，冲刺一结束就清空，下个冲刺重新建。一个是全产品的蓝图，一个是一个冲刺的作战地图，层次不一样，管的人也不一样。

二、创建流程：都在冲刺规划里定

Sprint Backlog不是凭空冒出来的，它是在冲刺规划这个环节被创建出来的。冲刺规划一般分三步走。
第一步，定冲刺目标。团队和产品负责人坐在一起，根据产品待办事项列表里靠前的、优先级高的功能，商量出这个冲刺要达到什么目标。冲刺目标要具体、要能达成，它是团队这一个冲刺努力的方向，也是后面所有工作围绕的中心。目标定得含糊，整个冲刺就容易跑偏。
第二步，选产品待办项。团队根据冲刺目标，从产品待办事项列表顶部往下挑，选出这个冲刺要做哪些功能项。挑多少，不是拍脑袋，要看团队的能力和冲刺的容量。也就是说，团队在这个冲刺的时间里实际能干多少活，就挑多少，别贪多。这里就牵扯到一个常用的概念，叫团队速度，也就是团队过去每个冲刺大概能完成多少工作量。参考这个数，选出来的量才靠谱。
第三步，拆任务。功能项选好之后，由开发团队把每个功能项拆成具体的开发任务。比如做一个登录功能，可能拆成设计界面、写接口、前后端联调、写测试用例这些任务。拆任务、估算每项任务要花多少时间，都是开发团队自己做，产品负责人不插手。为什么这么设计，因为只有真正干活的人，才最清楚活怎么拆、要多久。
这三步走完，Sprint Backlog就成型了，冲刺目标、功能项、任务都齐了。这是冲刺的起点，也是团队接下来一个冲刺要照着干的清单。
举个完整的例子。假设一个商城App，下个冲刺的产品待办里有登录、购物车、支付三个功能。冲刺规划时，团队和产品负责人先定下冲刺目标，让用户能完成登录和加购。团队按速度评估，一个冲刺能拿下登录和购物车，支付留到下个冲刺。于是从待办顶部选了登录、购物车两项，把它们拆成界面设计、接口开发、联调测试一堆任务，Sprint Backlog就这样建起来了。

三、维护原则：几条规则要记住

Sprint Backlog创建好之后，在冲刺期间要一直维护，它不是定下来就锁死的。这里有几条原则很关键。
原则一，只有开发团队能改它。Sprint Backlog是开发团队的工作视图，只有团队自己有权往里面加任务、调任务。产品负责人和Scrum Master都不能直接往里塞工作。这个设计是有道理的，它保证了团队的自组织，也防止了外部瞎指挥。你想，如果谁都能往里塞活，团队哪还有自己的节奏。
原则二，每天更新。团队每天都要更新Sprint Backlog，一般放在每日站会的时候。昨天做了什么、今天打算做什么、有什么卡住了，边汇报边把列表更新一遍，让Sprint Backlog始终反映当前的真实进度。一个不更新的Sprint Backlog，很快就变成一张没人看的废纸。
拿每日站会来说，团队十五分钟，每人说三件事，昨天做了什么，今天要做什么，有没有卡住。说的时候，一边说一边把Sprint Backlog里对应的任务更新掉，做完的标完成，卡住的标注出来。开完站会，列表就是最新的。这也是Sprint Backlog和站会天然绑在一起的原因，一个是会议，一个是会议的产出物。
原则三，冲刺中可以加工作，但不能改冲刺目标。冲刺进行到一半，可能发现要加一些活，比如某个功能的额外细节，或者突然冒出来的小问题。团队可以把这些新工作加进Sprint Backlog，但前提是冲刺目标不变。如果实在干不完，要主动跟产品负责人沟通，商量怎么调整，而不是自己硬扛着悄悄改目标。目标一变，这个冲刺的意义就没了。
如果冲刺中途真的遇到干不完的情况，正确做法是回看冲刺目标，把不影响目标的核心事项保住，把次要的往后挪，并第一时间让产品负责人知道。这样的透明沟通，比硬撑到最后再爆雷要好得多。Sprint Backlog的调整，本质上是团队对自己工作的动态管理，讲究的是透明和实事求是。
原则四，以完成的定义为准。每个功能项做到什么程度算完成，要看完成的定义，英文叫Definition of Done。比如一个功能，代码写完、联调通过、测试通过、文档补齐，才算完成。团队按这个标准去做，做完一项勾掉一项，Sprint Backlog上的事项才算真正清掉，而不是代码写完就自以为完成了。
完成的定义怎么定，也有讲究。它要具体、要能判断。比如一个功能，光说做完了不算，得有一条一条的标准，代码写没写完、单测过没过、联调顺不顺、文档补没补。标准越清楚，验收越省事。有些团队还会把完成的定义贴在墙上，或者写在Sprint Backlog的顶部，让大家一眼能看到。

四、常见误区，别踩坑

教学里见得多的，是这几个误区，一个一个说。
误区一，以为Sprint Backlog由产品负责人决定。不对。产品负责人定的是产品待办事项列表的优先级，排的是全产品该先做什么。Sprint Backlog怎么拆任务、怎么排顺序，是开发团队的活，两者别混。
误区二，以为冲刺开始后就不能加任何工作。也不对。冲刺里是允许加工作的，只要冲刺目标不变。真正的红线是不能改冲刺目标，不是不能加任务。新出现的重要工作，团队评估后可以加进去，把低优先级的往后挪。
误区三，把Sprint Backlog当成产品待办事项列表的复制。两者层次不同，一个是全产品的事，一个是一个冲刺的事，维护的人也不一样，内容粒度差得远，别当成一回事。
误区四，完成任务的标准模糊。Sprint Backlog里的任务，如果没写清楚完成的定义，做起来就没边界，验收也扯皮。这个在一开始就要定清楚，越具体越好，省得最后谁都觉得做完了、谁都不认。
还有一点实践上的提醒，Sprint Backlog别做得太粗，也别做得太细。太粗，任务没有粒度，不好跟进。太细，拆到每一小时，又成了负担，反而失去灵活性。合适的粒度，是每一项任务能在一两天内完成，既能看清进度，又留了调整空间。这个尺度，团队多跑几个冲刺就摸出来了。

五、小结

Sprint Backlog是敏捷冲刺的作战地图，由开发团队在冲刺规划时创建，冲刺期间每天维护。把这几句话记牢，它只归开发团队管，它每天都要更新，它能加工作但不能改冲刺目标，它以完成的定义为准验收。把这几点拿住，Sprint Backlog这个知识点就学扎实了。
从考试角度看，Sprint Backlog是PMBOK第8版里敏捷部分的高频考点。考它的创建时机、谁维护、能不能改动，常结合一个小场景来问。把创建流程和维护原则串成一条线来记，比零散背概念牢靠得多。理解了它背后的自组织逻辑，做题时不管场景怎么变，都能抓住核心。

六、一张表看懂组成要素

要素	作用	由谁确定
冲刺目标	指明这一冲刺的方向，团队工作围绕它展开	团队与产品负责人共同确定
选定的产品待办项	本冲刺要完成的功能，从待办顶部按优先级挑选	开发团队结合团队速度选定
开发任务	功能项的落地拆解，每项可独立估算和跟进	开发团队自行拆解
完成的定义	判定一项是否完成的统一标准，避免扯皮	团队共同约定并执行

上一篇:生成式AI进PMP考试，项目经理要补哪些数据功课

下一篇：没有了