Few of you’ve mentioned that defects should not change velocity as defects do not brings business value to product.

Does it mean there are no estimation of effort? Complexity? Are you just tracking remainig time vs. estimated duration?

What in case when our sprint is to manage defects found while user acceptance testing?

You know, sometimes you have to adapt your Scrum process to customer’s waterfall process. Typicaly if customer is thinking about new version deployment as internal project – banks, etc.

I agreed that sometimes we need to have separate backlog for bugs. In my organization, we do have different bug tracking systems. The Agile teams need to follow this kind of policy also. Although it is not perfect agile practice, but it works well. Each time, during the planning meeting, PO and team will make the sprink backlog together to get items that should be completed from both user story backlog and bug system. And also some teams will consider to leave 1~2 days in each sprint for bug fixing.

We always encourage team to fix all of the bugs that found in one sprint. But it is acceptable that some defects cannot be fixed because of dependency, legacy issue or something else.

The problem we have is about how to estimate the bug. Now we are trying to estimate the effort (hours). But I am wandering if it is possible to estimate bug with points. Since points is used to indicate the relative size, it seems OK to use it for bug estimation. I think it will be better to setup a unified estimation method for all of sprint backlog items. The team’s velocity can be figured out easier.

So, I prefer to prioritize known bugs over new features. If anything, this would allow us to achieve that “controlled debt.” Because there are always bugs in any system, it is just that we don’t know. So, fixing the knows bugs is always important.

It might be difficult for a legacy system with loads of bugs already on the backlog. For new systems, if bugs are always removed before new features are added, it never becomes an issue even from business perspective, because it should be 10-20% of your sprint backlog. Even that would be high and would recommend to review the engineering practices. If you start falling behind on fixing bugs, then it becomes difficult to catchup and maintain a controlled level of debt.

Thank you very much for helping clarify that point and doing so better than I did.

Secondly, I wanted to point out my views regarding the handling of bugs. I consider the sprinting team to be like a big old machine, with input, and output. The output is a shippable product, and the input is little pieces of paper with things written on them.

The product owner’s job is to run around between users and stakeholders, gathering information to be written on the bits of paper, then to write these papers, order them, and then to feed them, in order, into the machine.

The machine should output the resulting work in the same order as it was input by the product owner.

I guess that what I’m saying is, the only person who needs to use terms such as ‘bug’ and ‘feature’ – the only person who needs to think about these things, is the product owner.

Neither the stakeholder, nor the developer, nor the tester, nor Mrs. Enduser care at all about what you call the work. Similarly, they don’t care about you and your backlists. So don’t ask them to help you decide whether or not to use a single or multiple backlists, or what to call the work your team does.

When we remember to call this a sprint *review*, I think it becomes more clear that the team does not need to demonstrate every bug fix. I’d far prefer to hear about the bugfixes that were taken care of. Perhaps, “And we fixed 38 defects. Here’s a pie chart showing how they split by severity. Here’s a list of customers who were affected by severity 1 bugs that are now fixed. Any questions? Any comments on which bugs or which types of bugs we should fix next. I know our PO is debating whether to fix all priority 2 bugs anywhere in the system or to fix all bugs in the account maintenance area. Any opinions on that?”

Keep the purpose of getting useful feedback or guidance in mind and the meeting will run more smoothly, quickly and with less pain for all attending.

To set the stage, my org is in the early phase of adopting scrum. We have about 300 people and 20-30 million lines of code. We sell, develop and maintain an enterprise level suite of heavily integrated applications to external customers (meaning we are not IT). These very technical products have suffered for many years (as much at 20 + years) of inconsistent development and QA practices and as a result, are very buggy. So we are dealing with sprints, that in many cases are (almost)all defects. Granted the defects may be poorly classified as such and could be more of a feature change. We don’t specifically have an issue with prioritization of stories versus defects, our PO org is managing that part fine. We treat these pre-existing defects just like stories, they are in the backlog, they have story points, and when committed to a sprint, get a task breakdown.

Here is the issue – when it comes to a demo meeting at the end of the sprint, the teams seem to feel that demoing bug fixes is too time consuming and wasted effort. They might have fixed 30-40 defects in a 2 week sprint, and setting up a unique base state environment to demo each one (our software runs on several OS’s) takes more than the 2 hour demo time-box. The PO, stakeholders etc start to fall asleep and don’t engage in the meeting. The usual comment from the PO is that, if the team fixed a crash, what value does it have to show the was-is in the demo meeting? The PO would rather take QA’s word for it and move on. So unless that sprint team was “lucky enough” to also have a feature story in the same sprint, they now try to cancel the demo, stating there was nothing of interest to demo. I think we should stick to our guns and demo everything. If the defect had no business value, then the PO would not have prioritized it as they did. Any suggestions?

Tracking bugs is like keeping a diary of bad memories and have them thrown at you every morning when you wake up. It’s really demotivating for the team.

If you are in a situation where bugs needs to be tracked because there is no time to fix them right away, you’re in a fight that you’re bound to loose. By doing that exact action you’ve stated “I’ve given up”.

The zero bugs goal is possible. The software industry should start taking it seriously and our customers should stop accepting software with bugs.