Although you have been communicating with other people since before you learned how to talk, finding the right tone and content of a requirements elicitation conversation can still be challenging.

A Business Analyst (BA), Product Owner, or anyone who needs to discover and write User Stories has one foot in the specified business area they are supporting and the other foot in IT. Even worse, often they must keep the peace when IT and business users don’t get along.

In a modern software development environment, you must be a good communicator. Watch this video to learn about how to best promote and facilitate conversations that take place around User Stories.

The Most Important Soft Skill for a Business Analyst Is Communication

Building Rapport

At the beginning of any requirements elicitation meeting, the most important business analysis soft skill is to gain the trust of the other participants. Building rapport is the easiest way to achieve this. Building rapport is about small talk. It means chatting about things that are not important while avoiding topics that could be controversial in any way, shape, or form. In today’s day and age, I would highly recommend against any political conversations unless you know the individual very well; otherwise, you might just set off a firestorm that you will never be able to control.

Staying on Topic

Staying on topic can be challenging because as human beings, we quite often get sidetracked. It is easy to drift into a topic that is fascinating but that is related to your goal. Fortunately, we can easily avoid distractions if we have a defined objective for the meeting or the conversation in writing. Put this meeting goal into the email when you invite participants. Hang it on the wall during the conversation or requirements workshop so that it is visible during the entire meeting. Any time anyone (including yourself) starts to get off on one of those side topics that are so interesting, you can always bring the discussion back to the topic at hand by pointing to the objective.

Non-verbal Communication and Body Language

Another critical part of effective communication is non-verbal communication. It is not just about paying attention to what the other person says or does, it is just as much about paying attention to their body language. Facial expressions, gestures, posture, and tone of voice are powerful communication tools. Be careful though, nonverbal communication is a two-way street meaning you are sending signals to the other participants of the user story conversation or workshop while they are sending signals to you. Often the key to success in stakeholder conversations lies in your ability to understand the meaning of non-verbal clues in the context of the setting.

Minimizing Misunderstandings

The goal of any requirements elicitation conversation is to get a common understanding of what the User Story, the Feature, the Epic, the Acceptance Criteria, or the business requirement you are discussing is all about.

Listening Techniques

Being able to listen is a primary component of your Business Analyst skills set. So how can you hone this skill? There are three distinct techniques that Business Analysts should practice: active listening, informational listening, and Highway 350. Each technique will help on its own. Taken together, they give you the uncanny ability to hear not just what the other person is saying, but more importantly, what they are not.

Dealing with Difficult People

There are some people with whom I have instant rapport and there are others with whom I just cannot connect. Recognizing the difference, recognizing the fact that there are people that I would consider “difficult” is a first step. Learning business analysis techniques or soft skills on how to deal with difficult people is a key success factor for effective communication. It will allow you to develop a mutual understanding about your User Stories or stakeholder requirements and can dictate the success of your requirements meeting.

Open and Close-ended Questions

Many business analysis trainers recommend asking open-ended questions to get to User Stories, Epics, Features, and business requirements. In my experience, good interviewers or “requirement elicitors” use open-ended and close-ended questions in requirements gathering conversations or user story conversations. You just need to know when to use which form. If you want to get them started talking and you want to have a lot of information you ask an open-ended question. In trying to make sure that you understood what someone said, close-ended questions come in very handy. Know the difference and know when to use which.

Stay True to Yourself

A final word of advice: “to thine own self be true”! Basically, just be yourself. You are the one that knows what you need. You are the one that must be in control. You have to feel comfortable. One of the best ways to feel comfortable is to be yourself. The only way you can have a successful outcome is to be yourself as much as possible.