A business analyst role in agile and Scrum, in particular, is a controversy. Some believe a business analyst in a Scrum team contradicts the essence of agile methodology, where self-sufficient teams of developers regularly communicate with a business representative, Product Owner. Since elaborate requirements documentation is no longer needed, why keep the figure of BA?
Let’s explore the question and see how the BA role in scrum ensures a project’s success.
Can’t we do without the role of Scrum business analyst?
We surely can. After all, a Scrum team is multi-functional and self-contained. Developers work closely with the 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?
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.
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 realize 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!
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 as part of the scrum team?
You cannot underestimate the value of a business analyst as 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.
BA has a knack for distilling useful requirements from exaggerations and distortions. Analytical skills allow transforming 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).
Release plan, as compared to the Product roadmap, focuses on the tactics to ensure timely release. It taps into the Product backlog for details. Burndown charts are great at tracking the progress in relation to expenditure. Let the tools do the tracking job for you.
There is not only a big picture concerning a product design but a great interaction design as well. 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 for an agile Scrum team
A figure of a business analyst in a Scrum team may seem an oddity to some. But not Scrum business analyst responsibilities. It’s a myth that developers can cope on their own. The strength of a Scrum team is in its universal mixture of technical and non-technical skills. In fact, a business analyst role in Scrum is not one, but three.
Role #1. Product Owner
A business analyst becomes the 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 the 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.
The difference between Agile and Waterfall is best seen by comparison. Both methodologies have pros and cons. By understanding the development techniques, you’ll know when to use each and how to develop a better strategy for your project.
Role #2. One of the dev team
That’s the best possible option. If a client can actively participate in the development, s/he becomes PO, whereas BA directs more attention inwards: visualizing ideas, writing user stories and acceptance tests, communicating with the team and stakeholders, and sorting out matters at hand. Since Scrum doesn’t cast the 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, maybe assisting with other activities, such as testing or technical writing.
Role #3. Scrum Master
This business analyst role in Scrum is suitable for someone with strong management skills, especially if the objective is to promote collaboration and an atmosphere of trust, to maximize workflow efficiency, or if the chosen level of ‘client-vendor’ formality requires thorough process documentation.
What does Agile EVM do better than a release burnup chart?
- Agile EVM is more informative
- Agile EVM embraces change
- Agile EVM ties together abstract and time-bound valuations of effort
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, while others remain 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 the flexibility and resilience of Agile processes.