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.
It is a universal vocabulary list of domain terms and concepts, with each having a brief description of its meaning.
It is very simple:
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...”
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.
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:
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.