In the process of product delivery, we expect that everyone involved shares a common understanding - from user to stakeholder to analyst to developer to tester and to a user. However, we frequently see communication gaps, because each role uses its own language and vocabulary. Given below, is a real story of something that happened recently in our team.
The team was working on an insurance CRM product. One day, the analyst organized a meeting to elaborate on a policy summary story.
Analyst: "…Let's look into the details of the product summary. First, please look at the total number of products…"
Stakeholder: "…The design looks different from how I understand it. As I understand, it should be the total number of policies. User, what is your view on this?"
User (Sales & Services Staff): "…I think it should show the total number of risks. A policy might insure multiple risks. For example, a home insurance product covers fire, wind, theft …"
Tester: "…I tested the online application and it shows the total number of covers..."
Developer: "…Technically, we store the cover details, but not the risk details. I'm not sure whether we will be able to show total number of risks…"
You might have also experienced a similar scenario before. Different terms are used in conversations, and participants find it hard to follow what is being said and the discussion gets stuck.
Business Terms is a simple tool which can effectively improve communication of requirements.
What do you mean by Business Terms?
It is a universal vocabulary list of domain terms and concepts, with each having a brief description of its meaning.
Where do I start?
It is very simple:
- First, collect the terms and concepts that are being used in your team
- Set up a list with these terms and concepts with a brief description of its meaning. Provide specific examples if it's an abstract concept
- Socialize the list in your team and ensure that everybody knows it and uses it in their daily conversations
How will Business Terms help me in my job?
Let’s look at the story in the beginning. You may notice that four different business terms come up in this conversation: product, policy, risk, and cover. In this scenario, each participant is using the term he or she is more familiar with. This may or may not be the same thing. But people make assumptions based on their own understanding and context:
In the Stakeholder‘s mind: “Product, to me, is another word for policy. We sell policies to customers and each bill is linked to a policy number.”
In the User's mind (Sales and Service Staff): “We have different types of insurance products. Sometimes, we sell multiple items to the customer to cover multiple risks. If you take home insurance as an example, apart from the house itself, we also provide insurance for the properties inside the house, such as furniture, facilities, and other valuables. I am used to seeing a list of risks and the total number of risks in all the relevant insurance product systems.”
In the Tester's mind: “If a customer buys a policy on our website, before payment, he/she would see a product summary page which shows the total number of covers. Risks and covers might be the same thing. I think we should be consistent and also show the total number of covers.”
In the Developer's mind: “What is going on here? Whatever you call it, can anyone simply tell me which data field in our database table should be looked at for the number?”
If we read their minds, we realize that they have different assumptions. Their understanding might have been correct in earlier scenarios, but not in this one. In the meeting, however, they might not consciously recognize that. Most of the time, without proper intervention, the outcome can be very misleading and the communication process is ineffective. This is a typical example of how a communication gap is created when there is a lack of a universal vocabulary. This issue happens almost in every conversation; not just in the story elaboration meeting, but especially when the business domain is complicated and has multiple stakeholders.
To fill this communication gap and establish a foundation of shared context, analysts need to set up and maintain a universal vocabulary for all roles. With Business Terms, the analyst can first clarify the terms (product, policy, risk and cover being used in this discussion), and make sure that everyone has a shared understanding of each term. The conversation will flow more smoothly.
Analyst: "…Before we look into the details of the product summary design, I would like to clarify the terms used here. In this CRM application, policy is equivalent to a product. A risk is an item that the customer want to insure. It can be fire, storm or theft. In our context, we also call it cover. So risk is equivalent to cover. Is that clear to everyone? Any questions?"
Stakeholder: “Sounds good."
User (Sales & Service staff): “Ok, that makes sense.”
Tester: “Cool, risk is the same as cover. It clears my confusion.”
Analyst: “Now let’s look at the detailed design of the product summary...”
Okay, is that all? How else can Business Terms help?
Business Terms can be a powerful clarification tool to share understanding internally and externally. At the start of every conversation, we can first clarify the term or concept used and agree on it, before getting into the particular topic. Without well-prepared Business Terms, we might not know that different terms exist in different teams. Thus, we lose the rhythm in difficult conversations with multiple stakeholders. Using Business Terms will ensure success beforehand in these meetings.
It can be a powerful learning tool in the on-boarding process. When jumping into a new team or initiating a new project, the first challenge for us is to speak their domain language. Building up a commonly-used vocabulary is a very good starting point for a BA. It can effectively speed up the domain-learning process. For others in the team, it can be used as an induction tool to quickly learn the basic concepts.
Business Terms can also be used to facilitate the technical architecture design, also called “Domain-Driven Design." The technical modeling should map to the business domain and concept collations. When they are inconsistent, it will cause unnecessary complexity or involve extra effort during implementation. Analysts can effectively join the technical design conversation by picturing the Concept Model from a business perspective. This is a way to effectively bridge the business and technical worlds.
Business Terms can also be used as an important component of a user guide or a product knowledge base. Even when we try our best to make the wording in an application easy to understand, there are still cases when we have to explain the terms, especially if it's a particularly complicated domain like banking or medical. Sometimes, a business would like to introduce brand new concepts to consumers. In these cases, Business Terms becomes a key component in the online user knowledge-base.
Any tips or tricks?
Business Terms is usually the first thing that I do when I join a team. This, irrespective of whether it is a brand new project or an ongoing one. The power of Business Terms comes from the process of *building* it rather than the artifact itself.
In my experience, I've learnt:
- Set up the initial list with a simple collaborative tool. Either a wiki page or a physical wall, whichever is accessible to everyone in the team
- Collect terms and concepts by capturing the nouns frequently used in business conversations and documents
- Ask business users for the meaning of the terms and concepts
- Use plain words to explain these
- Clarify and agree on the *standardized* term for a particular context and tag your term with that
- When explaining these terms and concepts, use specific scenarios or examples
- It is better to compare yours with other relevant terms and concepts
- When the business and technologists use different terms to refer to the same thing, make sure the business term goes into the list and that everyone starts using this term going forward
- Regularly review the term list to recap with the team
- Keep the list up-to-date
- Categorize (areas) and rank (importance) as the list grows
- Consider using flash cards or the Anki tool to help the whole team master the terms
- Clarify and agree on the terms and concepts to be used at the beginning of every conversation and update the list afterwards
- Make the key term or concept visible - for example, by creating posters to make sure it acts as an Information Radiator.
It's a very simple tool, isn’t it? Give a try!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.