The question is ...
When your team has a meeting or do you discuss some functionality with a fellow developer, do you use the diagrams?
In case of affirmative , then use must be daily, so it is rewarding to keep documentation up to date.
Negative case, diagrams were probably only meant for initial understanding or to meet customer or management expectation, not worth it ; work is more than the benefit harvested.
If the source file of the diagrams is versioned along with the source code, then it is easy for any team member to update the diagram and synchronize the project with SCM.
On the other hand, if the team usually works with printed documents, simply scratch the document in pencil and it will be enough to use in the next sprints (provided, of course, that no one plays basketball with papers and a wastebasket).
UML diagrams need not be a 100% accurate reflection of the code. In many cases, I avoid placing attributes in classes so as not to compromise the internal structure.
But what often happens is to use the UML to represent the system database model. I do not really agree with that. There are more appropriate tools that allow you to do an MER (Entity-Relationship Model) and already synchronize the diagram with the database.