Business Analyst: Roles and Responsibilities in a Scrum Team

787
4.67/5
06/24/2020
7 minutes

There’s no such thing as Business Analyst (BA) in Scrum. So why bother? Can’t we do without this role? What can possibly go wrong? And how can s/he help in our self-contained and self-organizing Scrum team of software developers? These questions are regularly heard nowadays. And they often hurt the experts in question. In this article, we will try to address them.

Can’t we do without this role

We surely can. After all, a Scrum team is described as multi-functional and self-contained. Developers work closely with Product Owner (major business-driven ideologist) and Scrum Master (primary process facilitator) on a daily basis. It works out perfectly and who cares about a business analyst, right?

Wrong!

What can possibly go wrong without a business analyst

Scenario #1. Failure to bridge the knowledge gap

Imagine, a client asks you to develop software for Plumbus manufacture. You say, ‘Sure. Easy as pie’ and get down to business. But where do you start? What questions do you ask? And how do you go about measuring the scope or writing user stories? Most importantly, are you sure the instruction below will help you understand the true business value of the product?

For homemade plumbuses, always push your dinglebop through a grumbo so your fleeb doesn’t fill up with its own juice. Or you’ll find out how badly hizzards can get in the way when you’re trying to flag down a freelance blamph through a handful of chumbles. Spitting schlami optional.

from Rick and Morty (TV Series)

Sounds like Martian, eh?

But what you really should beware of, is a ‘hidden’ trap – when a conversation with a client seems perfectly normal, and yet you can’t make a head or tail of what they are talking about. Like in this kids’ riddle:

  • — Are they red?
  • — No, black.
  • — Why are they white?
  • — Because they’re green.

It won’t make much sense until you realise the conversation revolves around currants. Clearly, without understanding the context and getting the grasp of a client’s domain knowledge, your interaction will remain meaningless.

Scenario #2. Requirements chaos

OK, you’ve elicited the requirements from the client, stakeholders, and end users. Now you’ve got a neat (you think) and clear (just wait!) big picture of what you are going to build. It reads like this:

This thing is a Thneed. A Thneed’s a Fine-Something That-All-People-Need! It’s a shirt. It’s a sock. It’s a glove. It’s a hat. But it has other uses. Yes, far beyond that. You can use it for carpets. For pillows! For sheets! Or curtains! Or covers for bicycle seats!

Dr. Seuss The Lorax

Are you sure you’ve gotten to the crux of the matter and can build it right? Even if you can do that, requirements (no matter how neat) do not equal the design, which comes as a result of a cognitive creative process of behavior analysis.

Scenario #3. Conflict of interests between the client and end-users

Have you been through a dilemma of whether to cut functionality or compromise quality just because a client urges you to cut costs? Which would you choose provided that the market research proves you will fail either way? Or should you just quit? Tough choice! And no one to step in and remind the client about not compromising on your brand promise.

How can a business analyst help

Solution #1

BA is a requirements elicitor. S/he knows the right questions to ask and can anticipate problems and model future situations. A business analyst understands the merits of DDD in getting great soft. Without proper understanding of the context and domain knowledge, communication will be meaningless. This role is particularly relevant for remote teams where communication with a client and stakeholders is hampered by distance.

Solution #2

BA has a natural flair for distilling useful requirements from exaggerations and distortions. Analytical skills allow to transform disparate and incompatible requirements of various stakeholders into a clear product’s value vision. Software engineers are great designers… for machines. That’s their mode of thinking, and they may find it hard to think otherwise. A business analyst, on the contrary, loves doing what developers find hard to cope with and can detect human behavior patterns. Moreover, they are great at translating research into actionable sketches and narratives, and especially at writing ‘compelling and useful descriptions of software form and behavior’ (Alan Cooper).

Solution #3

There is not only a big picture concerning a product design but a great interaction design that must be taken care of. And a business analyst has a phenomenal ability to reconcile variance of interests. Because BA addresses business rationale as well as user rationale, s/he will ensure there is a balance of mutual value.

Business analyst 2.0

There’s no such a figure as Business Analyst in a Scrum team. But that does not mean the competence of BA is no longer needed or that developers can cope on their own. The strength of a Scrum team is in its universal mixture of technical and non-technical skills. And BA can be easily cast in one of Scrum’s three roles.

Role #1. Product Owner

A business analyst becomes a sole decision-maker who shoulders responsibility for the product’s ROI. This role detaches a business analyst from the team and shifts him or her closer to the business side. It’s all right with some projects where a dev team possesses wider expertise to go by. However, this will only work out if a client is willing to delegate authority in decision-making to Product Owner (PO). Otherwise there is a fear for BA to turn into a Proxy PO, just a figure, a title, which may create unnecessary complexities and bottlenecks and hinder product development. On the other hand, this role may overwhelm BA with too many responsibilities in case the dev team needs more day-to-day assistance in business matters.

Role #2. One of the dev team

That’s the best possible option. If a client can actively participate in development, s/he becomes PO, whereas BA directs more attention inwards: visualising ideas, writing user stories and acceptance tests, communicating with the team and stakeholders and sorting out matters at hand. Since Scrum doesn’t cast dev team into special roles, BA will be an ordinary team member. Apart from the regular duties, like verifying various brain-waves against acceptance criteria and UX, may be assisting with other activities, such as testing or technical writing.

Role #3. Scrum Master

This role is suitable for someone with strong management skills, especially if the objective is to promote collaboration and atmosphere of trust, to maximize workflow efficiency, or if the chosen level of ‘client – vendor’ formality requires thorough process documentation.

How strong is the chain

The old adage – ‘a chain is only as strong as its weakest link’ – applies perfectly to business-related issues, like bottlenecks. And that gives us the clue to a business analyst’s role. The expertise of a business analyst covers almost every non-technical aspect of software development – business analysis, process & documentation control, interpersonal communication and ‘business – IT’ alignment. One of these skills can come to the fore and determine the key responsibilities, with the others remaining supplementary. Since BA’s knowledge base is so versatile, s/he can strengthen the weakest link in the process flow, especially in situations developers find the most challenging, like communication, management, and other ‘wasted’ non-technical work. And this adds to flexibility and resilience of Agile processes.

Did you enjoy the read? Was it useful? Your sentiment helps us to create better content. Use the reactions to assess the article. Or leave us a note in the comments. We are out here to boost your tech savvy.
4.7/ 5.0 rating (36 votes)
Leave a Reply