Project Starts: Ubiquitous Language

When starting a new project as its manager or a member, one of the most important steps you can take is to establish ubiquitous language. Establishing ubiquitous language involves getting everyone to speak the same language, use the same jargon, and have the same definitions in their head of what that jargon means. This is as simple as asking, “What do you mean when you say that?” Is it possible that you will look silly? Absolutely, but I would rather look silly than remain ignorant of the language being used and possibly lose control of a project when everyone’s jargon diverges.

When you have yet to establish ubiquitous language, you almost always run into a fun term in linguistics called lexical ambiguity.

An ambiguous joke

“I have a really nice step ladder. Sadly, I never knew my real ladder.”

Lexical ambiguity is when you have an identical or similar word that means slightly different things to different people. This happens because that term has not been explicitly defined.

A common lexical ambiguity in product and software is the term User Story. Most people’s definitions are pretty close. However, you can run into annoying communication issues when you don’t line up definitions with the rest of your team.

Some User Story Definitions

• It could be the informal, natural framework for describing your feature or a requirement from a given user’s perspective. As a < type of user >, I want < some goal > so that < some thing happens >.
• Some people consider a user story to be the ticket itself in relation to Jira, shortcut, or some other ticket tracking software. Shortcut even uses the phrase ‘Create Story’ on the button to create a new work ticket.
• For some people, user story and requirement are synonymous.

None of these definitions are wrong. None of them are objectively correct either, so the goal of ubiquitous language is to have shared definitions across the board.

For a more recent example, we had a kickoff meeting with a client where they kept referring to Group 1 and Group 2. They were referring to customers who were in a certain part of the process to getting onboarded. As the meeting continued I noticed that people kept using Group 1 and Group 2 for different points in time within the onboarding process, so I simply asked, “Who is Group 1? What does it mean?” Understandably, the team was silent.

The next step was to say, “Okay let’s define group 1, group 2, any other groups, and then document those groups for when other people don’t know what they mean.

Whether you almost know what someone is saying or you know that other might not know, don’t hesitate to ask, “What do you mean when you say that?”

When you establish ubiquitous language or a shared glossary, you chop out many of the communication problems that can naturally crop up with your new team.