Show all posts
9 years ago

Agile Bug Management Anti-Patterns

Agile development books often skip bug management practice. However, there are several dangerous misunderstandings (anti-patterns) that are quite common. It is better to recognize the problem early and fight to win. Here are three common bug management anti-patterns in a development process.

Bug fixing phase inside iteration

Symptom: You have several days at the end of  iteration fully dedicated to  bug fixing.

If you have a bug fixing phase inside an iteration, you have mini-waterfall in each iteration, which is not a very good idea (in agile we blame waterfall for good reason, don’t we?). Story should be tested as soon as it is completed.

Bug fixing iteration

Symptom: You run several iterations with almost no or little bug fixing and then one (or even two!) iterations fully dedicated to bug fixing.

Bug fixing iterations kill your iterative development. It is even worse than mini-waterfall. Such iterations increase your work in progress dramatically. You have nothing done during several iterations before bug fixing iteration. You have nothing to ship. Moreover, bug fixing iterations reduce motivation, people don't like to fix bugs for 2 weeks or for the whole month.

No “Zero open bugs” rule in user story’s Definition of Done

Symptom: You have open bugs in a completed iteration.

You may have decided that some bugs discovered during story development are unimportant and can be postponed to  future releases/iterations. This is a very dangerous practice that leads to bugs accumulation. Moreover, it may be a reason for Bug fixing iteration (see above). The best strategy is to have “Zero open bugs” rule in Definition of Done for user story.

  • Nicolas

    Symptom: You have open bugs in a completed iteration.

    What do you suggest you do in this situation? Prolong the iteration?

  • Michael Dubakov

    If you have iterations, it is required to not include user story into the iteration and move it to the next iteration. It should not be released with open bugs.

    If you do not have iterations, just fix all the bugs and mark it as done and ready for release.

  • Jeremy

    Heh, this must be nice at places where you have full control of everything. However, most of the rest of us aren’t so lucky, so there’s no way this could possibly work for most teams.

    For one thing, most teams already have a backlog of hundreds, if not thousands of bugs; the fantasy of “just don’t create new bugs” fails to address that. It also fails to address bugs you miss; even if you commit to “zero bugs”, what do you do when a bug is discovered two weeks after your “bug-free” release?

    And on top of that, how do you define “bug”? For instance, what if your customer can’t find a feature in your app/site: Do you devote programming time to adding more links to that feature? Do you write a tutorial and add it to your “Help” page? Do you assume the customer is an idiot and change nothing? And then regardless of what you do, what do you do when another customer has the same problem in a month?

    Such bugs are very different from the clear and obvious “your app isn’t working the way you intended it to” bugs, and often times fixing them makes little or no business sense at all. At the same time, there’s no magic way to separate the bugs that make business sense to fix and bugs that don’t. What most teams then do is prioritize their backlog of bugs, and work through them on their “bug fixing” time, whenever that may be. Your anti-patterns demonize both backlogs and bug-fixing-time, but don’t supply any explanation of what to replace them with.

    Any sort of bug strategy would need to address all of the above and more; otherwise it’s not a strategy at all, just some guy saying “Hey, I fix everything I consider to be a bug, aren’t I great?” And if there’s no strategy behind them, then anti-patterns are just one person’s pet peeves; for an anti-pattern to be meaningful, there has to be a (presumably productive/useful) pattern that it conflicts with, and I see no such pattern here.

  • John PV

    “Zero open bugs” would also be difficult to implement in organizations where the QA cycle by a separate team occurs after the full iteration. Bug fixing would always occur at the end of an interation.

  • Michael Dubakov


    Hmm, in general the goal of this post was to show what problems exist.
    It does not provide any solution, but your comments focuses on solutions more.
    I will make several posts that address that. Anyway, some comments.

    >>It also fails to address bugs you miss; even if you commit to “zero bugs”, what do you do when a bug is discovered two weeks after your “bug-free” release?

    There is no such a thing as “zero-bugs” release. In 99% of cases you WILL have bugs in production.

    >>At the same time, there&#39s no magic way to separate the bugs that make business sense to fix and bugs that don&#39t.

    Yes, there is. Product Owner should do this job. There are several strategies to deal with bugs found in productions.
    Most common way is to ask Product Owner.

    >>Such bugs are very different from the clear and obvious “your app isn&#39t working the way you intended it to” bugs

    You&#39ve provided correct bug definition here. Otherwise it is an enhancement (user story or feature). We all know how to deal with user stories.

  • Michael Dubakov


    Yes. Absolutely. Such organizations have this anti-pattern and serious problems with development process as I may suspect.

  • Anonymous

    Agile is crap and developers are useless.

  • anonymous coward

    @ anonymous

    We shipped our product with over 1,000 regressions as we were doing big bang integration at the end of a Waterfall iteration. We have since moved to a product called Accurev and bug counts themselves are down dramatically. Agile and continuous integration with good unit testing is also a big plus. I can’t imagine going back to the old way.


  • Nilanjan Raychaudhuri

    Not having testers inside the iteration is a smell.

  • Michael Dubakov


    Absolutely. Testing should start right after User story completion.

  • dpolist

    Or, rather, User story should only be considered complete after succesfully tested 😉

  • Alpesh

    Clarification: Why not “zero open showstoppers” instead of “zero open bugs”? It seems very limiting and out of touch with business reality to say ANY bug is more important than the next feature. Are you saying to decide immediately whether to fix or defer a bug? In practice, there are those borderline bugs that you really would fix if time allows, but really would ship with if you had to. Adding those to the backlog is reasonable, no?

  • Eleonore

    What if the bugs are enhancements? Do you recommend that we convert them into user stories and send them to the backlog and then prioritize them?

    For example: The feature is a linechart and it works. No defects in code. But, the time format only shows days, months and years when interval is monthly. QA analyst suggests that it would be BEST to show hours and minutes as well, in all cases. He reports a bug as an enhancement, but since we have zero bug policy in our DoD, this gets rejected if we don’t have time to do UX research on what is actually best…. we are at the end of the sprint. What should we do?

    My solution is to convert the bug in a user story because it is an enhancement that brings value to the user, but it’s not a showstopper for the line chart feature. It’s still shippable….