Does your team have a definition of done? In the dictionary, the term done means:
“Having been carried out, accomplished, or finished”
Many teams struggle to know when they are done, whether it is from the user story clarity itself or the team’s engineering paradigms paired with the diligence they have established in DONEness.
Have you ever seen anyone say “That’s Done Done”, or even “That’s done, done, and done”? We should have one singular version of what DONE is and the entire team (all roles) stand behind that version as a filter for things they choose to demonstrate in their sprint review sessions. If the user story is not done, then don’t call it done, don’t split it up, just move it to the backlog for re-prioritization.
Having a definition of done allows you to start your strength training exercises in Agile Engineering. When you first start a work-out program, you have a fairly light regimen that allows you to lift weights, do cardio, and stretch without getting hurt. As you strengthen yourself, you start changing your regimen to have more discipline and rigor. You might add more days to the work-out, increase the weights, or even do complex aerobics.
The point is, if you don’t continue to escalate your work-out, you won’t get stronger. You have to exercise those muscles. At some point, they will reach their comfort zone and be able to perform your current work-out with minimal exertion. The point of increasing your work-out regimen is to get stronger and stronger.
The same holds for your definition of done. You have to start out where you are, but have the idea of where you want to go. Your definition of done should change overtime as you strengthen your Agile Engineering practices. Work those development muscles and become stronger and more Agile the more you add to your rigorous definition of done. Your customers, the business, and your team will thank you for it, I promise.
If your definition of done is the same now as it was 1-2 years ago, you aren’t Agile and you certainly aren’t improving. Measure it like velocity, the trend over time should show an upward slope, always increasing your team’s strength in doneness.
DFW Scrum User Group 
I don’t agree with one statement. Your definition of done should NOT change over time. What WILL change is the increase of output of user stories over time. The team will be able to accomplish more the longer they are together. But DONE is done and the definition has been determined already. If you don’t have a completely tested and an increment of potentially shippable product at sprint end then you are NOT done period. The Scrum community should not be putting this up for debate
Hi Stephen, thanks for the comment. I actually agree that a potentially shippable product increment has to be complete in the context of the sprint. My point is that over time, the team will solidify better engineering practices along their Agile journey. Your first rendition of Definition of Done might not contain EVERYTHING you wish you accomplish over-time (of course at minimum it is tested and integrated code). Let’s say a team wants to do automated testing or automated build/deploy. They can continue shipping product increments, but strive to change their definition of done to include that automated unit tests / regression tests have been written.
I don’t think it is very pragmatic to tell a team that if they can’t do all of these things, right now, when they install Scrum, then they will never get anything “Done”. Our goal is to increase our engineering practices over time and we have to start somewhere. I don’t tell my friends that I don’t want to take Karate until I am a Black Belt right? Same scenario here, we should encourage people to adopt Scrum where they are and build on it over time. It is a given that if you adopt Scrum, Done means tested and integrated code, but how they get there should evolve overtime.