Prominent Role of Business Analysts in SCRUM:

A Business Analyst who is shortly referred as a BA plays a very drastic and 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, this tutorial will somehow be a unique one and will explain to you the importance of BA in SCRUM.

Let’s Explore!!

=> Check ALL Business Analyst Tutorials Here.

Responsibilities of a BA

There are several Roles of Business Analysts in Scrum and there are certain responsibilities to which a BA should adhere to.

Few selective ones among them are mentioned below.

• Grooming the product backlog based on the prioritization provided by the product owner.
• Analyzing the customer needs and finding the solutions to address them.
• Creating the requirements in the form of user stories with appropriate acceptance criteria.
• If in case the user stories have been already created by the product owner (with acceptance criteria), then reviewing them to make sure that every business rule is covered and the acceptance criteria meet the user story functionality.
• Working with the product owner and the stakeholders to understand the scope, suggest improvements to the requirements, etc.
• Preparing 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’s backlog. The BA guides the team, helps them to understand the requirements, and even at times has to approve the implementation.

He also works closely with the QA’s like analyzing the test coverage, converting real-world use cases into test cases, providing insight to test complex functionalities, etc. The BA also participates in the planning meeting to help the team in estimations by helping them to understand the flow, complexity, and dependency.

BA has to always keep learning about the new trend that is going on in the market, keep innovating and stay 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. In these cases, the BA is the contact point for all the queries. The BA then becomes the mediator between the team and the stakeholders.

The 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 geolocated to a different time zone so as to avoid the ‘gap in communication’.

If the BA as in the product owner is geolocated to a different time zone, then it not possible to approach him every time and the only way to communicate is by emails or chats or calls, hence this may result in lack, gap, 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 Business Analyst understands 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 the Business Analyst as a team member because the Product Owner will not be available every time. When the Business Analyst is a team member then they help the peers in 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. The BA also works closely with the QA team for testing i.e. analyzing the coverage, the use cases covered, any hidden requirements or dependability or effects.

Sometimes the acceptance criteria written by the Product owner may be vague and not 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 also creates 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 also is an added advantage. Since the BA is the same across teams, (s)he can think about the interoperability of the modules, how new features or updates will affect the other modules, etc.

Thus this would help a great deal to the technical teams to consider such aspects as not always do the user stories or acceptance criteria mention such.

Importance and Role of Business Analysts in SCRUM Team

The role of Business Analysts in SCRUM is very important in the success of a project. Their involvement starts right from understanding the customer’s need to the 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, make them more explanatory and 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 & efforts in breaking them down and prioritizing them with the Product Owner.

You can imagine what would happen if there’s 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 do transactions in 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 would 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 a QA Best fit for this Job?

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

A Business Analyst works closely with a QA in reviewing the test case coverage which provides an insight into hidden flows or 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 not always do they think about how would a customer 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 the 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 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, 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. Several courses which include both the basic level and advanced level are found in the market.

Are you a BA/QA? Have we rightly pointed out all about your role? Or Do you think we have missed something which you uniquely perform? We would be glad 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.