One of Agile Modeling's (AM) practices is Apply Modeling Standards, the modeling version of Extreme Programming (XP)'s Coding Standards. The basic idea is that developers are more effective when they follow a common set of standards and guidelines, even when the guidance isn't perfect. It's like speaking the same language -- models that are depicted with a common notation and follow effective style guidelines are easier to understand and to maintain. These models will improve communication internally within your team and externally to your partners and customers, thereby reducing the chance of costly misunderstandings. Modeling guidelines will also save you time by limiting the stylistic choices you face, letting you focus on developing software.

All diagrams comprise three basic elements: bubbles (data entities on data models or use cases on UML use case diagrams), lines (associations on UML class diagrams or transitions on UML state machine diagrams) and labels (use case names or roles on associations). As a result, a common set of modeling guidelines applies to most diagrams:

1. Avoid crossing lines. Two crossed lines on a diagram can easily be misread. If you can't avoid crossing lines, draw one so that it "hops over" the other to make their difference explicit.

2. Avoid diagonal or curved lines. Straight lines, drawn either vertically or horizontally, are easier to follow visually. Placing bubbles on diagrams as if they're centered on a graph's grid point, a built-in feature of many software-based modeling tools, makes it easier to connect the bubbles with only horizontal and vertical lines.

3. Draw bubbles of consistent size. The larger a bubble appears, the more important it seems to be. Unless you want that effect, strive to make your bubbles of uniform size. Note that with some modeling tools, bubbles resize automatically based on their contents, so this may be beyond your control.

4. Include white space. White space is the empty area between modeling elements on your diagrams. When bubbles crowd each other, it can be hard to distinguish which labels go with which bubbles and lines, decreasing the diagram's readability. Sometimes, when using a modeling tool, you may be motivated to reduce the white space to print a diagram on a single page. Be aware that you reduce the diagram's usability by doing so -- sometimes taping two pieces of paper together is worth the effort, for readability's sake.

5. Organize diagrams left to right, top to bottom. In the West, people read from left to right and top to bottom. If there's a starting point for reading a diagram, such as the initial state of a state machine diagram or the beginning of the flow of logic on a sequence diagram, place it toward the top-left corner of your diagram and continue appropriately from there.

6. Show only what you have to. Diagrams that have too many details are difficult to read because they're too dense. One of AM's practices is to Depict Models Simply, to include only critical information on your diagrams and not include anything extraneous. Remember the KISS rule: Keep it Simple, Stupid.

7. Avoid esoteric notation. A diagram that uses a wide range of arcane symbols, abbreviations and so on, instead of focusing on the 20% "kernel notation" that does 80% of the job, can be difficult to read.

8. Keep your diagrams small. It's often better to have several diagrams showing various degrees of detail than one complex diagram that reveals everything. A good rule of thumb is that a diagram shouldn't have more than 7 +/- 2 bubbles, because there's a limit on the amount of information that we humans can deal with at once.

9. Focus on content over appearance. Don't succumb to the temptation of adding hours to your modeling efforts by rearranging the layout of your bubbles and lines to improve readability. The best approach is to first focus on the diagram's content -- it doesn't have to be perfect while you're working on it. Once you're satisfied with its accuracy, and have decided that you want to keep it, then you can invest appropriate time to make it look good. You'll save time by not dedicating significant effort to improve diagrams that you may eventually discard as the result of AM's Discard Temporary Models practice.

10. Set and follow effective naming conventions. This ensures consistency within your models and hence increases their readability. Better yet, your diagrams should use consistent and recognizable domain terminology. This is particularly true for domain-oriented diagrams that your project stakeholders are likely to be involved with.