This is a very good question and I have some observations when it comes to different approaches to this problem.
Treating all bugs equally with backlog items might sound like a good idea in theory (work tracked in a single place) but doesn't work well in practice. Bugs are usually low-level and more numerous, so if you create an individual user story for each bug then the "real" stories will get obscured soon.
Explicit time in each sprint reserved for fixes is fine if done in a way that is visible for the product owner. Bugs should be mentioned during the daily scrum and discussion about bugs fixed should occur during the sprint review. Otherwise the product owner won't be aware of what's going on in the project.
Putting the whole backlog in bug tracking tool leads to the same set of problems as in 1. Moreover most bug trackers are not designed with Scrum in mind and using them for this purpose can be painful.
The solution we found the most satisfying was to put a single user story called "Tickets" or "Bugs" on every sprint. Then such a story can be divided either into low-level tasks describing a particular bug (if known during planning) or meta-tasks reserving a given number of hours for general bug fixing. This way the product owner has visibility into the process and the burndown chart reflects the progress.
Just remember to mercilessly close all "bugs" that are actually new features and create new backlog items for them. Also make sure to fix all the bugs reported against the current sprint before the sprint is over in order to consider the sprint as done.
If the bug is easy/quick to fix (one liner, etc), then just fix it.
If the bug is not trivial, and not a blocker, then add it to the backlog.
If the bug is a blocker then add a task (to the current sprint) to capture the work required to fix it, and start working on it. This requires that something else be moved (from the current sprint) to the backlog to account for the new hours because your total hours available hasn't changed.
The first step is to define what a bug is. I teach that a bug is only a bug if it is functionality that does not work in production as it was intended/designed. These become bug type PBIs to be prioritized against new development. Missing functionality in production is a Feature and becomes a normal product backlog item. Any defective code found during a sprint is considered incomplete work and since you don't move on to the next story until the current one is done-done; it is unnecessary to track these defects in the sprint as the team is always working on the offending code. Post-its can be super handy here for quick reminders between team-mates. Fixing broken code always takes precedent over writing new code. If the defects are due to misunderstanding the story then you need to work on your conditions of acceptance before starting the story.
Inventory is waste. Bug tracking is inventory. Bug tracking is waste.
Treating all bugs equally with backlog items might sound like a good idea in theory (work tracked in a single place) but doesn't work well in practice. Bugs are usually low-level and more numerous, so if you create an individual user story for each bug then the "real" stories will get obscured soon.
If you have that many more bugs than features then you need to work on your engineering practices. This is a smell that something else is wrong and tracking is not the answer. Dig deeper. Actually bugs are always smelly. They aren't cool and if you have lots of them you need to find the root causes(s), eliminate those, and stop focusing on tracking bugs.
Don't track defects on a list, find them and fix them -- Mary Poppendieck
Indeed, If inventory is waste, what about an inventory of defects...
That's why I always try to implement a Stop-the-Line mentality with test-driven development and continuous integration, so that we find and fix most defects instead of putting them on a rework list.
And when defects pass through, we fix them before writing new code (stories with bugs aren't done anyway). Then, we try to fix our process to make it more mistake-proof and detect defects the moment they occur.
There is no one size fits all solution and each project is different. Bugs might also be categorized from mission critical to hardly worth fixing.
Unless critical to the running of the system, I prefer bugs to become story cards. That makes the priority of feature development vs. bug fixing really explicit. In a scenario where bug fixes are considered to be "outside of the sprint" the bug fixing might move toward fixing really trivial bugs while really important business features aren't being developed.
We've gone trough a number of permutations before setting on the bug as a story approach. Try some different things and replay them at team retro meetings.
In our case (greenfield development, 2-3 devs) found bugs are written down, marked clearly as a bug and based on their severity they are assigned to next iteration or left in the backlog. In case of critical and urgent bugs they are added to the ongoing iteration.
I don't know why something as simple as fixing bugs is complicated with rules.. Scrum has very few rules, remember? Every feature, Support, Recommendation or Defect is a Backlog issue in Scrum, there is no differentiation. So, as the Scrum guide says: the tasks in a Sprint are never limited to what you decide during the planning meeting the Daily Scrum helps people discuss "impediments" along their way.
Why?
So you discuss and think rationally as a team if you want the defect i.e. backlog issue to go into PBI or remain in this Sprint and deliver it...
Better question is how do I stop creating bugs in development phase? see--> http://bit.ly/UoTa4n
If you are identifying and documenting bugs you will have to triage and fix then at some future time. This leads to "stabilisation sprints" i.e. one whole sprint just to fix bugs. Or you can add them back to the backlog and prioritise them as part of some future sprint. It also means that you will are providing and expect to get signed off and released software with known bugs in it (P3 & P4 aka cosmetic and minor).
I have tabled the idea in our project to introduce a short bug fix sprint every third sprint. Our current sprints are three weeks.
The idea is that it will allow all dev to focus on bug fixing together, allow focus on just new stories in regular sprints and keeps a regular focus on reducing tech debt.
Bug fixes will be grouped into relevant stories and prioritised. Emphasis is not on sizing before the sprint as devs struggle to size bug fixes without getting stuck in to understand the nature of the defect.
Has anyone tried this or have any feedback on how they think this might work?
发布评论
评论（9）
这是一个非常好的问题，当涉及到解决这个问题的不同方法时，我有一些观察。
我们发现最令人满意的解决方案是在每个冲刺中放置一个名为“Tickets”或“Bugs”的用户故事。然后，这样的故事可以分为描述特定错误的低级任务（如果在计划期间已知）或为一般错误修复保留给定时间的元任务。这样，产品所有者就可以了解流程，并且燃尽图可以反映进度。
只要记住无情地关闭所有实际上是新功能的“错误”，并为它们创建新的积压项目即可。还要确保在冲刺结束之前修复当前冲刺报告的所有错误，以便将冲刺视为已完成。
This is a very good question and I have some observations when it comes to different approaches to this problem.
The solution we found the most satisfying was to put a single user story called "Tickets" or "Bugs" on every sprint. Then such a story can be divided either into low-level tasks describing a particular bug (if known during planning) or meta-tasks reserving a given number of hours for general bug fixing. This way the product owner has visibility into the process and the burndown chart reflects the progress.
Just remember to mercilessly close all "bugs" that are actually new features and create new backlog items for them. Also make sure to fix all the bugs reported against the current sprint before the sprint is over in order to consider the sprint as done.
实际上，我认为最好的答案是 jpeacock 从这个问题 您是否将花在 bug 修复上的时间计算到 scrum 中？
让我引用一下：
衬垫等），然后修复它。
阻止程序，然后将其添加到待办事项中。
任务（到当前冲刺）
捕获修复它所需的工作，
并开始研究它。这
需要移动其他东西
（从当前的冲刺）到
积压以适应新的工作时间
因为您的总可用时间
没有改变。
Actually I think that best is answer by jpeacock from this question Do you count the hours spent on bug fixes towards the scrum?
Let me cite it:
liner, etc), then just fix it.
blocker, then add it to the backlog.
task (to the current sprint) to
capture the work required to fix it,
and start working on it. This
requires that something else be moved
(from the current sprint) to the
backlog to account for the new hours
because your total hours available
hasn't changed.
第一步是定义什么是错误。我教导说，只有当某个功能无法按照预期/设计在生产中运行时，该错误才算是一个错误。这些成为 bug 类型的 PBI，针对新开发优先考虑。生产中缺少的功能是一个功能，并成为正常的产品积压项目。在冲刺期间发现的任何有缺陷的代码都被认为是不完整的工作，因为在当前的故事完成之前你不会继续下一个故事；没有必要在冲刺中跟踪这些缺陷，因为团队始终致力于处理有问题的代码。便利贴在这里非常方便，可以在队友之间快速提醒。修复损坏的代码始终优先于编写新代码。如果缺陷是由于误解故事造成的，那么您需要在开始故事之前确定接受条件。
库存就是浪费。错误跟踪就是库存。错误跟踪是浪费。
如果你的错误比功能多得多，那么你需要改进你的工程实践。这是一种其他问题的气味，并且跟踪不是答案。深入挖掘。事实上，虫子总是有臭味的。它们并不酷，如果您有很多它们，您需要找到根本原因，消除它们，并停止专注于跟踪错误。
The first step is to define what a bug is. I teach that a bug is only a bug if it is functionality that does not work in production as it was intended/designed. These become bug type PBIs to be prioritized against new development. Missing functionality in production is a Feature and becomes a normal product backlog item. Any defective code found during a sprint is considered incomplete work and since you don't move on to the next story until the current one is done-done; it is unnecessary to track these defects in the sprint as the team is always working on the offending code. Post-its can be super handy here for quick reminders between team-mates. Fixing broken code always takes precedent over writing new code. If the defects are due to misunderstanding the story then you need to work on your conditions of acceptance before starting the story.
Inventory is waste. Bug tracking is inventory. Bug tracking is waste.
If you have that many more bugs than features then you need to work on your engineering practices. This is a smell that something else is wrong and tracking is not the answer. Dig deeper. Actually bugs are always smelly. They aren't cool and if you have lots of them you need to find the root causes(s), eliminate those, and stop focusing on tracking bugs.
事实上，如果库存是浪费，那么缺陷库存又如何......
这就是为什么我总是尝试实施 Stop-the-Line 以测试驱动开发和持续集成的心态，这样我们就能发现并修复大多数缺陷，而不是把它们放在返工清单上。
当缺陷出现时，我们会在编写新代码之前修复它们（无论如何都不会完成有错误的故事）。然后，我们尝试修复我们的流程，使其更加防错，并在缺陷发生时立即发现它们。
Indeed, If inventory is waste, what about an inventory of defects...
That's why I always try to implement a Stop-the-Line mentality with test-driven development and continuous integration, so that we find and fix most defects instead of putting them on a rework list.
And when defects pass through, we fix them before writing new code (stories with bugs aren't done anyway). Then, we try to fix our process to make it more mistake-proof and detect defects the moment they occur.
没有一种适合所有情况的解决方案，每个项目都是不同的。错误也可以从关键任务到几乎不值得修复进行分类。
除非对系统的运行至关重要，否则我更喜欢将错误变成故事卡。这使得功能开发与错误修复的优先级变得非常明确。在错误修复被认为是“冲刺之外”的情况下，错误修复可能会转向修复真正微不足道的错误，而真正重要的业务功能尚未开发。
在将错误设置为故事方法之前，我们已经进行了多次排列。尝试一些不同的事情，并在团队回顾会议上重温它们。
There is no one size fits all solution and each project is different. Bugs might also be categorized from mission critical to hardly worth fixing.
Unless critical to the running of the system, I prefer bugs to become story cards. That makes the priority of feature development vs. bug fixing really explicit. In a scenario where bug fixes are considered to be "outside of the sprint" the bug fixing might move toward fixing really trivial bugs while really important business features aren't being developed.
We've gone trough a number of permutations before setting on the bug as a story approach. Try some different things and replay them at team retro meetings.
在我们的案例中（绿地开发，2-3 名开发人员）发现的错误被记录下来，清楚地标记为错误，并根据其严重性将它们分配给下一次迭代或留在待办事项中。如果出现严重和紧急的错误，它们将被添加到正在进行的迭代中。
In our case (greenfield development, 2-3 devs) found bugs are written down, marked clearly as a bug and based on their severity they are assigned to next iteration or left in the backlog. In case of critical and urgent bugs they are added to the ongoing iteration.
我不知道为什么像修复错误这样简单的事情会因为规则而变得复杂。Scrum 的规则很少，还记得吗？
每个功能、支持、推荐或缺陷都是 Scrum 中的 Backlog 问题，没有区别。因此，正如 Scrum 指南所说：
Sprint 中的任务永远不会局限于您在计划会议期间决定的内容
Daily Scrum 帮助人们讨论前进道路上的“障碍”。
为什么？
因此，如果您希望缺陷（即积压问题）进入 PBI 或留在本 Sprint 中并交付它，您作为一个团队进行理性讨论和思考...
I don't know why something as simple as fixing bugs is complicated with rules.. Scrum has very few rules, remember?
Every feature, Support, Recommendation or Defect is a Backlog issue in Scrum, there is no differentiation. So, as the Scrum guide says:
the tasks in a Sprint are never limited to what you decide during the planning meeting
the Daily Scrum helps people discuss "impediments" along their way.
Why?
So you discuss and think rationally as a team if you want the defect i.e. backlog issue to go into PBI or remain in this Sprint and deliver it...
更好的问题是如何停止在开发阶段产生错误？
参见--> http://bit.ly/UoTa4n
如果您正在识别并记录错误，则必须在以下位置进行分类和修复未来的某个时间。
这会导致“稳定冲刺”，即只是为了修复错误而进行的整个冲刺。或者，您可以将它们添加回待办事项列表中，并将它们作为未来冲刺的一部分进行优先排序。
这也意味着您将提供并期望获得签名并发布包含已知错误的软件（P3 和 P4 又名化妆品和次要错误）。
这不是真的敏捷吗？
Better question is how do I stop creating bugs in development phase?
see--> http://bit.ly/UoTa4n
If you are identifying and documenting bugs you will have to triage and fix then at some future time.
This leads to "stabilisation sprints" i.e. one whole sprint just to fix bugs. Or you can add them back to the backlog and prioritise them as part of some future sprint.
It also means that you will are providing and expect to get signed off and released software with known bugs in it (P3 & P4 aka cosmetic and minor).
This is not really agile?
我已经在我们的项目中提出了每隔三个冲刺引入一个简短的错误修复冲刺的想法。我们当前的冲刺是三周。
这个想法是，它将允许所有开发人员一起专注于错误修复，允许在定期冲刺中只关注新故事，并定期关注减少技术债务。
错误修复将被分组到相关的故事中并确定优先级。重点不在于冲刺之前的规模调整，因为开发人员很难在不深入了解缺陷本质的情况下确定错误修复的规模。
有没有人尝试过这个或对他们认为这可能如何运作有任何反馈？
干杯，
凯文.
I have tabled the idea in our project to introduce a short bug fix sprint every third sprint. Our current sprints are three weeks.
The idea is that it will allow all dev to focus on bug fixing together, allow focus on just new stories in regular sprints and keeps a regular focus on reducing tech debt.
Bug fixes will be grouped into relevant stories and prioritised. Emphasis is not on sizing before the sprint as devs struggle to size bug fixes without getting stuck in to understand the nature of the defect.
Has anyone tried this or have any feedback on how they think this might work?
Cheers,
Kevin.