Prominent Role of Business Analysts in SCRUM:
A Business Analyst who is shortly 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.
=> Check ALL Business Analyst Tutorials Here.
What You Will Learn:
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 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 review 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 QAs 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 is 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 & effort 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:
- The customer should be able to log in.
- The customer should be able to do transactions in 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 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 Analysts / 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.
19 thoughts on “Role of Business Analysts in SCRUM and Why is a QA Best for this Role?”
Thank you for providing such a valuable information.
Thanks, great write up.
Very informative article, very well explained.. thanks for sharing this..
nice one. motivating to me as well all QA’s
good to know more about BA Roles and it very clear to me…
Informative post on business analyst SCRUM
First of all, There is no BA or QA in the scrum. There are only developers, PO and Scrum Master. And there is no Roleplaying either. if you are changing role or adjusting it is not scrum its something else. If you think QA can be best for PO then it will be the biased view for the project.
Nice motivating articles for all QA’s.If anyone who is on QA field if they follow surely they will have a good scope and future.
You can have BAs and QAs in scrum. What scrum says is that they to an extent should
Be able to do each other’s jobs when needed.
No no and NO…..there are no BA’s in SCRUM… period… you are just saying if my PO sucks, use a BA instead??? sorry… get the PO proper training… or you will just find your way back to waterfall….PO, SM, Development Team… period…a BA might support the PO, but putting them in the Team, or between the PO and the Team will be detrimental to the proper workings of SCRUM.. period
While there may not be a formal “role/title” of BA in SCRUM, the business analysis tasks are still needed. Those can be done by anyone on the team who possesses those skills. In some organizations, those tasks fall to the PO, and in others they have a formal “BA” job title, and others spread those tasks among the entire team. Whatever works best for the team! We shouldn’t get hung up on the title “BA”, but look at the business analysis skills needed on the team.
Thank you Marilyn, you said what I was about to say. People like Chris and Kevin seem to be confusing job titles (Developers) with the type of work described in scrum (developer – a generic term used for anyone involved in building a product whether that’s analysing, testing or coding). So if you have a BA doing analysis and a QA doing the testing they are all part of the team DEVELOPING the product, ergo they are ‘developers’ (small ‘d’).
In my experience, many Developers (the job title of the people doing the coding part) are not great at analysing user needs (in the same way that BAs are not very good at coding – they are very distinct skill sets), hence why we sometimes have poor products with unhappy users as the Developer creates something THEY think needs to be built rather than understanding what the USER wants.
The skill of the analyst is understanding what that user need is and translating it into a story that everyone can work from, and articulating the acceptance criteria that meets that need. And whilst bigger companies will have researchers and user experience (UX) experts the gap that’s often missing is the logical understanding to ensure that a user need can actually be met (ie the user isn’t asking for the impossible). Another example is considering both the happy and unhappy paths of any user journey (although on larger stories you may want to split these paths).
Where I disagree with the author of this article is the level of collaboration with testers (“Why is a QA Best fit for this Job?”). The stories should be easy to understand and the need articulated clearly enough for everyone on the team to know what is required. If the testers don’t understand something, or require further clarity or think some acceptance criteria is missing they can discuss this with the BA. But how the QA wants to write their tests is entirely up to them and entirely up to them to use whatever QA standards they follow. At the heart of any build is
a user story and only a user story. If anyone in the team wants to create any other artefact that may help them do their part, well, that’s entirely up to them. The real measure is making sure your working software meets the user need that’s been expressed – and that’s the need often expressed in the user story.
Well said CHRIS – you are spot on!
I only believe that a BA can operate as a Product Owner if that is the dedicated role. A BA cannot be expected to act as a BA AND a PO in the same role, it needs to be one or the other. This is because they ultimately conflict because the BA’s priorities usually revolve around a specific project or client implementation, where a Product Owner’s priority is the product itself.
Eh?! There is no BA in Scrum?! BA is ultimately a traditional waterfall project management role.
In Waterfall you do all the Analysis up-front. In Agile/Scrum you only do enough analysis for the first increment or MVP, and base your subsequent increments based on learning from Customer Feedback on ACTUAL USE OF THE PRODUCT (i.e. the PO communicates with them or studies the usage analytics, etc).
Go ask Jeff SUtherland! What you’re ‘teaching’ here is WRONG!
thanks for sharing such a nice content about BA
thanks for sharing
there is no BA role in Scrum by design. Jeff Sutherland and Ken Schwaber purposefully *eliminated* the role. Maybe focus on doing Scrum properly and coaching and supporting the roles to be effective, instead of suggesting putting band aids over larger problems.