Within a development iteration or sprint, ensuring a story meets its acceptance criteria and passes its test case should be part of the story estimate and the Definition of Done.
If a number of defects are identified after the iteration where the story was completed, e.g. identified during Regression Testing of the entire product in a subsequent iteration, stakeholders are likely to require some indication of how long it will take to resolve these defects, particularly showstopper and critical defects.
Teams not developing in iterations and following a lean pull-system, such as Kanban, will face the same challenge when defects are identified after their Definition of Done, which is usually a release to production.
Regardless of the delivery approach, as most of the time spent resolving a defect is in the investigation, it is often unknown how long it will take to resolve a defect until an initial investigation has been completed.
One method we use is to get the team to agree to timebox the initial investigation of each defect. This could be 30 mins per defect.
These initial investigations may determine the complexity of each defect or even provide the solution itself. Either way, 20 defects multiplied by 30 mins gives an early indication of the work ahead.
Once the team has some understanding of the complexity of each defect, these defects can be estimated alongside other backlog items using relative complexity, for example story points in a Fibonacci sequence or t-shirt sizes, or ideal development days.