'minor' bugs at the end of a Sprint
Is it acceptable within SCRUM to have ‘minor’ known bugs for any reason at the end of a Sprint and the Definition of Done still be met?
For example can the Scrum Team’s definition of “Done” state that minor defects can be reviewed and placed on the Product Backlog to be addressed in a future Sprint?
Yes, it can.
As long as the Product Owner prioritizes them and states they are acceptable for productive use, you can proceed like this. If this becomes a major problem, you may want to inspect the root cause of these bugs and improve your process.
Suppose a Development Team discover that system performance deteriorates significantly with more than 50 concurrent users, and grinds to a halt with 100. They are unable to rectify the matter before the end of the Sprint, and the PO is informed accordingly.
He or she might choose to accept this defective increment anyhow, with a view to releasing it to a group of 20 early adopters. The new features in the increment may thus be evaluated without adverse incident, and the ROI of the product can be potentially improved. Clearly if the PO refused to accept the increment altogether, then such opportunity would be lost.
This means that it is indeed "acceptable" to have bugs at the end of the Sprint - even serious ones - because the PO might still value the increment. The PO is ultimately responsible for ROI and the decision to accept a delivery, and whether or not to release it in some form, should be made on that basis.
What would *not* be acceptable in Scrum would be a failure to inspect and adapt the team process, so that similar defects can be pre-empted in future, and the incurral of technical debt avoided. In the above example this could involve modifying the Definition of Done so that appropriate load testing is performed.
That is what I assumed but wanted to be sure.
Sincerely, Thank you for the feedback!