I am working as developer in product based software company. In all companies I worked as of now , we say that the quality of this delivered story is good or bad. But I find this is subjective. Is there a standard rule of thumb where we can say for a work of X man hours , Y hours of rework in defect fixing is fine.

If Y value is within the range

  • a to b: Quality is very good
  • c to d: Quality is average
  • e to f: Quality is bad

Is there a standard rule like this ? May be it can not be standardized as it depends on lot of other factors like complexity of work, skill of resource etc., but then what are the factors/metric I should consider to objectively say that quality is good or bad?

Is there any formula that takes into account these factors and tell about the quality. I agree that measurement may not be true but it will act as pointer or work to cement the subjective view ?



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.

  • Thanks Todd. As you asked If you're already doing these sorts of things, why are "defects" making it outside the development cycle to become bugs? My question is even if team is following these practices there is scope defects can be leaked like understanding gap b/w dev and qa/product, infra level issue like service gets down because of resources etc . So there will be few instances . Is n't it ? Aug 11 '19 at 7:34
  • Also for first two points you raised Does the team effectively use source control? Does the team use continuous integration (CI)? Is n;t source control and CI both same thing ? I believe when you say CI helps in detecting bugs, you mean the more continuous integration is , more frequently dev get to know each other code and also automated pipeline is triggered which run UT/IT/FT etc which betters the quality ? Aug 11 '19 at 7:38

There is no standard measure of acceptable quality as each organisation exists in its own domain.

For example, a startup working with a radical new technology may accept a large number of issues as for them speed to market is more important than quality.

A company building medical applications will usually aim for a very high quality standard.

Having said that, in recent years the trend has been towards increasingly regarding rework as unacceptable. This trend is driven by the desire to release frequently and by highly competitive industries where issues can have a severe impact on sales.

The main outcome of this trend has been for organisations to invest in baking quality in rather than in spending time and money on fixing issues. There is a good argument that investing in continuous integration, automated regression tests, etc. saves money in the medium/long-term due to less time being spent on rework.

  • Rate all defects in terms of severity-- critical, high, medium, and low. Once you've organized defects in this manner and have addressed them when possible, it will be easier to determine the quality of your software.

  • Have a predetermined criteria for when a task is done.

  • 1
    You may need to expand your answer. As currently written, I don't see how your answer directly addresses the OP's question of "How much defect rework is expected?"
    – Todd A. Jacobs
    Aug 5 '19 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.