本文分享自华为云社区《用了Scrum越来越累？这三点帮你走出困境》，作者： 敏捷小智 。

你有没有一种感觉，团队用了 Scrum 之后，工作任务越来越多，加班越来越严重？有？好兄弟，这篇文章正好能帮你~

“用了 Scrum 之后，团队越来越累”，这应该怪 Scrum 么？其实，这个锅 Scrum 还真不背。《2020-Scrum-Guide（简体中文）》有如下描述：“Scrum 基于经验主义和精益思维。 经验主义主张知识源自实际经验以及根据当前观察到的事物作出的判断所获得。精益思维减少浪费，专注于根本。”，也就是说 Scrum 可以帮助团队减少浪费，让团队开发出最具核心价值的产品，但并没有说使用了 Scrum，工作量会变多或是变少，那问题出在哪呢？我们来分析一下。

问题分析

本文列举了三个比较具有代表性的原因。

1. 需求没有得到很好的澄清

从计划会议开始，团队就一直处于混沌的状态：部分业务场景相对复杂， PO 仅靠计划会议不足以向团队澄清所有重要的业务需求；计划会议结束，很多需求的细节甚至主要功能，都没有被开发人员理解，开发人员带着满脑子问号进入编码阶段，最终结果可想而知——开发人员在迭代中不断地和 PO 对齐，不断的整改编写完成的代码，测试人员也一直忙于功能测试、回归测试——整个团队忙的飞起，做出的产品却没有起飞。

2. 估算不准确

这里包含两方面估算错误，一方面是对团队速率估算错误，另一方面是对于需求工作量估算错误。

团队速率估算错误比如：团队一个迭代使使劲勉强可以做 40 个故事点的需求，结果团队高估了自己的能力，以为轻轻松松就可以做 50 个故事点的需求，最终造成团队疲于交付。需求工作量估算错误和速率错误同理。

3. 团队内卷

IT 行业内卷已经成为常态，以前没用 Scrum 大家都写周报，发给领导汇报工作，谁也不知道彼此干了啥；现在天天开早会，早会上一听说，嗯？这兄弟昨天干了这么多？那我要做的比你更多（比你更好）——这种内卷氛围在团队里蔓延起来，整个团队就会很累。

解决方法

1. 添加需求梳理会，提前了解需求

Scrum 框架中预置的 5 个活动并不包含需求梳理会，所以很多团队对“需求梳理会”（以下简称梳理会）这个词感到非常陌生，那什么是梳理会？

梳理会是 PO 向团队成员澄清未来迭代要做哪些需求的活动，开完梳理会再开计划会议，团队成员会对需求有更好的理解。梳理会虽然不是 Scrum 标准活动，但实际生产中，很多 Scrum 团队都会在迭代中插入梳理会，帮助团队对需求达成共识，确保下一个 Sprint 顺利进行。

梳理会什么时候开，开多久？

梳理会通常在迭代的中后期进行，和 Scrum 标准事件一样，梳理会的时间也应该是固定的，且适用于时间盒。梳理会持续时长通常不超过迭代总时长的 5%，比如两周一迭代，团队可以选择第二周周三的下午开展需求梳理会。

梳理会怎么开？

首先声明一点，需求梳理会不是计划会议的提前演练，梳理会相对于计划会议，更像是一种辅助关系，梳理会目的是对 Product Backlog 进行梳理、细化、排序；计划会议更多的是对 Sprint Backlog 里的需求进行拆分、认领。

梳理会首先需要 PO 说明下迭代哪些需求需要进行开发，同时 PO 负责向团队澄清这些需求。如果某个需求太大，PO 和团队一起对需求进行拆分。梳理会上的需求拆分目的是弄清楚下迭代底要做什么，这个过程不涉及团队分工，所以需求拆分至 Story 级别即可，将 Story 拆分至 Task 的操作可以放到计划会议去做。

需求拆分完成后，团队和 PO 一起，对新的 Product Backlog Item（PBI）进行优先级排列，并对近期要开发的需求进行工作量估算。所以梳理会给计划会议打了一个很好的基础，同时团队也有更多的时间去深入了解需求，避免需求没有得到很好的澄清。

2. 合理估算团队速率和工作量

如果团队成员对需求理解到位，可每个迭代还是被一大堆工作压着，那就有可能是计划会议上活领多了，这就需要团队对团队速率以及每个需求的工作量有一个很好的估量。

单个需求的工作量可以以小时为单位，高端点的话，可以用故事点做计量单位。工作量估算的过程，最好是整个团队都参与进来——人多力量大，一方面能将需求考虑的更全面，另一方面可以缩小估算偏差。更多估算知识可以参考《【DevCloud · 敏捷智库】估算四篇合集》 。

团队速率通常不等于一个迭代 100%的时间，因为团队还需要开会、研讨等。

团队速率是以故事点为单位，也就是正常情况下，一个迭代中，团队能够交付多少故事点的需求。如果团队没有尝试过使用故事点来估算团队速率，使用工时来估算也可以。这里推荐以迭代 80%的时间作为可工作时间的上限，也就是说，团队认领的工作总量不要超过迭代时间*团队人数的 80%。比如团队 7 个人，迭代时长为两周（每天工作八小时，每周工作五天），8*5*2*7*80% = 448h，也就是说这个团队每个迭代认领的总工作量应该在 448h 附近（故事点为单位同理）。

如果团队觉得 448h 时间还比较紧迫（不考虑团队磨洋工的情况）或者有很多闲置时间，那么后续迭代可根据实际情况，重新对团队速率做估算。

3. Scrum Master 遵从敏捷原则，让团队远离内卷

团队成员之间稍微卷一点，可能会起到一定的积极影响；可是卷的严重了，比如 996 甚至 007，整个团队就很累，这对于团队发展是不利的。

Scrum 本身提倡精益思想，既然团队迭代初期认领的需求工作量是符合团队速率的，那么团队加班在做什么呢？是否是过度开发，后面是否会造成浪费？Scrum Master 和整个团队都要反思。

而且敏捷十二原则有一条：“敏捷过程倡导可持续开发，责任人、开发人员和用户要能够共同维持其步调稳定延续”，如果团队按照内卷的节奏，能持续并且高效的发展下去，倒也能接受，可是团队往往很难坚持，这与敏捷的原则是违背的，作为 Scrum Master 应该注意到这点，并引导团队作出调整。

整个大环境都在内卷，如果 Scrum Master 改变不了团队内卷的情况，那就为团队成员准备下《颈椎护理指南》《21 天弄明白腰间盘》等养生书籍吧。

总结

以上三点分别从不同的角度讲述了用了 Scrum 之后，团队越来越累的原因和解决方法，希望对你有帮助。

此文由 DevSecOps 专家服务团队出品，前往 专家服务 ，获取更多 DevSecOps 工程方法、工具平台、最佳实践等干货。

点击关注，第一时间了解华为云新鲜技术~​