First: asking whether a number of bugs is appropriate is like saying that it takes "6 months to grieve a relationship". This is not grounded on any baseline. Therefore, its very hard to determine what an acceptable/inacceptable number of bugs really is.
From the looks of it though, you are creating too many bugs. This assessment is based on the fact that the sheer amount of bugs you are faced with impedes your progress. If your velocity is near null, then there is a proble.
There are many reasons why this could happen:
- Poor code quality
One of the problems in many teams is that they "develop".
Developing new features is fun, but it inevitably changes the system you're working in. If you spend no time refactoring a bit, you'll end up debugging a lot.
If your team refactors as it moves, at a steady pace, old structures will remain relevant, and bugs will be easier to spot.
Refactoring also allows you to optimize your code and eliminate redundancies. If you follow OOP principles, you'll reduce the amount of lines of code, and thus, the amount of lines of code developers will need to read through to find what went wrong.
Another common problem is the lack of testing methodologies. Without delving into TTD (though I would advise it if your team is familiar with that approach), its important to test implementation under different circumpstances. It's possible that a new feature / refactor "works" under your current test conditions, but it doesn't mean it keeps status quo with all potential situations.
My personal way to assess this is to create automated test cases with "random" values. This allows me to easily run a number of cases and assess that the system works under different circumpstances. This gives me faith in the code-base, which is important before committing important changes.
- Poor work ethic
Your team, by now, should have a culture of what it means to put something to "done". Most likely, they consider it's done when they've developed it.
It shouldn't be just that though.
The DOD (definition of done) should encompass any technical debt created by the new feature.
In other words, a new feature is done only when it works fully, and hasn't caused any instabilities elsewhere.
Thus, a bunch of the "bugs" youy are stuck with are probably the result of technical debt: a new feature that broke something else.
If you empower your developers with the responsibility of this DOD, it will be easier to implement a reward mechanism.
Following your principle, I would say:
1for1: if you get 1 feature to Done (including all technical debt bugs resolved), you get to have a drink.
This allows your developers to have a hollistic vision of development. Instead of "preying on the small bugs", they'll carefully choose one feature, and own it entirely.
Also make sure to use the "boyscout rule". If a developer creates a new feature that leverages another part of the code that is considered risky, he must leave the place "cleaner than it was" (thus making a few optimizations to the original code of the faulty class or bit of code).
Lastly, to insure your most important features get done, assign an arbitrary value (0-100) to each feature, where 100 is the most important one.
When "drinks" come, insure everyone has fully completed their one feature, then, look at its value.
If it's 100, YOU get to pay their drink. If it's 50, pay half of their drink, etc.
If people want "free drinks", they're likely to start on 100-rated items (heck you could even go with 200-rated items if you want to pay them 2 drinks!).
This gives them incentive (drinks) to acquire ownership and responsibility (DOD).
Good luck!