多团队如何评估故事点(译)
发布于 2024-02-22
2859
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
Bruce Talk
扫码关注公众号
扫码阅读
手机扫码阅读
规模化敏捷中的多团队评估挑战
当组织扩展敏捷实践到多个团队时,协调和评估工作的复杂性会增加。团队必须进行评估和计划,并跟踪进度,以便产品负责人可以优先排序工作并与利益相关者沟通。多团队环境的挑战包括处理不同技能水平的团队、在不涉及所有人的情况下进行准确评估,以及在不确定最终执行团队的情况下预先评估。
常见的评估错误
组织在多团队评估中常犯的两个错误包括:
- 选择一小部分人进行评估,结果可能不反映所有团队的能力,导致评估结果过于乐观,从而破坏客户信任和工作关系。
- 将用户故事点等同于具体的小时数,这会消除故事点的主要好处,即评估不依赖于执行工作的个体,导致管理层错误比较不同团队的速度。
多团队项目的有效评估方法
针对包含多团队的项目,有效的评估方法是建立一个所有团队都认可的共同基准评估,用于评估和跟踪共享目标的进度。
让正确的人参与
建立跨多个团队的共同基准评估的最佳方法是将每个团队的代表聚集在一起,数量取决于团队的规模和数量。团队应选择最能进行评估的人员,考虑代表的技能组合。
评估多种类型的待办事项
代表团队通过玩计划扑克等活动进行评估,最好是面对面,但也可以虚拟进行。这些代表不会评估整个待办列表,而只估计10-20个能代表工作多样性的项目。
避免每个人都对所有事项精通
并非每位评估者都需要理解待办事项列表中的每一项。选择代表广泛产品范围的项目,并且多数参与者能够参与评估是关键。这样,通过代表团队达成一致的基准评估使各团队能够统一地进行评估。
译者的观点
相对估算如故事点估算具有易于达成共识的优势,应避免将其转换为绝对估算(如具体小时数)。基准评估应覆盖多种类型的用户故事以便于快速估算。多团队环境下,全员参与会议效率低下,选择团队代表进行评估是一种更高效的方法。
Bruce Talk
Bruce Talk
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
Bruce Talk的其他文章
重学Scrum三大支柱——《Scrum指南》重读有感(1)
Scrum 事件之所以起作用,是因为它们实现了基于经验主义的 Scrum 的三个支柱:透明(Transparency)、检视(Inspection)和适应(Adaptation).
SM和PO如何参与Daily Scrum——《Scrum指南》重读有感(3)
如果 Product Owner 或 Scrum Master 正在积极处理 Sprint Backlog 条目,那么他们将作为 Developers 参与其中。
DDD与CQRS的关系
前言
今天介绍一个实际工作中遇到的概念理解不准确
有时候用户故事拆分好坏可能只差一个问题
有时候转变思维惯性可能只差一个问题。
用“会思考的提示”提升提示工程效率
Meta-prompts也叫做元提示词,用来生成提示词的提示词模版。让我们用“会思考的提示”提升提示工程效率吧。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线