Answers:
理想情况下，您的软件应该在每次迭代后都没有错误，并且修复错误应该是每个sprint的一部分，因此在分配故事点时应考虑修复错误所需的工作（即，更可能产生错误的任务应有更多的故事点分配给它）。
但实际上，无论测试多么严格，错误始终会在部署后浮出水面。当发生这种情况时，删除错误只是另一个更改，如果可以的话，可以使用此功能。在这种情况下，错误报告和功能请求之间没有根本区别：在两种情况下，应用程序都显示出某种行为，并且用户（或其他利益相关者）希望看到它有所更改。
从业务的角度来看，错误修正和功能实际上是相同的：要么执行（方案B），要么不执行（方案A）；两种情况都附带有成本和收益，一个体面的业务人员会权衡它们，并选择能为他们带来更多利润的东西（长期或短期取决于业务策略）。
因此，是的，一定要为错误分配故事点。您还打算如何确定错误与功能以及针对错误的优先级？两者都需要某种程度的开发工作量，并且最好具有可比性。
最大的问题是错误修正通常更难估计：实际努力的90％或更多在于寻找原因。一旦找到它，就可以得出准确的估算值，但是几乎无法判断搜索将花费多长时间。我什至看到过很多错误，其中大部分时间都花在试图重现该错误上。另一方面，根据错误的性质，通常可以在进行估计之前，通过一些最少的研究来缩小搜索范围。
正如在其他答案中已经指出的那样，用点来估计错误本质上是困难的，是的，理想的解决方案是在接受sprint之后在功能中发现的错误应被视为新功能。
但是，这种错误的点估计困难是Agile PM软件包允许在数小时内估计任务和错误的许多原因之一，因为要熟练掌握点估计需要花费很多精力和经验。许多项目在正确确定速度时会遇到重大问题，因此许多敏捷项目使用点来确定将哪些故事纳入冲刺中，但是在计算燃尽图时会花费数小时。
只要不将小时数估算值用作确定冲刺承诺的因素，这似乎很直观但可以管理。过度使用自然会导致功能缺失或不完整或超时，因此随着时间的流逝，所有相关人员都被迫在点估计上变得更好，这时，估计任务和错误的小时数将逐渐成为毫无意义的指标。
您不应该指出错误解决方案。考虑以下事实：该错误来自故事，开发人员已经通过完成故事而获得了积分。它不应再从实际上不应该赢得积分的地方再次获得积分。
错误修复应该对速度产生负面影响。否则，下降的质量最终会受到不受影响甚至提高的速度的奖励！
也许有用的链接：
估算故事的依据是，随着时间的推移，团队会获得解决故事的经验。通过它，可以提高准确性，并可以建立速度来衡量车队的速度。建立未来冲刺可靠预测的理想方法。
对于软件开发公司而言，错误是生活中不可或缺的事实。尽管我同意在编写故事时应该发现所有错误，但接受每个工作组都应计划的事情，即不能始终做到这一点。与其固执地认为流程应该统治团队，不如反过来。
当然，无论是错误还是故事，从业务方面来讲，团队处理的内容都没有关系。两者都可以为产品所有者带来同等数量的价值。
在我们的团队中，我们尝试了一些估算错误的技术：
对于1.，我们失败了。对于大多数错误，我们发现90％的时间都花在了错误分析上。之后，可以以与故事相同的方式估算错误修复。通过将错误计划到一个Sprint中，我们犯了一个错误，即未知范围会影响故事的解析度，直到我们这样做的每个Sprint都失败了。
基于选项2的90/10比率（分析与错误修复）估算技术，确实意味着我们必须计划分析，而这并不是sprint计划所涵盖的内容（我们从选项1中学到了，但是没有真正的解决方案如何处理已分析的错误）。结果是没有进行错误分析，因为冲刺专注于计划的项目。团队没有时间专注于积压的错误。所以最终他们也没有完成。
通过拥抱不确定性，我们现在选择了选项3。我们将产品积压工作分解为常规的故事/任务部分，团队可以使用故事点和错误积压工作来估算该部分。在错误积压中，产品所有者根据业务价值和非常粗略的团队判断对错误进行排名。团队允许在sprint期间分配大量的时间，使他们可以专注于bug。产品负责人不知道确切的结果，因为以前不可能进行任何计划。可以根据每个sprint的当前状态以及内容的重要性和业务价值来调整每个sprint的bug待办事项与常规待办事项的比率。
通过消除不确定性，它的确释放了团队。Sprint不受未知错误的影响。通过将错误分为不同的待办事项列表，既增加了团队的常规冲刺重点，又使我们完成了包含重要业务价值的错误。
因此，这取决于故事点是否适合您。我将尝试首先使用故事点来估计错误。如果失败，请尝试我的选择3。这使我们的团队（超过30个sprint）再次关注具有较大商业价值的较旧的bug。这也使我们摆脱了试图提供团队根本无法估计的东西的负担。拥抱未知因素使我们更接近现实，也使我们的冲刺再次成功，同时通过错误修复提供了很大的业务价值（基于错误与故事的比率）。我们最近使用的比率是50/50。
我必须不同意将错误点分配给故事的最佳答案。故事点应该是为了交付新的价值。如果您要为产品价值和非价值项目分配积分，则最好估算并跟踪小时数。
错误是您昨天所做的工作的开销，并不表示产品完成的速度，它们也不会创造任何新的产品价值（考虑一下）。错误有点像中断，您需要每周处理所有其他母牛皮。故事要点的整体思想是，它跟踪/估计我们何时交付产品（或功能集）。故事点是任意的，这就是它从估计中消除所有非价值开销的方式。通常，非价值工作每周都会保持不变，因此它是团队速度的一部分。当他们删除或减少这项非有价值的工作时，团队将加速。
换句话说，为什么还要跟踪漏洞？这样一来，您最终知道每个成员做了多少“工作”？别搞了！坏经理！:)衡量团队，而不是球员。如果一个人没有减轻体重，鼓励团队进行自我管理。更有效。进行故事重点项目不应使个人感觉更好，但是在冲刺结束时做出承诺时，整个团队应该感觉更好。在体育运动中，目标对团队或个人有益吗？如果个人为自己比赛，那么从长远来看，球队会输掉比赛。
您知道，最终您根本不想使用点。估算是花费在实际工作上的时间。当团队达到最高极限时，他们根本不使用积分，但确切地知道他们可以拉入冲刺的项目数。他们已经掌握了将工作单元分解为零的艺术，因为估计是过程浪费。
有些任务是可以估计的，有些则不是。 对于无法估计的事情，请使用预算。
修复缺陷不是容易估计的任务，因为它有几个未知的组件。是什么导致缺陷？了解原因后，如何解决？此更改对系统的其余部分有什么影响？您注入了多少新缺陷来修复此缺陷？
请记住，导致缺陷的原因可能来自软件生命周期中的任何时候-误解或传达的要求，不良的设计或错误的假设，不良的编码，不良的测试，根据从当前版本中学到的信息获得的有关问题的新知识...
可以通过几种不同的方式来完成错误修复任务的预算。这是我有效使用的一些想法：
然后，您的目标是在分配的预算内修复尽可能多的缺陷。与您的客户战略讨论优先报告的缺陷。例如，您是否按重要性然后按优先级对缺陷进行分类？严格的优先级？您应该首先攻击“低落的果实”吗？UI Bug首先？
另外，修复错误不会带来任何价值。修复缺陷是一种浪费。您已经在该功能上获得了价值，因此您不应因修复错误而获得“加分”。
有了预算有助于计划，但仍可以为您准确了解速度。预算特定数量的漏洞用于修复，根据您的历史数据为预算分配大约时间，然后在预算的时间内尽可能多地压缩漏洞！
我发现与其专注于故事，错误和琐事以及每一个要点，不如专注于为客户提供功能。
客户期望该软件能够正常运行，并且只有在开发，增强功能和新功能推动业务发展的过程中，才真正赋予它们真正的价值。
错误修复，尽管可能非常重要，但并不能将业务推向新领域和新客户（切向，最终也许是，但不是立即，这是管理层正在衡量的）。
因此，最好从较高的速度观点来查看分数，并且从历史上每周对类似得分的故事完成了多少分数。
这可以通过跟踪记录的历史来进行管理，而不是迫切需要完成本周的故事，并经常发现事实并非如此。但是，由于失去了前期控制权和增加的信任度，一些经理会惊慌失措。
我使用Pivotal Tracker（我也有JIRA，Trak，Trello和其他工具），Pivotal Tracker也不会为琐事或漏洞做点说明。这样做的原因与上面相同，在JIRA中也是如此，就像您看到的一样。