多团队如何评估故事点(译)
发布于 2024-02-22
2547
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
Bruce Talk
扫码关注公众号
扫码阅读
手机扫码阅读
规模化敏捷中的多团队评估挑战
当组织扩展敏捷实践到多个团队时,协调和评估工作的复杂性会增加。团队必须进行评估和计划,并跟踪进度,以便产品负责人可以优先排序工作并与利益相关者沟通。多团队环境的挑战包括处理不同技能水平的团队、在不涉及所有人的情况下进行准确评估,以及在不确定最终执行团队的情况下预先评估。
常见的评估错误
组织在多团队评估中常犯的两个错误包括:
- 选择一小部分人进行评估,结果可能不反映所有团队的能力,导致评估结果过于乐观,从而破坏客户信任和工作关系。
- 将用户故事点等同于具体的小时数,这会消除故事点的主要好处,即评估不依赖于执行工作的个体,导致管理层错误比较不同团队的速度。
多团队项目的有效评估方法
针对包含多团队的项目,有效的评估方法是建立一个所有团队都认可的共同基准评估,用于评估和跟踪共享目标的进度。
让正确的人参与
建立跨多个团队的共同基准评估的最佳方法是将每个团队的代表聚集在一起,数量取决于团队的规模和数量。团队应选择最能进行评估的人员,考虑代表的技能组合。
评估多种类型的待办事项
代表团队通过玩计划扑克等活动进行评估,最好是面对面,但也可以虚拟进行。这些代表不会评估整个待办列表,而只估计10-20个能代表工作多样性的项目。
避免每个人都对所有事项精通
并非每位评估者都需要理解待办事项列表中的每一项。选择代表广泛产品范围的项目,并且多数参与者能够参与评估是关键。这样,通过代表团队达成一致的基准评估使各团队能够统一地进行评估。
译者的观点
相对估算如故事点估算具有易于达成共识的优势,应避免将其转换为绝对估算(如具体小时数)。基准评估应覆盖多种类型的用户故事以便于快速估算。多团队环境下,全员参与会议效率低下,选择团队代表进行评估是一种更高效的方法。
Bruce Talk
Bruce Talk
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
Bruce Talk的其他文章
简约而不简单的Kanban方法
简约而不简单的Kanban方法
用户故事地图——让迭代计划灵动起来
用户故事地图也可以是一个计划工具哦。
如何进行用户故事估算——10月9日Ethan Huang分享感受
敏捷估算一直是一个无法绕开又非常令人头疼的话题。无法绕开是因为无论是产品还是项目都离不开估算。令人头疼是因为估算结果一般都很难令人满意。
Foundry IQ 解惑:它和 Azure AI Search、传统 RAG 到底什么关系?
这篇文章聚焦 Foundry IQ 最容易被误解的几个问题,讲清它与 Azure AI Search 的关系、检索流程中为什么需要 LLM,以及它和传统 RAG 的核心差别,帮助你判断它适合用在什么场景。
分享几个团队敏捷转型过程中的故事
作为ScrumMaster,有机会和不同的团队合作,会发现Team在从传统工作方式转变为敏捷开发方式的时候,会有一些相似的经历(一些弯路都会走一下)。这也是团队成长的必经之路。今天分享几个我在多个转型团队中遇到的相似的故事。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线