In your statistics report on the number of defects you should differentiate between different kinds of defects:
- Defects on stories that have been delivered in previous sprints. Unless the teams consistently work on separate parts of the application (i.e. a front-end and a back-end team), there is not really a point in separating these defects out per team.
- Defects on stories in the current sprint that were found and fully fixed.
- Defects on stories in the current sprint that are open at the end of the sprint. It doesn't matter here if the issues has been closed and reopened during the sprint. Only the status at the moment of the demo is relevant.
The first two categories can then be subdivided further by issue resolution (fixed, duplicate, rejected).
This way, there is a clear distinction between the number of issues related to current work and the number of issues related to past work.
When dealing with defect statistics, there are two things that you should be careful with:
- Multiple defects in one report.
- Morphing defects: After fixing the original defect, the same ticket gets reused to report a different issue.
Both are a nuisance when solving/verifying issues, but they are an outright nightmare for the statistics. In both cases, it should really be reported as multiple, distinct, issues.
Regarding whether stories are done if there are defects open on them: Generally, a story should not be considered to be done if it has open defects associated with it, but you should also allow the Product Owner to accept a story anyway if, in the opinion of the PO, the defects are not important enough to block the story on.
There can be business reasons to accept minor issues with a product, but that call can only be made by the representative of the customer (i.e. the Product Owner).