Is the main role of a Business Analyst to be a translator?

When I am asked by someone who has no knowledge of software development “so, what does a Business Analyst do?”, I normally explain that I am a point of contact linking “business people” with “technical people”, the "techies" to the "talkies". I then expand on the subject, depending on who I am speaking to. Of course, this is an oversimplification, but to say “internal consultant” or “facilitator” doesn’t quite demonstrate the uniqueness of what we do. Comprehensively answering this question could itself be the subject of another blog post so for now, I want to focus on how relevant a high-level answer this is.

 

There is the classic example of a software engineer who is on his way home from work when his wife calls. “Please can you pop into the supermarket and buy a pint of milk, and if they have eggs, get six,” she says.

Later, he walks through the door. “I’m home, mission accomplished!” he beams.

“But you have bought six pints of milk! Why did you do that?” asks his wife.

“They had eggs.”

The message in this story is that the context is often missed in instructions. In many businesses, it is often felt that technical delivery teams (developers, testers) do not understand the basic goals, let alone overall business goals. Furthermore, in the modern world where team members have different mother tongues, the need for clear  descriptions is ever more important. (Let's not also forget the different dialects across the English speaking world!)

Requirements are sometimes accompanied by a glossary. The less you need to explain in the glossary, the better. It is better to say “get a pack of 6 eggs” rather than to mark “eggs*” and explain that eggs, in a shopping context, tend to come in packs of six. Using clear language, being aware of idiomatic expressions and providing a glossary all seem to be the functions of a translator.

Consider this example: “The page should not have adverts when accessed by mobile devices.” A developer may have a different idea to the business owner as to what constitutes a “mobile device” - is an iPad a mobile device? If so, why isn’t a laptop? A business person might just think that a laptop has a keyboard, therefore it is not a mobile device! Thus, having elicited from the business stakeholder, a business analyst would give a more precise definition perhaps along the lines of “mobile telephones or tablet devices”. Furthermore, the acceptance criteria could list operating systems that are to be excluded from seeing adverts. This removes the need for a glossary to explain “mobile device”.

But are we being too harsh on “techies”? Isn’t the eggs story, just a story? Perhaps. Doesn’t a developer know that a laptop is not generally thought of as a mobile device, even though you can carry it around? If you are working on a product that most people are already familiar with (say a cash machine - or ATM for American readers), then less context is needed for the delivery team - the business analyst does not need to define “withdrawal”.

My suggestion is that the amount of context needed depends on the organisation and, most significantly, the size. If working in a smaller company, technical representatives will likely be more intimately involved with the business discussions that take place, early on. Thus a business analyst will be using other skills in their tool kit, such as being a good facilitator and asking good questions. However, if you work for a larger company, technical staff may have been through an induction of some sort, though much of the product knowledge learned there will not be retained. In addition to this, people get moved across different projects over time, the company changes the product they originally worked on, after they moved, before they came back, and so on. Thus growing companies are increasingly seeing the need to hire more business analysts.

My experience is that business analysts are more likely to have arrived from the technical side, learning the product as they gain experience. (I have heard an estimate of 70% - however, the ideal background for a business analyst should be a separate discussion.) Thus many business analysts are comfortable dealing with the technical team members and understanding how they might interpret a sentence. Yet sometimes you need to “translate” the other way, explaining what is feasible, what the latest technologies can do, their limitations, why a request has such a large estimate and so on. At the same time, subtely in one's language is important - "defect" can be a more loaded term for a business owner than a developer. 

So as a translator of sorts, which do you consider your “first language” - that of the technical team members, or that of the business?

Do you often find that developers/testers don't understand the context? What ways have you seen a business mitigate this?

Alternative Paths, Negative Tests and Acceptance Criteria

Acceptance criteria in a user story are like an informal contract - if they are met and quality assurance engineers / testers are happy, then a delivery team can argue that the story is complete, their work is done, they are free to move on to the next piece of work. Yet there are many potential behaviours of the software that could still happen which would lead to an unsatisfactory result. As a business analyst, this puts added importance to what you put down in the story.

Consider this example: The French government tells Facebook that French users can only log in via www.facebook.fr, and that it would be illegal for them to log in from www.facebook.com. (One can only imagine - perhaps to protect the French language?!) The definition of a French user - by IP address or country of residence - is not addressed for the purposes of this article. As part of meeting the regulations, we could have the following user story:

As a Facebook executive,

I want French users to to get an appropriate message when they are logging in to facebook.com

so that they understand they need to go to facebook.fr instead.

Acceptance Criteria

1)  A French user cannot successfully log in to facebook.com.
2) There is a message explaining to the customer after trying to log in that they need to go to facebook.fr (text to be confirmed with customer communications team)
3) By default, the message is in French.
4) Upon clicking an “OK” button in the message, the French user is redirected to facebook.fr.

In this example, there are some potential user actions that are not mentioned, yet somehow need to be covered to satisfy the overall business picture...

a) What happens when a French user enters an incorrect password?

b) What if a user hits the back button on their browser (and potentially the code might let them into facebook.com)?

c) How does a user see the message in other languages?

To each of these potential actions, let’s imagine that we do not get the behaviour we expect, yet the delivery team are claiming that acceptance criteria are met, thus the story should be signed off.

For a) we can agree that a user should not be logged in. But should they get the “incorrect password” message, rather than the “France redirection” message? If the latter happened I would say the user would be unaware that they are closer to a limit that puts a security flag against their account. This is because, with my own knowledge of how security works, the customer would not be informed of the incorrect password entry, meanwhile an addition is made to the incorrect password count.

Therefore, the “incorrect password” message should come first. Should the QA engineer / tester know this? Shouldn’t they have picked this up in regression testing? Much here depends on the technology organisation - whether it can be expected that QA engineers know how the system works on such a level. On balance, I would argue that for this alternative path, we are introducing a business rule (the new France message follows the “incorrect password” message in precedence). Therefore, a separate user story, correctly linked to the first, should be created and tested in its own right. I would also then be more stringent in the original user story, stating that it only applied to “validated” customers, where “validated” is defined as having successfully entered in valid credentials.

For b), I would not accept a delivery team member saying “but you didn’t mention this in the acceptance criteria”. This is clearly a defect and against the spirit of the story. With agile software development, business analysts cannot do requirements to such detail, nor should they. There should be a level of common sense and understanding of how things should work, without it needing to be spelt out. Plus, if I did cover this scenario in the requirements, where would it end? (back button + “Enter key”, “Esc” button,  etc...) This behaviour should be found through “negative testing” - verifying that what shouldn’t happen, doesn’t. Acceptance criteria should generally focus on what should happen.

For c), here I would say it is something the business analyst should have mentioned in the acceptance criteria in the story. Having French users understand they should go to a different page is part of the story. Furthermore, the story has mentioned that the default language is French. It needs to be mentioned how a user gets the message in a different language. There could either be a dropdown in the message for switching language, or the user could select one of the existing language links towards the bottom of the Facebook homepage. Both are feasible options, yet a key stakeholder from the "user experience" team may feel strongly one way or the other. Thus it needs to be both documented and part of this story. Therefore an extra acceptance criteria is needed.

To summarize how to cover alternative user journeys (paths), I would ask whether the expected behaviour is minor and should be commonly understood by the delivery team, as well as if it is essential to the user story under test. See the illustration below...  

Please let me know your thoughts...