As a communication tool I've sold work with a really busy, boxy class diagram where the focus is on the connections and not a complete representation of all the

As a communication tool I've sold work with a really busy, boxy class diagram where the focus is on the connections and not a complete representation of all the properties. Being able to stand in front of a big screen and point to and talk about connections and cardinalities magically draws questions and comments out from the business stakeholders. That feedback helps me get the model to a place where it generally matches what the business wants. Keeping that diagram alive and updated as we implement the system has served as a super valuable tool for communication with other teams that need to touch the model. Everyone continuously hashes out and agrees on common terms, ownership, etc. The worst defects come from requirements or design defects. I'm not advocating for giant up-front designs with hundred+ page software design spec docs. But, paraphrasing Uncle Bob, "'no up-front design' doesn't mean no design." There has to be some design of some sort and some documentation of the system being developed. I think the time to stop diagramming/designing is when adding more detail won't communicate anything more about the model or business process in casual conversations about the system. That's a very subjective line to draw, but it helps me to think that way.