One hidden aspect of the Business analyst role

Business analysis and Business Analyst definitions

I would like to start this conversation with the definitions as we all need to understand what we are talking about.

• BABOK defines Business Analysis as the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change and to design and describe solutions that can deliver value.
• BABOK defines the Business Analyst as a role that is responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders. The business analyst is responsible for eliciting the actual needs of stakeholders — which frequently involves investigating and clarifying their expressed desires — in order to determine underlying issues and causes.

Let’s pay attention to the words in bold: define, articulate, the rationale for change, design solutions, discover, synthesize, analyze, variety of sources, actual needs, underlying issues, and causes.

I am eager to emphasize there are no such words as “convey”, “transfer” or any similar. It means, that just listening to the client and conveying it to the team without all those actions, even in the form of a User story and acceptance criteria, cannot be considered to be a Business analysis and Business Analyst role.

Unfortunately, in practice, I face cases when a BA plays the role of the post service: just handing out information without discovering different sources, analysis, classification, synthesizing, and so on. Let’s step up our game, let’s level up our standards and what we find to be a Business analysis in real projects.

I would like to supplement the given definition and try to show in more detail why we need to have something in the middle of receiving information and turning it into the requirements. I want to give one more reason, why it’s significant to additionally operate the information received.

Human abilities to remember and learn.

My point of view relies on the simple fact that stakeholders and a BA and a team are people. The people with their physical and psychological features. It’s like people have some attributes, functions, and procedures 🤓. I mean that people have the ability to listen to, perceive, operate, interpret, and remember information. However, these abilities have specific functions not to overload a human brain and do as fewer actions as it is possible. Edgar Dale’s “Cone of Experience” describes this really well, it says that people remember less when they read, listen to, and watch and more when they add some actions like writing, speaking, or experiencing. What is more, there is one more thing as cognitive distortion, that leads to misrepresenting. You can see all these factors that impact how much a BA really may perceive info in the picture below.

Now I would like to ask you, does it contribute to the goal of BAs to enable change and satisfy standards’ needs? Does it enough to reach this goal? Does the fact that we absorb only about 20% of gained information if we don’t do any additional actions with it, makes us closer to the change-maker who BAs are according to the definition? Think about it.

Meantime, let’s go ahead and look at what Edgar sees can help to remember (learn in original) more.

You can see, that additional actions that are applied to the information increase your awareness and boost your understanding. These activities bring you to the next level of possession of information.

Does it ring a bell? Yes! This is what we have in bold in Business Analysis and BA role definitions. Bingo!

In other words, BAs should analyze, synthesize, model, and so on to extend the amount of information and try to reach the level of information to the extent the stakeholders have. Oh, no, even more: to see what stakeholders missed and what is a lack in the whole picture.

Great! Now let’s look at how can we apply this specifically to the BA’s work. We have information that goes through the chain from Stakeholders to a BA, from BA to Developers and QAs. Can you imagine how the amount of information decreases at each element of this chain? A stakeholder conveys a piece of information to a BA, if a BA just listens to or reads, they have at their best 30% of it. Then the BA writes this info creating the US, recalls something more, or has a few questions. Definitely, they get the answers and finish the US. Let’s add 10%. As a result, the BA conveys 40% of the info to the team. The team reads the US, listens to the explanation on the refinement session and also absorb in the best case 30%. So, the team owns 12% of the information given by the stakeholders. Interesting, isn't it?

Here is what it may look like. I also considered that stakeholder tells not everything they know, but what is in active memory.

Applying Edgar’s options to improve results and actions from definitions at the beginning of the article, we have such a picture:

In conclusion, we have presented a new perspective on the question of why we need to operate information before conveying it. The BA role has a goal to expand the information we receive to fully understand the root causes and needs of stakeholders and to fully present these needs to the team to enable changes for sure.

In addition, I would like to mention that to list, analyze, describe, synthesize, and other, BAs use techniques. We will talk about them in the next article.