在了解错误并开始修复以估计工作何时完成后，我们使用“签入日期”（预计完成日期）。但我们使用错误打开之前的实际日期，直到它被解决，以帮助我们跟踪错误和工作项的进度。

在燃尽图或下滑图中，我们根据实际打开日期跟踪活动问题（错误或工作项）的数量和打开 > 72 小时的活动问题的数量。

本质上，我们正在关注趋势。例如，如果活动问题的数量 >72 小时等于活动问题的数量，那么我们可以预测问题没有足够快地得到解决，而未解决的问题数量通常会飙升。

由于每天在他们的功能区域中领导分类问题，我们可以重新分配/重新确定工作的优先级，以确保重要的事情得到解决，并且及时发生烧毁而不会使人员筋疲力尽。

我参与过的几乎每个团队都处理过这个问题的方式是，产品团队的某些子集会定期对错误进行分类——通常是开发主管、QA 主管和 PM 主管。分类小组负责确定错误是否符合要修复的标准，并将其分配给适当的团队成员进行修复。在分类期间，可以将错误分配到几个不同的分类状态：1. 接受 2. 拒绝 3. 调查

如果需要更多信息以确定是否应接受或拒绝，则应将其置于 Investigate 状态。如果它被接受，那应该意味着分类团队已经非常清楚它有多大的工作项以及分配给它的团队成员的可用性。

任何花费在调查和/或修复和/或单元测试已被接受的错误上的时间都被视为花费在修复错误上的时间。出于我能想到的任何目的，没有必要将其分解。即使准确地跟踪修复错误需要多长时间也感觉不是非常可操作的数据。我唯一能想到它会发挥作用的情况是，如果分类团队认为一个错误是一个快速修复并且它最终变得更加复杂，那么这只是与开发人员交谈的问题（希望在日常站立会议中）了解修复需要多长时间。尽管如此，对于管理发布而言，这将更多地基于具体情况，并且在考虑用于制定未来业务决策的趋势数据时不太有用。

为什么您需要知道缺陷的存在时间以及是否正在处理它们？这是为了确保您按计划发布吗？似乎更直接的方法是与每个开发人员讨论他们正在做什么以及他们希望在下一个里程碑之前完成什么。这是您从每日站立会议中获得的巨大价值。

“他们并没有真正受到惩罚或奖励，但根据这些统计数据，他们可能会受到困扰。”

他们确实受到了惩罚——被“打扰”是一种惩罚。当人们像这样被衡量和惩罚时，他们很快就会学会玩这个系统。

考虑将缺陷分配给人们，并找到一种方法来了解他们正在做什么，而不会被视为“麻烦”。有时与人交谈，而不是依靠跟踪系统，效果更好。

如果您正在跟踪修复时间，则应根据优先级应用它。P1 小时、P2 天、P3 周等。随着缺陷变老，它们可以重新评估。但我发现修复缺陷结束了这些讨论。如果花费的时间太长，通常意味着功能优先于积压中的技术债务。可以增加每个 sprint 中的数量以消除缺陷。

如前所述，QA、dev 和 PM 共同设置 priority.Product Mangers 是否影响功能交付。