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.
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.
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.
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:
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.
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.
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.
No comments:
Post a Comment
Comment