backlog与bug

我们采用jira来做bug跟踪系统，同时会将backlog与拆分的任务维护在jira上。

我们每一次sprint都会经历需求确认，开发，测试，部署上线的完整流程。

如果在到达发布日期时仍有没有修复的bug该如何处理呢？

一般来说应该对每一个bug进行分析，如果不属于严重bug，则可以结束当前的sprint，

否则当前的sprint宣告失败，需要重新进行评估。

如果在下一次sprint中包含bug，则应该在进行计划时由项目负责人对bug进行评级，由他挑选出优先级高的bug，放到这次的sprint backlog中。

有一些方法供尝试：

1) 产品负责人打印出Jira中优先级最高的一些条目，带到sprint 计划会议中，跟其他故事一起贴到墙上（因此就暗暗地指明了这些issue相对其他故事的优先级）。
2) 产品负责人创建一些指向Jira条目的故事。例如“修复那几个后台报表最严重的bug，序号是Jira-124、Jira-126，还有Jira-180”。
3) 修复bug被当作sprint以外的工作，也就是说，团队会保持一个足够低的投入程度（例如50%），从而保证他们有时间来修复bug。然后我们就可以简单假设，在每一个sprint中，团队都会用一些时间来修复Jira上报告的bug。
4) 把产品 backlog放到Jira上（也就是放弃Excel）。把bug与其他故事同等看待。