Myth about Definition of Done being baselined before project starts

Definition of Done is directly compared with Quality Criteria which was used in waterfall. Because of this teams tend to baseline the definition of done before starting the project
By baselining the definition of done, product teams and delivery teams don’t get to iterate the quality criteria as they go-along
Lot of time then gets wasted in trying to get the product too precise and the releases get delayed

Definition of done should be emergent. That means the definition of done should get more and more stringent as the product maturity increases.
There is no point in trying to make the Definition of done too stringent upfront. Instead one can always start with “the bare minimum” definition of done.
As the product matures, it is often necessary to make the definition of done stronger. It makes sense then to make the definition of done stronger as you go along.
However, one must understand that if the Definition of Done becomes stronger, then there may be undone work associated with the product and the product must be brought to the current definition of done. That means, all the undone work must be identified and put back into the product backlog.
For example : One could start with a definition of done as
- Acceptance criteria for functionality is met
- User Documentation is completed
- Integration testing is done
- Regression testing is done
As the product matures, lets say, after 6-8 months, the volumes increase drastically and product becomes slow. Then it may be required to add performance testing into definition of done. So the new Definition of done could become.
- Acceptance criteria for functionality is met
- User Documentation is completed
- Integration testing is done
- Regression testing is done
- Performance testing is done

So now one must understand that because Performance Testing is added to the definition of done, it is now required to add the “undone work” associated to the last 6-8 months of product that was already completed. And that means, we may have to dedicate some time in the upcoming sprints to get the product to the current definition of done.
By doing this, it avoids a lot of initial wait time before we get the product into the market. In the above example if we would have added performance testing initially, a lot of time could have been wasted trying to do performance testing when it was not required. We could have missed the window of opportunity. Our competitors would have released the product earlier than us.
It is not just the scope which is iterative and incremental in Scrum. Definition of done (Quality Criteria) is also iterative and incremental.