Your third answer is the best method. A sprint is simply a commitment by the team to complete a specified amount of work in a defined period of time. If you're accepting additional work in the middle of the sprint, you're deviating from that original commitment by working on things that were not committed to by the team at the beginning of the sprint.
Here's what we do:
All stories within a sprint must be defect free in order to be considered "done"
Any defects that are found during a sprint for a previously completed story are logged and put into the backlog. They're estimated just like anything else and prioritized by the product owner. If a product owner prioritizes new features over defects, they're choosing functionality over quality and vice-versa.
We don't assign story points to defects, but we do estimate every defect as it gets accepted into a sprint as part of planning. The team shouldn't get credit for broken functionality, but by the same token the time it takes to fix them needs to be recognized -- this accomplishes both.
Here's the problem with your other solutions:
Have a story that says "90% of bugs fixed in the app" where you then guess how many bugs will emerge in that sprint and how many can be fixed and then point it based on the anticipated workload
Again, see above. You want to avoid empty buckets of work that can be filled during the sprint. This defeats the purpose of a defined commitment by the team. How can the team commit to something they don't know about or haven't estimated?
Plus, this can easily spiral out of control into a product owner that will "design by defect" by filling that bucket with nice-to-have functionality that is really masquerading as defects.
Have a story of size, say, 8 that is ALWAYS accepted at the end of the sprint where you fix as many bugs as you can. This obviously requires a great deal of trust that everybody is actually doing an 8's worth of work
This sounds strange. The team should be accepting work at the beginning of the new sprint planning, not at the end of the previous sprint. Additionally, this will really skew your velocity over the long term. Scrum refers to Product Backlog Items, not just Stories, so there's nothing to say that you can't include defects as PBI's.
Record bugs but do not work on them until the next sprint. They can be pointed individually or as a group. This has the advantage of being more "Scrummy" but causes a three week delay for what are essentially 1 hour fixes.
You make an interesting point and we had some concern about this as well. However, that 1 hour fix (regardless of how quick it is) may not be time well spent when stacked up against the other things in the backlog. The bottom line is you want to push these decisions off to the product owner and give them the freedom to prioritize EVERYTHING the team spends effort on.
I firmly believe that a process is only as good as it's ability to improve a situation. The process should work for you, not the other way around.
If following the Agile Scrum process to the 'T' is doing more harm than good, in this situation, then it is time to find a better solution outside of the Scrum process.
We have created a mini 'QA' sprint that is tacked on to the end of every sprint. It is after code complete but before release. In this short time period issues are carefully scrutinized and can be approved for inclusion based on risk and criticality. Issues fixed in this time period have some extra level of a custom review process, but work largely outside of the defined Scrum process.
Have you identified during your retrospective the cause of these bugs? Are you using engineering (XP) practices i.e., doing TDD - test driven development, autoamted functional tests will daily full regression testing along with pairing and story cards with acceptance criteria.
When a defect is found, is the root caused identified and is an automated unit and functional test added to your test harnesses to catch such a defect should it occur again?
From my understanding, your defect rate is too high. If one does TDD and full functional regression tests at least daily, it is not uncommon to reach zero defects during UAT.
In the short term, you can charge the team x number of units/ points of work to fix the defects (look at your past iteration and if it takes x number of hours per iteration to clean up the small bugs, subtract that time from your team's capacity.) Longer term, focus on the root cause and improve your team's engineering practices.
From measuring the cost of defect fixes, we have seen the following relationship. If a defect cost 1x during development, it cost 2x to fix during functional test, 3x to fix during UAT and 4x to fix when in production. By writing story cards with acceptance criteria, pair developing, test driven development and automated functional test with at least daily full regression testing, you will improve quality and reduce cost significantly. As a result, you will not need to subtract any time from your team's capacity which will improve velocity.
This is a fine example of the strong need for sound engineering practices in Scrum projects.
"[we're] running into trouble with a bunch of tiny bugs that appear after code has been accepted"
This suggests that your "definition of done" is not strong enough.
"These include things such as spelling errors"
Do these spelling errors appear on the UI? Whomever is spotting them after the code is accepted should be spotting them before the code is accepted.
The thing to do with defects is 1) fix them right now, 2) instrument the system so that similar defects will be caught earlier next time and 3) improve your process so that the kind of error that lead to the defect is less likely to occur in future. These are all technical issues.
I have had the following policies succeed in my projects:
Defect correction is always prioritized over feature development. The target is to have zero open defects at all times, valuing 100% working features over almost-working features.
Defects can and should be fixed as soon as they are found. A ticket needs only to be filed if the defect is found by some non-developer or the developer finding it cannot fix it instantly.
Defects that require architecture-level changes to the code base have the architecture tweaking part logged as a story and estimated & planned to some upcoming sprint. The defect status is set to be pending on the story implementation.
Sprint backlog is protected from external changes, but the team itself may introduce new stuff in the middle of a sprint that is required to meet the zero defects at all times target.
If a defect is not worth fixing (based on some rudimentary cost-benefit analysis), then it simply ignored to prevent won't-fix open defects from polluting the issue tracker.
Prioritizing defect fixing over story implementation will hit your velocity from time to time, but it's ok. In the long run, your efficiency in implementing stories will increase as the code base has only a little technical debt in it.
what we normally do, in case the Bug are unrelated to what you are developing, or let's say any other "unrelated" activity happening during a sprint, is to create a "Contingent".
It is basically a certain amount of time that will be removed from your "capacity" for a sprint, and will be dedicated on demand to do activities outside of the sprint goal. This works the following way:
Daily the team focus on the Sprint Goal, but has a "buffer" of time (the Contingent) to take care of external issues. At the Daily stand-up the PO may present daily incoming issues, and the Team Members that completed a Sprint task (so there is no interruption) will eventually take one of the issues to fix.
The time is that booked on the contingent, that when comes to an end will have to be closed.
The Team has the right to communicate to the Product Owner that the time in the contingent is over, and that if he wants them to keep the Sprint commitment, he will have to decide whether he want them to do so, or continue running after daily issues, giving up some value out of the Sprint.
It always worked out to be a fair deal ;-)
We use it for the following: Bug and Maintenance of the live product (5-15%), preparation of the upcoming sprint (10%)...
如果您在 Google 上搜索“技术债务” 或使用 Scrum 来查看其他人如何处理这些事情可能还有其他想法。
Who handles the support for the code you push into production? If your team does handle support requests then these typos and other cosmetic problems fall into that category and get handled appropriately. If not, then you may have to have the occasional sprint be kind of like a "patching" sprint where no new functionality is added but many old things are fixed and technical debt is reduced to a reasonable level. Or combine a bug of the little bugs into one story of say "Fixing all typos on the site" for an idea.
If you Google up "technical debt" or "broken windows" with Scrum to see how others handle these things there may be other ideas out there.
发布评论
评论（8）
你的第三个答案是最好的方法。 冲刺只是团队在规定的时间内完成规定数量的工作的承诺。 如果您在冲刺中期接受额外的工作，那么您就偏离了最初的承诺，从事了团队在冲刺开始时未承诺的事情。
我们要做的是：
这是您其他解决方案的问题：
有一个故事说“应用程序中修复了 90% 的错误”，然后您猜测该冲刺中会出现多少错误以及可以修复多少错误，然后根据预期工作量
再次参见上文。 您希望避免在冲刺期间可以填充的空工作桶。 这违背了团队明确承诺的目的。 团队如何能够致力于他们不知道或没有估计的事情？
另外，这很容易失控，导致产品所有者“按缺陷进行设计”，用真正伪装成缺陷的漂亮功能来填充这个桶。
有一个大小为 8 的故事，在冲刺结束时始终被接受，您可以在其中修复尽可能多的错误。 这显然需要极大的信任，相信每个人实际上都在做 8 分的工作
这听起来很奇怪。 团队应该在新的冲刺计划开始时接受工作，而不是在上一个冲刺结束时接受工作。 此外，从长远来看，这会真正影响你的速度。 Scrum 指的是产品待办事项列表项目，而不仅仅是故事，因此没有什么可以说你不能将缺陷包含在 PBI 中。
记录错误，但在下一个冲刺之前不要对其进行处理。 它们可以单独指出，也可以作为一组指出。 这样做的优点是更加“Scrummy”，但会导致本质上 1 小时的修复延迟三周。
您提出了一个有趣的观点，我们对此也有一些担忧。 然而，当与待办事项中的其他事情相比时，1 小时的修复（无论速度有多快）可能并不值得。 最重要的是，您希望将这些决策推给产品所有者，并让他们自由地优先考虑团队花费精力的所有事情。
Your third answer is the best method. A sprint is simply a commitment by the team to complete a specified amount of work in a defined period of time. If you're accepting additional work in the middle of the sprint, you're deviating from that original commitment by working on things that were not committed to by the team at the beginning of the sprint.
Here's what we do:
Here's the problem with your other solutions:
Have a story that says "90% of bugs fixed in the app" where you then guess how many bugs will emerge in that sprint and how many can be fixed and then point it based on the anticipated workload
Again, see above. You want to avoid empty buckets of work that can be filled during the sprint. This defeats the purpose of a defined commitment by the team. How can the team commit to something they don't know about or haven't estimated?
Plus, this can easily spiral out of control into a product owner that will "design by defect" by filling that bucket with nice-to-have functionality that is really masquerading as defects.
Have a story of size, say, 8 that is ALWAYS accepted at the end of the sprint where you fix as many bugs as you can. This obviously requires a great deal of trust that everybody is actually doing an 8's worth of work
This sounds strange. The team should be accepting work at the beginning of the new sprint planning, not at the end of the previous sprint. Additionally, this will really skew your velocity over the long term. Scrum refers to Product Backlog Items, not just Stories, so there's nothing to say that you can't include defects as PBI's.
Record bugs but do not work on them until the next sprint. They can be pointed individually or as a group. This has the advantage of being more "Scrummy" but causes a three week delay for what are essentially 1 hour fixes.
You make an interesting point and we had some concern about this as well. However, that 1 hour fix (regardless of how quick it is) may not be time well spent when stacked up against the other things in the backlog. The bottom line is you want to push these decisions off to the product owner and give them the freedom to prioritize EVERYTHING the team spends effort on.
我坚信，流程的好坏取决于它改善情况的能力。 这个过程应该适合你，而不是相反。
如果在这种情况下遵循敏捷 Scrum 流程“T”弊大于利，那么是时候在 Scrum 流程之外寻找更好的解决方案了。
我们创建了一个迷你“QA”冲刺，附加到每个冲刺的末尾。 它是在代码完成之后但在发布之前。 在这段短时间内，问题会被仔细审查，并可以根据风险和重要性批准纳入。 在此时间段内修复的问题具有一定程度的自定义审核流程，但大部分工作在定义的 Scrum 流程之外。
I firmly believe that a process is only as good as it's ability to improve a situation. The process should work for you, not the other way around.
If following the Agile Scrum process to the 'T' is doing more harm than good, in this situation, then it is time to find a better solution outside of the Scrum process.
We have created a mini 'QA' sprint that is tacked on to the end of every sprint. It is after code complete but before release. In this short time period issues are carefully scrutinized and can be approved for inclusion based on risk and criticality. Issues fixed in this time period have some extra level of a custom review process, but work largely outside of the defined Scrum process.
您在回顾期间是否确定了这些错误的原因？ 您是否正在使用工程（XP）实践，即进行TDD - 测试驱动开发，自动化功能测试将每天进行全面回归测试以及具有验收标准的配对和故事卡。
当发现缺陷时，是否确定了根本原因，并且是否将自动化单元和功能测试添加到您的测试工具中以捕获此类缺陷（如果它再次发生）？
据我了解，你们的缺陷率太高了。 如果至少每天进行 TDD 和全功能回归测试，那么在 UAT 期间达到零缺陷并不罕见。
在短期内，您可以向团队收取 x 数量的工作单元/工作点来修复缺陷（查看过去的迭代，如果每次迭代需要 x 小时来清理小错误，请从您的成本中减去该时间）团队的能力。）从长远来看，关注根本原因并改进团队的工程实践。
通过衡量缺陷修复的成本，我们发现了以下关系。 如果开发期间的缺陷成本为 1 倍，则功能测试期间的修复成本为 2 倍，UAT 期间的修复成本为 3 倍，生产期间的修复成本为 4 倍。 通过编写带有验收标准的故事卡、结对开发、测试驱动开发和自动化功能测试以及至少每天的全面回归测试，您将显着提高质量并降低成本。 因此，您不需要从团队的能力中减去任何时间，这将提高速度。
Have you identified during your retrospective the cause of these bugs? Are you using engineering (XP) practices i.e., doing TDD - test driven development, autoamted functional tests will daily full regression testing along with pairing and story cards with acceptance criteria.
When a defect is found, is the root caused identified and is an automated unit and functional test added to your test harnesses to catch such a defect should it occur again?
From my understanding, your defect rate is too high. If one does TDD and full functional regression tests at least daily, it is not uncommon to reach zero defects during UAT.
In the short term, you can charge the team x number of units/ points of work to fix the defects (look at your past iteration and if it takes x number of hours per iteration to clean up the small bugs, subtract that time from your team's capacity.) Longer term, focus on the root cause and improve your team's engineering practices.
From measuring the cost of defect fixes, we have seen the following relationship. If a defect cost 1x during development, it cost 2x to fix during functional test, 3x to fix during UAT and 4x to fix when in production. By writing story cards with acceptance criteria, pair developing, test driven development and automated functional test with at least daily full regression testing, you will improve quality and reduce cost significantly. As a result, you will not need to subtract any time from your team's capacity which will improve velocity.
这是 Scrum 项目中对健全工程实践的强烈需求的一个很好的例子。
“[我们]遇到了代码被接受后出现的一堆小错误的麻烦”
这表明您的“完成的定义”不够强大。
“其中包括拼写错误等内容”
这些拼写错误是否出现在用户界面上？ 在代码被接受之后发现它们的人应该在代码被接受之前发现它们。
处理缺陷的方法是 1) 立即修复它们，2) 对系统进行检测，以便下次能更早地发现类似的缺陷，3) 改进流程，从而减少导致缺陷的错误类型发生在未来。 这些都是技术问题。
This is a fine example of the strong need for sound engineering practices in Scrum projects.
"[we're] running into trouble with a bunch of tiny bugs that appear after code has been accepted"
This suggests that your "definition of done" is not strong enough.
"These include things such as spelling errors"
Do these spelling errors appear on the UI? Whomever is spotting them after the code is accepted should be spotting them before the code is accepted.
The thing to do with defects is 1) fix them right now, 2) instrument the system so that similar defects will be caught earlier next time and 3) improve your process so that the kind of error that lead to the defect is less likely to occur in future. These are all technical issues.
我在我的项目中成功实施了以下策略：
缺陷纠正始终优先于功能开发。 我们的目标是始终保持零开放缺陷，重视 100% 工作功能而不是几乎工作功能。
一旦发现缺陷，就可以而且应该立即修复。 仅当缺陷是由非开发人员发现或发现缺陷的开发人员无法立即修复时，才需要提交票据。
需要对代码库进行架构级更改的缺陷会将架构调整部分记录为故事并进行估计和修复。 计划一些即将到来的冲刺。 缺陷状态设置为待故事实现。
Sprint 待办事项不受外部更改的影响，但团队本身可能会在冲刺中引入新内容，以满足始终实现零缺陷的目标。
如果一个缺陷不值得修复（基于一些基本的成本效益分析），那么它就会被忽略，以防止无法修复的开放缺陷污染问题跟踪器。
将缺陷修复优先于故事实施会时不时地影响你的速度，但没关系。 从长远来看，您实现故事的效率将会提高，因为代码库中只有很少的技术债务。
I have had the following policies succeed in my projects:
Defect correction is always prioritized over feature development. The target is to have zero open defects at all times, valuing 100% working features over almost-working features.
Defects can and should be fixed as soon as they are found. A ticket needs only to be filed if the defect is found by some non-developer or the developer finding it cannot fix it instantly.
Defects that require architecture-level changes to the code base have the architecture tweaking part logged as a story and estimated & planned to some upcoming sprint. The defect status is set to be pending on the story implementation.
Sprint backlog is protected from external changes, but the team itself may introduce new stuff in the middle of a sprint that is required to meet the zero defects at all times target.
If a defect is not worth fixing (based on some rudimentary cost-benefit analysis), then it simply ignored to prevent won't-fix open defects from polluting the issue tracker.
Prioritizing defect fixing over story implementation will hit your velocity from time to time, but it's ok. In the long run, your efficiency in implementing stories will increase as the code base has only a little technical debt in it.
如果 Bug 与您正在开发的内容无关，或者假设冲刺期间发生任何其他“不相关”活动，我们通常所做的就是创建一个“偶然”。
这基本上是从您的冲刺“能力”中删除的一定时间，并将根据需要专门用于冲刺目标之外的活动。 其工作方式如下：
团队每天都专注于冲刺目标，但有一个“缓冲”时间（特遣队）来处理外部问题。 在每日站会上，产品负责人可能会提出每日收到的问题，完成 Sprint 任务（因此不会中断）的团队成员最终将解决其中一个问题。
时间是在队伍上预定的，到了就关闭。
时间是
团队有权向产品负责人传达，团队的时间已经结束，如果他希望他们遵守 Sprint 承诺，他将必须决定是否希望他们这样做或继续 ，
它总是被证明是一个公平的交易;-)
我们将它用于以下目的：实时产品的错误和维护（5-15％），为即将到来的冲刺做准备（10％）......
HTH
what we normally do, in case the Bug are unrelated to what you are developing, or let's say any other "unrelated" activity happening during a sprint, is to create a "Contingent".
It is basically a certain amount of time that will be removed from your "capacity" for a sprint, and will be dedicated on demand to do activities outside of the sprint goal. This works the following way:
Daily the team focus on the Sprint Goal, but has a "buffer" of time (the Contingent) to take care of external issues. At the Daily stand-up the PO may present daily incoming issues, and the Team Members that completed a Sprint task (so there is no interruption) will eventually take one of the issues to fix.
The time is that booked on the contingent, that when comes to an end will have to be closed.
The Team has the right to communicate to the Product Owner that the time in the contingent is over, and that if he wants them to keep the Sprint commitment, he will have to decide whether he want them to do so, or continue running after daily issues, giving up some value out of the Sprint.
It always worked out to be a fair deal ;-)
We use it for the following: Bug and Maintenance of the live product (5-15%), preparation of the upcoming sprint (10%)...
HTH
谁负责为您投入生产的代码提供支持？ 如果您的团队确实处理支持请求，那么这些拼写错误和其他外观问题就属于该类别并得到适当处理。 如果没有，那么您可能必须让偶尔的冲刺有点像“修补”冲刺，其中不添加新功能，但修复了许多旧的东西，并将技术债务减少到合理的水平。 或者将一个小错误中的一个错误合并到一个故事中，比如“修复网站上的所有拼写错误”以获得一个想法。
如果您在 Google 上搜索“技术债务” 或使用 Scrum 来查看其他人如何处理这些事情可能还有其他想法。
Who handles the support for the code you push into production? If your team does handle support requests then these typos and other cosmetic problems fall into that category and get handled appropriately. If not, then you may have to have the occasional sprint be kind of like a "patching" sprint where no new functionality is added but many old things are fixed and technical debt is reduced to a reasonable level. Or combine a bug of the little bugs into one story of say "Fixing all typos on the site" for an idea.
If you Google up "technical debt" or "broken windows" with Scrum to see how others handle these things there may be other ideas out there.
如果错误导致您停止实现冲刺目标，您仍然可以决定取消迭代并重新计划。 但这是一个安静的艰难决定。
If the bugs cause you to stop working on the sprint goals you still can decide to cancel the iteration and replan. But this is a quiet hard decision.