故事点和估算
良好的估算可以帮助产品负责人针对效率和影响力进行优化。这就是它如此重要的原因。
开始使用免费的 Jira Scrum 模板
简化您的项目，轻松规划、跟踪和管理跨多个冲刺阶段的工作。此模板包括面板、待办事项列表、路线图、报告等！
Key Takeaways
Story points are a relative estimation method in Agile that helps teams assess effort, complexity, and risk for backlog items.
Using story points instead of hours encourages team collaboration, reduces emotional bias, and improves forecasting.
Estimation techniques like planning poker and retrospectives help teams calibrate and refine their process over time.
Practice regular estimation and review past estimates to improve accuracy and team alignment on future work.
估算很难。对于软件开发人员来说，即使不是最困难的工作，也是最困难的工作之一。必须要考虑一系列因素，帮助产品负责人做出影响整个团队和业务的决策。由于事关重大，难怪从开发人员到上层管理者都容易为此焦头烂额。但这是不对的，敏捷故事点估算只是估算而已，而不是誓言。
不需要为了弥补低估的工作量而在周末加班。话虽如此，让我们来看看如何尽可能准确地进行敏捷估算。
与产品负责人协作
在敏捷开发中，产品负责人的任务是确定待办事项的优先级，待办事项列表是一个有序的工作清单，其中包含产品需要的所有功能和修复的简短描述。产品负责人从业务部门获取需求，但他们不一定了解实施的细节。因此，良好的估算可以给予产品负责人对各个工作项工作量的新见解，再反馈到他们对每个工作项相对优先级的评估中。
当工程团队开始其估算流程时，通常会出现有关需求和用户故事的问题。这非常好：这些问题有助于整个团队更全面地了解工作。特别是对于产品负责人，将工作项目分解为细小的部分并通过故事点进行估算，有助于他们确定所有工作方面（以及可能隐藏的部分！）的优先级。从开发团队那里获得估算后，产品负责人重新排列待办事项列表中项目的顺序，这样的情景也并不少见。
敏捷故事点估算是一项团队运动
让团队中的所有人（开发、设计、测试、部署... 每一个人）参与进来是关键。每个团队成员对产品和交付用户故事所需工作有着不同的看法。例如，如果产品管理想要做一些看似简单的事，比如支持新的 Web 浏览器，开发和 QA 就需要权衡一下，因为经验告诉他们，表面之下隐藏着什么样的巨龙。
同样，设计变更不仅需要设计团队的投入，还需要开发和 QA 的付出。将广泛产品团队的一部分排除在估算流程之外，会降低估算质量、削弱士气（因为关键贡献者感觉自己被排除在外），并损害软件的质量。
因此，不要让您的团队成为凭空估算的受害者。这是走向失败的快速通道！
想尝试一下故事点？首先，注册或登录 Jira
故事点和小时数
传统软件团队用时间格式来给出估算值：天、周、月。但是，许多敏捷团队已过渡到故事点。故事点是一种度量单位，用于表示全面实施某一产品待办事项或任何其他工作所需的总体工作量估算。团队根据工作的复杂度、工作量以及风险或不确定性来分配故事点。分配的值可以更有效地将工作分解为更小的碎片，以便解决不确定性。随着时间推移，这可帮助团队了解他们在一段时间内可以取得的成就，并确立对解决方案的共识和承诺。听起来可能违反直觉，但这种抽象实际上很有帮助，因为它能促使团队围绕工作难度做出更艰难的决定。以下是使用故事点的几个理由：
日期并不能考虑到不可避免地潜入我们日常且与项目无关的工作：电子邮件、会议，以及项目团队成员可能参与的访谈。
日期附有情感因素。相对估算剔除了这种情感依附。
每个团队以略有差异的尺度估算工作，这意味着他们的速度（以点数为单位衡量）自然会有不同。反过来，这使得速度无法成为用来玩政治的武器。
一旦就每个故事点值的相对工作量取得共识，您就可以快速分配故事点，无需太多争论。
故事点根据所解决问题的难度而非用时来奖励团队成员。这使团队成员专注于交付价值，而不是消磨时间。
遗憾的是，故事点经常被滥用。如果故事点被用来评判人员、分配详细时间表和资源，以及当它们被误认为是生产力衡量标准时，那就会出现问题。相反，团队应该使用故事点来了解工作的大小和优先顺序。有关故事点和估算实践的深入讨论，请观看与行业专家举办的圆桌会议，并继续阅读以获得更多敏捷估算技巧。
故事点和 Planning Poker
团队初涉故事点时会使用一种名为 Planning Poker 的练习。在 Atlassian，Planning Poker 是整个公司通用的实践方法。团队将从待办事项列表中提取一个工作项，进行简短的讨论，然后每一成员在心中做一个估算。接着，每个人拿起一张卡片，上面标有反映他们估算的数字。如果大家都同意，那很棒！否则，花一些时间（但不要太长，一两分钟即可）了解不同估算背后的理由。但请记住，估算应该是一项概括性活动。如果团队过于深入细节，请暂停一下并提高讨论的层次。
准备好试一试？
了解有关 Planning Poker 的更多信息
估算更明智，而不是更困难
任何一项任务的用时都不应超过 16 小时。（例如，如果您使用故事点，可以决定 20 点是上限。）以较高置信度估算比这更大的单个工作项，难度实在太高。而这种置信度对于待办事项列表顶部的最重要项目尤其重要。如果某一工作估计会高于团队的 16 小时（或 20 点）阈值，这便表明您可以将其分解为更精细的碎片并重新进行估算。
对于待办事项列表上排名较低的项目，请给出粗略估算。当团队真正开始处理这些项目时，其要求可能会改变，您的应用也一定会变化。所以，先前的估算不再准确。不要浪费时间估算可能有变化的工作。只要给产品负责人一个粗略数字，他们就能用它来适当确定产品路线图的优先级。
从历史估算中学习
回顾是团队从以往迭代整合洞察信息的时候，包括其估算的准确性。许多 Agile 工具（如 Jira）可以跟踪故事点，使反思和重新校准估算变得容易得多。例如，使用故事点值 8 提取团队提供的最后 5 个用户故事。就这些工作项是否都有类似的工作量加以讨论。如果答案为否，请讨论原因。在未来估算讨论中使用这一洞察信息。
就像敏捷中的其他所有内容一样，估算也是熟能生巧。随着时间推移，您会做得越来越好。