Prominent Role of Business Analysts in SCRUM:
A Business Analyst who is briefly referred to 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.
What You Will Learn:
Role of Business Analysts in Scrum
Responsibilities of a BA
There are several Roles of Business Analysts in Scrum and there are certain 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 even at times 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 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. 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 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 is not possible to approach him every time and the only way to communicate is by email or chat or call, 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 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 the Business Analyst as a team member because the Product Owner will not be available every time. If the Business Analyst is a team member then they can help their peers 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 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, 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 the SCRUM Team
The role of Business Analysts in SCRUM is undoubtedly very important in 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, 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 & 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:
- The customer should be able to log in.
- The customer should be able to make transactions on my account.
- 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. 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 everything 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!!