Evolving definition of done - how past iterations of the increment comply
As we progress with a product as a team, we will learn and be able to update the definition of done to be more concise. The definition of done applies to the increment, so each sprint we have the opportunity to change the definition of done and it subsequently applies to the new increment.
However, this would mean that we have to potentially retrofit whatever we built with the old definition of done. Differently put, functionality we built in older increments that complied with the past definition of done, may not anymore. And, that means that a new definition can have far reaching consequences and should not be done lightly.
Hence the question, how do we act as a team when deciding to change the definition of done?
The situation you describe has exposed technical debt. You might be Done and still build up debt in the Product, because the Definition of Done subsequently proves to be inadequate.
My advice is to deal with it in those terms. Account for this newly discovered technical debt in the Product Backlog, and come up with an appropriate policy of paying it off Sprint by Sprint.
Remember that each Sprint Retrospective provides a formal opportunity to challenge and improve the Definition of Done, so quality remains under control and the team is able to keep a lid on technical debt.
a new definition can have far reaching consequences and should not be done lightly.
N.B. it's best to think of it the other way around. Improvement ought to be done courageously.
@Ian gives good advice as he always does. Let me give you my perspective on this.
The Definition of Done should change continuously as your team evolves. As new knowledge is gained it should be applied to everything that is done. Does this mean that work done previously is sub-standard. Not exactly. It was done to the standard you held at that time it was done. Could it have been done "better"? Maybe, based upon what you have learned. But that is not a reason to go back and redo all of the work. It is a reason to celebrate that you have learned, adapted, and improved. The product will evolve over the time it exists as it is improved and needs change.
If there is any work identified that needs to be done to code base in order to make the product better, it should be captured in the Product Backlog. It should be ordered in a way to maximize the value that the Scrum Team produces. I do not suggest that you go back and review the entire codebase for any places that do not adhere to the current Definition of Done. Because as you work on areas of the code base, it will be updated to adhere to the current Definition of Done in order to be included in current increments.
Think of it in terms of an automobile. If new laws are passed any old automobile may need to have some updates. But it does not mean that all old automobiles will have to be updated. New models of automobiles will have features and benefits that the older ones do not. But that doesn't mean the older automobiles are no longer valuable.
Don't make up work for the sake of working. Do work for the sake of providing value.