TL;DR
Refactoring is a natural part of iterative and incremental development methodologies. However, a high ratio of defects in a product indicates one or more fundamental process problems. Such problems represent a cost to the project by consuming budget, schedule, and resources. High defect rates also create a drag on productivity that increases over time.
Identify the Process Problems
There is no standard ratio of work to defects, either in project management nor in software engineering. Defect rates represent a cost to a project, either in time and budget to fix defects or in customer dissatisfaction with the project, so minimizing foreseeable defects is important. Your company or agile team should have a well-defined Definition of Done and a notion of what level of quality is acceptable from both a business and an engineering point of view.
This is really an X/Y problem, though. If your defect rate is high enough to even ask the questions you're asking, there's a process problem that needs to be uncovered. It's time to ask yourself and your team some hard questions, like:
- Does the team effectively use source control?
- Does the team use continuous integration (CI)?
- Does the system have unit tests that must pass before code is checked in?
- Do the tests provide adequate code coverage?
- Is the team following test-first development practices?
- Is the team creating new regression tests each time it finds a bug?
- Does each work increment fully meet the team's Definition of Done?
- Is the Definition of Done being updated when quality problems are identified?
If you're already doing these sorts of things, why are "defects" making it outside the development cycle to become bugs? This is often a process issue where good engineering practices are not being consistently followed, or an indicator that the team has chosen to "work faster" at the risk of a higher rate of defects. This is often a false dichotomy, because when working faster simply generates defects faster you haven't actually gained any real operational efficiencies.
Agile Teams Have a Bias for Predictability
From an agile perspective, the goal isn't to work faster. It's actually to work more effectively at a sustainable pace. Part of setting a sustainable pace is to empirically discover how reliably the team can deliver product increments that meet an agreed-upon level of quality at a predictable cadence. It's up to each team (and each organization) to define what level of quality is acceptable, sustainable, and cost-effective for the business. You then adjust your processes and your cadence to consistently meet that quality standard.
