对软件开发人员来说，敏捷估算可能是最困难的工作之一，因为它必须考虑一系列因素，这些因素包括对整个团队、业务的影响，以及与各方的利害关系等，这些都将影响产品负责人的决策。敏捷估算是一种预估，但不是准确的结果，也不是对结果的承诺。下面，文章将介绍一些使敏捷估算尽可能准确的方法。
一、有哪些方法可以使敏捷估算更准确？
1.与产品负责人合作
在敏捷开发中， 产品负责人的任务是确定产品待办列表（Product Backlog）的优先级，产品待办列表中包含产品所需功能特性和缺陷的简短描述。产品负责人从业务中收集需求，但他们不一定了解每个需求实现的细节，所以好的敏捷估算可以让产品负责人对工作项的工作量有新的了解，并反馈到工作项优先级评估中。
在团队做估算时，通常会面临需求和用户故事拆解的问题，这些问题有助于团队更全面地理解需求，特别是对产品负责人（Product Owner）来说，将需求分解成细粒度的用户故事并进行故事点估算，有助于将所有工作（甚至是一些隐藏工作）都纳入优先级排序的范围。开发团队评估后，产品负责人基于评估进行产品待办事项列表重新排序。
2.敏捷估算是一项团队运动
敏捷估算时，关键是让团队中的每个人（开发人员、设计人员、测试人员、部署人员……每个人）都参与进来，因为团队不同成员对产品和交付用户故事要做的工作的理解不同。
例如，产品经理希望做一些看似简单的功能：产品支持新的 Web 浏览器，这时开发和 QA 一定会说这个功能不简单。
因此，在评估时，将团队的一部分成员排除在外将会影响评估的准确性，影响团队士气和产品质量，最终可能导致产品失败。
您可以注册或登录 PingCode >>尝试估算故事点。
在PingCode中，支持创建您的第一个 Scrum 项目，学习如何估算和追踪您的用户故事。
3.故事点与工时
传统软件团队以工时的方式（天、周、月）评估故事点，而许多敏捷团队则已转向故事点。故事点是衡量完成产品待办事项或其他工作所需总体工作量的度量单位。团队根据工作复杂性、工作量以及风险或不确定性来分配故事点，从而更有效地将工作分解成更小的部分，以降低不确定性。随着时间的推移，团队可以通过故事点了解一段时间内可以实现多少目标，并就解决方案交付时间和工作量方面的建立共识以及合理承诺。
以下是建议使用故事点的几个原因：
- 时间估算很难考虑日常工作中与项目无关的工作：如发送邮件、会议和面试；
- 时间估算受个人因素影响，相对估计消除了这个影响；
- 速度（单位时间内完成故事点数量）不能作为评估标准，因为每个团队对故事点的估算标准不同；
- 一旦团队就每个故事点的值要做的工作达成一致，就可以快速确定故事点，不需要太多争论；
- 故事点鼓励团队成员在解决问题考虑难度而不是花费的时间，使团队成员专注于价值。
但需要注意的是，故事点经常被滥用。当故事点被用来判断人员、时间、资源分配，以及作为衡量生产力的标准时就会出错。相反，团队应该使用故事点来了解工作的大小和工作的优先级。
4.用扑克牌的方式估算故事点
使用”扑克牌”进行估算是包括我们在内的很多团队都会使用的方法。产品负责人从待办事项列表中选取一个工作项，进行简要描述和讨论，每个成员在心里进行估算。然后每人拿出一张卡片，上面写着反映他们估算的数字。如果每个人的数字都一致，就结束然后进行下一个工作项评估，如果不一致，可以花一些时间(几分钟)理解不同估算背后的原因。
在 PingCode 中，团队可以使用“敏捷估算器”进行故事点估算，估算时采用斐波那契(Fibonacci)数列，提高团队评估效率。
5.灵活的估算
任何单个任务的工作时间都不应超过 16 小时（你也可以根据团队的习惯，设置20个故事点是上限），当某件事的估计值超过团队的 16 小时（或20个故事点）阈值时，这是一个信号，可以将其分解为更精细的用户故事并重新估算。
对于产品待办事项列表中短时间不会开始的项目，给出粗略估计就可以了。因为当团队实际开始处理这些项目时，估算的标准可能已经发生变化。因此，故事点早期的估计不会那么准确，所以不要浪费时间估计可能发生变化的工作。只需给产品负责人一个大概的数字，以便她可以用来适当地确定产品路线图的优先级。
6.从过去的估算中学习
通过回顾帮助团队从过去的迭代中评估估算值的准确性。许多敏捷工具（如 PingCode）跟踪故事点，这使得反思和重新校准估计变得更加容易。例如，试着调出团队交付的最后5个用户故事，假设故事点值为8，讨论这些工作项中的每一项是否具有相似的工作水平。
