When I first started my career as a Business Analyst, I had a rough understanding of what the role entailed and how critical BAs value is in Product development.
In my quest to understand more about this role, I learned pretty quickly that various assumptions and misinterpretations existed around this role in Agile-related conversations. Assumptions such as agile teams do not need “requirements” therefore, the role of BA is useless or there is a Product owner so, a Business Analyst role is not necessary.
After being in this role for a few years now, I feel that nothing could be further from the truth. Even though the business analyst role isn’t mentioned all throughout the descriptions of the Agile Manifesto, it is essential to an Agile team.
Here are three main Agile principles that will help you rethink of this role and influence the way you do your work as a Business Analyst:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Working software is the primary measure of progress
Welcome changing requirements, even late in development.
The old method of product management involved strict planning and specifying requirements without any feedback or information from the end-user. While Agile as an approach for products is about ensuring what is built is valuable to the business and end-users.
To deliver working software, Agile teams need to be able to discover what their targeted user needs are and determine a solution that will have the most value to the business and customers, so you as an organization can effectively practice Agile principles.
But where do those requirements come from for teams to build a solution that provides value to the users?
How do you determine what the working software is supposed to do?
That’s where the role of Business Analyst comes in. Perhaps the role and interpretation of an agile business analyst will look different from small companies to larger organizations. But I believe there are some core responsibilities, expectations, and qualities that remain the same among most organizations that are going through Agile transformation.
So how does a Business Analyst exactly add value to an organization? If you’re currently working as a BA, you’ve likely realized that your tasks are no longer just submitting depth requirements plans and detailed spreadsheets. Nowadays, requirements change frequently, and the traditional BA tasks that you’ve learned seems to disappear on an agile team.
BA’s value to the organization now is much more than the tasks they do. It’s no more just submitting a checklist of deliverables; instead, it’s about creating valuable software in the leanest way possible. The way you do this is by producing quality dialogue between the business and development team through a series of collaborative discussions, not documents. You, as a business analyst, have a responsibility to facilitate shared understanding among a diverse group and identify increments of value and priority setting.
It’s crucial that you first understand what your organization as a whole is trying to solve for the end-users.
My general approach to problem exploration is through asking a series of questions to understand a big picture:
🔹 What problems do our customers have?
🔹 What is the context around when they experience these problems?
🔹 What are they currently doing to solve their problems, and why is it not working?
🔹 What matters to the users in a solution?
🔹 What are the right flows and features to solve this problem?
🔹 Do they enjoy the experience we are creating for them?
The collaboration and dialogues between various parties will serve you better to track down the answers to questions above, validate assumptions, and ensure what you’re building truly does solve problems for the users. You want the interactions with real customers and the team to drive requirements rather than taking handed documents with all the requirements defined upfront from the business.
Once you have a clear understanding of the user’s needs, you then work with your product owner to analyze priorities and work to decompose them into small pieces. Each piece should deliver value to the customer and should be small enough for the team to estimate accurately.
A good BA is someone who can take a holistic view of the product backlog to match business goals and priorities and find those inner related requirements and interdependencies while ensuring details in user stories are appropriately defined and represent true value to the business.
Clear continuous communication is essential not only in your written stories but also in the way you collaborate with your team members throughout the development process. It’s not uncommon to see development teams who spend hours building something but have no clear understanding of what is even desired from the business or customers. You, as a BA, would need to collaborate at every step in the development to make sure the team is delivering what is expected and there are no surprises at the end of the sprint.
When creating user stories, focus on defining the “who,” “what,” and “why” that accurately reflects the end user’s expectations with the functionality. Touch base with the team during development to give early feedback so that dependencies or blockers can be resolved early and chances of developing something which is not in the scope is significantly reduced.
👉🏼 FINAL THOUGHTS
The journey of discovering real value for the end-users as a BA is one that’s continuous questioning, sharing, and adjusting. Business Analysts that embrace agility will increase their effectiveness in an organization by adhering best practices while adopting a growth mindset.
Cheers! Laxmi Khanal
