A common question about definition of done is - "When should we do which activity?" A definition of done is usually about:
- Done when the story is done
- Done when the sprint is done
- Done when the release is done
Usually you should strive to be done as soon as possible with the most activities, so do the most stuff at story level except there is a reason not do. Here are several why you might scale your activity from story level to sprint or even release level.
Transaction costs, synergy or no demand
Some activities should be done for all stories and it is cheaper to execute them together, usually activities for non functional requirements fit here. Take for example performance testing or testing with data from live systems. If you do it once a sprint it might be enough. Moreover, there are different opinions about how much e. g. security is required per story, this happens per stakeholder. Sometimes there might be no demand to do the activity per story.
Minimum viable product and experiment
Sometimes you want to experiment functionality. You develop it without making things nice and layout it the way it fits into the GUI design. This approach is fairly okay, because you want feedback, you wanted to test your idea. This is often when you go for a minimum valuable product. You might run a few sprints with making it run and before the release, after you said - "this is it" - you make it nice and fast.
Low performance, too many restrictions or impatient stakeholders or customers
If you spent too much time with developing one story and you cannot get enough features done. Then you might suspend some activities for later. This is also recommendable if you've got impatient stakeholders or customers. Show that it works and then make it nice and fast.