Role of Business Analysts in SCRUM and Why is a QA Best for this Role?

In this article, we have explained the role of Business Analysts in SCRUM and why QA is the best for this role. Let’s get started.

A Business Analyst who is briefly referred to as a BA plays a very important role in SCRUM. This person is the link between the product owner/customer and the technical IT team.

Though we have come across several tutorials on our website on BA, we assure you that this tutorial will be unique and explain to you the importance of BA in SCRUM.

Let’s Begin!

=> Check ALL Business Analyst Tutorials Here.

Role of Business Analysts in Scrum

Responsibilities of a BA

There are a variety of roles for Business Analysts in Scrum and there are a few responsibilities to which a BA should adhere.

A few selective ones among them are mentioned below:

• Grooming product backlog based on the prioritization provided by the product owner.
• Analyzing customer needs and finding solutions to address them.
• Creating requirements in the form of user stories with appropriate acceptance criteria.
• If in case the user stories have already been created by the product owner (with acceptance criteria), then review them to make sure that all business rules are covered and the acceptance criteria meet the user story functionality.
• Work with product owners and stakeholders to understand the scope, suggest improvements to the requirements, etc.
• Prepare documents like wireframes, design flow, UI, etc., as and when required.

Apart from this, a Business Analyst is an important participant in the brainstorming sessions when the team meets to discuss the upcoming sprint backlog.

The BA guides the team, helps them to understand the requirements, and at times even has to approve the implementation.

He also works closely with QAs like analyzing test coverage, converting real-world use cases into test cases, providing insight to test complex functionalities, etc.

BA also participates in planning meetings to help the team in estimations by helping them to understand the flow, complexity, and dependency.

BA has to keep learning about the new trend that is going on in the market, always innovating and staying updated about the business area for which the product has been made.

Business Analyst as a Product Owner

Depending upon the customer and the company, it happens that some companies have the Business Analyst as the product owner. BA is the contact point for all queries. BA then becomes the mediator between the team and the stakeholders.

BA has to understand the requirements of the stakeholders, their thinking about taking the business ahead, and what (and how) the business should grow.

Then based on the requirements of the stakeholders, the BA must create the documents, user stories, prioritization the stories, help the team understand them, answer their queries about the same, etc.

The most important thing to note here is that this is advisable when the BA is physically available and is not in a different time zone so as to avoid the ‘gap in communication’.

If the BA as in the product owner is in a different time zone, then it may not be possible to approach him every time and the only way to communicate is by email, chat or call, resulting in a lack or gap in communication, and even miscommunication at times.

As per my experience, this should be followed when the BA is sitting in your office, next to your team so that your work won’t hamper, and (s) he will be easily approachable.

From a BA’s point of view, they own the product on behalf of the stakeholders/customers, make appropriate decisions, and even need to learn new skills which may include learning some technicalities of development.

Having a Business Analyst as a Product Owner is an added advantage because the BA is able to understand the product very well, and prioritization and scoping of tasks can be negotiated as well.

Business Analyst as a Team Member

The other option is to have a Business Analyst as a team member because the Product Owner may not be available all the time. If the Business Analyst is a team member then they can help their colleagues with backlog grooming.

Having a Business Analyst as a team member is more advantageous because the technical team finds it easy and comfortable to communicate with the BA for clarifications or discussions.

BA is also working closely with the QA team for testing i.e. analyzing the coverage, use cases covered, any hidden requirements, dependability or effects.

Sometimes the acceptance criteria written by the product owner may be vague and not very clear, then as a team member, it becomes the responsibility of the BA to write elaborate and well-explained acceptance criteria.

If the team needs more information, then the BA can also create wireframe documents, flow documents, etc. to help the team understand the requirements.

In large-scale projects where the modules are distributed among teams, having a BA for more than one team is also an added advantage.

Since BA is the same across teams, (s)he can think about the interoperability of the modules and how new features or updates will affect the other modules, etc.

This would help a great deal for the technical teams to consider such aspects as not always doing the user stories or acceptance criteria mention such.

Importance and Role of Business Analysts in the SCRUM Team

The role of Business Analysts in SCRUM is undoubtedly very important for the success of a project. Their involvement starts right from understanding the customer’s need for a Sprint Demo.

They are the first point of contact for the technical team for clarifications. They are even more important in the initial phases of a new project and the projects which are large in scale.

The Product Owner will not always be a good writer, sometimes they come from a technical background and hence it becomes the responsibility of the Business Analyst to write the stories, acceptance, wireframes, etc.

In my project, our PO was not so good with documentation and even the user stories written were never more than 2-3 liners while the acceptance criteria were only a 1 liner. It was the Business Analyst who used to modify them and make them more explanatory as well as elaborative.

Even at times, it happened that our PO wrote user stories that had 21 or more story points, and hence the Business Analyst had to spend extra time & effort in breaking them down and prioritizing them with the Product Owner.

You can imagine what would happen if there was no Business Analyst and your Product Owner has created a user story like “As a customer, I want to perform all banking operations for my account”, with acceptance criteria like:

1. The customer should be able to log in.
2. The customer should be able to make transactions on my account.
3. The customer should be able to download my historical statements etc.

Now, in my opinion, this user story would hold even more than 34 story points, hence there is a need to break it down further.

Things will worsen for the technical team if the proper flow diagrams and UI screens (to be created) are not provided.

This would lead to a failing sprint, and in turn, a failed project. Unless the Product Owner is a trained/practiced Business Analyst, there is a need to have one on the team. 

Why is QA the best fit for this Job

QA is a person who verifies the proposed solution for a problem/requirement by testing it. Hence the Business Analysts / Stakeholders / Product Owners are very eager to know about the feedback of QA. The involvement of a BA in testing is little more than what it is in development.

A Business Analyst works closely with QA in reviewing the test case coverage which provides insight into hidden flows and requirements/effects. Thus this kind of knowledge sharing (by the BA) makes them understand the product functionality, the business rules, the customer expectations, the flows, dependencies, and everything completely.

QA always tests from the point of view of the end customer who would be using the product, hence the chances of helping the customer for improvements, enhancements in the product are more (when compared to a developer).

Developers develop the product for the given user story and the set of acceptance criteria but do not always think about how a customer would use the product.

In development, the implementation of a product, the flow, and the rules are well defined but testing is completely based on logical thinking and the ability to think from the point of view of the end-users.

QA can start getting into the role of Business Analysts in SCRUM because of the lot of opportunities that are presented in the day-to-day work.

Recommended Read => Career Shift from a Tester to BA

It is very easy for a QA to get into roles like:

• Study the requirements very deeply and point out the gaps in review meetings/brainstorming sessions etc. Try to think about better solutions and discuss the same with the team and the BA.
• Be attentive on calls with the Product Owner, ask questions and share your findings. This will boost the confidence of the Product Owner in showing your interest in the product.
• Fit yourself between the BA and the development team, you should be the point of contact for the developers in case of clarifications or doubts.
• Setup the testing process and keep on innovating it, changing it to help in delivering successful sprints.
• In the case of products with fancy UIs, lookout for new trends and suggest such improvements.
• Understand the product completely in and out.
• Build a strong knowledge of your stakeholders and their expectations and share your experience with them.

This also implies that in order to get into the BA role you need to enhance your skills. There are a number of courses that include both the basic level and advanced level available in the market.

Are you a BA/QA? Have we rightly pointed out everything about your role? Or do you think we have missed something which you uniquely perform? We would be happy to hear from you. Feel free to share them with us in the comments section below!

=> Visit Here To See The Business Analyst Series For All.