Ubiquitous Language is a practice of building up a canonical, rigorous and unambigous language between everyone involved in the software development process. Usually a common shared language between the development team and the users, but not limited to that. The product owner and other stakeholders should adopt it as well.

It comes from the Domain Driven Design world. It was first introduced by Eric Evans in his own book "Domain-Driven Design: Tackling Complexity in the Heart of Software" in 2003.

When the business domain is very complex, it is common to find situations where team members or users have a different understanding of the same concept.

The lack of a shared understanding has a deep impact in the velocity and quality of what the development team delivers and can also lead to frustration in the users because what they have in mind is not what is finally implemented.

Some examples of complex domain concepts:

• "Time travelling" in AI model development domain
• "Merge vs Join" in the data engineering domain.

Developing Ubiquitous Language has many benefits. It helps to

• better understand the business domain and the users.
• remove ambiguity from the development process.
• establish a common language between everyone involved in the development process, especially between developers and users.

The output of the Ubiquitous Language practice should be a glossary of terms & concepts and their definitions. Ideally this glossary should be available for reading & reviewing by everyone involved in the development process, not only the developers. A git repository where changes can be tracked and suggested could be an ideal place for it.

Don't be afraid of drawing rather than writting. There might be concepts that are better explained in a diagram than in plain words.

In order to start developing an Ubiquitous Language:

1. Start collecting domain concepts from other practices. Event Storming is the perfect candidate practice to start capturing concepts that are relevant for the business domain but not equally understood by all the participants of the Event Storming. Don't limit yourself to the Event Storming, other discovery practices like Impact Mapping or Empathy Mapping are good candidates as well.
2. Develop definitions for those concepts.
3. Validate those with the development team, the users, the PO, etc. Ask for feedback.
4. Iterate ;)