Hah. Google it. It's a pretty common complaint.


Well, that depends. If the bug is in a new feature, then you're not just doing Agile wrong, you're doing software development wrong. You're intentionally ignoring errors. A feature isn't "done" if it doesn't work. In terms of Agile, no product owner should accept a feature as "done" if there are known bugs (unless, perhaps, it's a corner case that's so exceedingly tricky to resolve that they're okay with pushing it into a different sprint).

If the bug is in an old feature that the new feature depends on, then you should be fixing that bug, as part of the work to implement the new feature. Otherwise, your new feature can't be finished correctly.

If the bug is in an old feature that a new feature doesn't depend on, then it's up to the product owner to prioritize fixing the bug. In that case, just pushing the bug onto the backlog is the right thing to do.


Is there business value in doing all that? If no, then the product owner will never prioritize it high enough to get done. You might need to make the case that you've incurred a lot of technical debt, and suggest spending a single sprint clearing that up. Or, if there's too much to do in a single sprint, suggest dedicating every n-th sprint to working to clear that technical debt.

One way for a team to push back on implementing new features is to decrease their capacity in the sprint planning session. Since that capacity determines how much work you can take on in a sprint, you can use that extra time to work on fixing some of those bugs. Remember, a team's capacity is up to the team to decide, not the product owner. If the team says "we don't have the capacity to work on that," then there's nothing the product owner can do, other than asking "how can we reduce the number of hours you're spending on non-functional tasks?"


Static code analysis isn't an "agile" thing. You shouldn't depend on it, and don't have to use it, the way you do unit tests. However, it is an invaluable informational tool. It can, for example, give you the metrics to take to the product owner, and say "look at these numbers... last year, we were here, this year, we're here. Bug counts have increased in these areas correspondingly. We should spend some time refactoring, blah, blah, blah. The upside of letting us do that this sprint, is that implementing feature X would take less time, so we could also do feature Y, and, since it would eliminate an area of buggy code, we'd spend less time on patches after it's release, and could up our capacity to the point where we may be able to get feature Z in the bag, too."