One option for business analysts is to take on the product owner role, as the following picture shows.
I feel that this option is often a natural extension of the business analyst role. But it usually implies significant changes: The individual should now own the product on behalf of the company, make the appropriate product decisions, and be responsible for product success. The new product owner often has to learn new skills to effectively play the role. This includes creating a valid product strategy, developing an actionable product roadmap, and aligning the stakeholders in addition to working with the development team and managing the product backlog. Consequently, the individual will usually benefit from developing the appropriate product management skills.
The second option for business analysts is to work as team members. This option is depicted by the picture below.
Business analysts working on team often help their peers refine the product backlog. But as backlog refinement should be a team effort, analysts working on the team will take on additional responsibilities, for instance, working closely with the testers or the technical writer. As a business analyst on the team, you should hence expect to learn new skills and broaden your expertise.
Dealing half-heartedly with the role of business analysts in Scrum is a common mistake: Business analysts neither play the product owner role nor are they team members. Instead, they end up as proxy product owners, a go-between the real decision maker and the development team, as shown below.
Avoid using a proxy product owner—certainly as a permanent solution. Take the following example from one of my clients. The head of a business unit was asked to take on the product owner role for a new product. As the individual struggled to effectively fill the role due to their other work commitments, the business analyst stood in as a proxy. While the analyst took care of the product backlog, the business unit head make the strategic product decisions and told the analyst which product features should be implemented. Unfortunately, this resulted in misalignment, a long-winded decision-making process, and poor morale.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
Hi Roman,
I am new to this field, I recently joined as Business Analyst. My senior BSA started writing user stories and assigning it to me and working on those. I don’t know how to show result for the work I have done and how to complete my cards and do my analysis.
Thanks
Thanks for sharing your experience and question Charan. I recommend that you take a look at my article 10 Tips for Writing Good User Stories, which offers guidelines for creating effective user stories. Hope this helps!
Hi Roman,
I have recently taken a new Senior Business Systems Analyst role with an agile development team. I have over 25 years of BSA experience. Previous to my current role, I was a Product Owner/Technical Product owner for a different product and development team. I loved my job and was very successful at it. I worked hard with long hours but absolutely loved the work. Unfortunately, I had a life threatening medical issue and missed 15 months away from work in the hospital and recovering afterwards. Before I returned to work, the team and the product were moved to another part of the company after some restructuring. The senior management decided to assign their own product owner. So, when I returned to the company after my medical leave, they were trying to find a spot for me. It’s an excellent company; they stood by me through my illness and recovery.
Here is where the difficult part is. I am struggling to become part of this new team. They have some dysfunctional issues they are trying to work though. They also have a new resource manager who is from an outside company. The Product Owner is technically savvy and is dedicated and available. The Scrum Master is an over achiever who actually performs more than one role. The development team and my resource manager have been giving me developer type work assignments such as extracting logic from examining the code. In addition, they are expecting me to automate the functional testing. I have struggled with these technical tasks because I haven’t done them before and there is no training other than 15-20 minutes to handoff the work. The application is basically a RESTful api provider to integrate some enterprise applications. It’s a very technical product with no UI’s.
The Scrum Master and System Architect are also assigning me a lot of trivial, low-value add tasks (administrative assistant type tasks). For example, I had to call the help desk and waited in the queue for 3 hours waiting to find out all of the permissions and security groups that the developers belonged to. I had to do this effort because the developers wouldn’t answer my questions. The developers think that since I am not doing development work that I don’t belong there.
The PO does not want to spend time with me and leaves me out of meetings and emails. So, I struggle to fully understand what’s going on. This is an overwhelming challenge for me. I’ve been in the position for 10 weeks. There are several problems, the main one being that my success needs their cooperation; their success does not need or depend on my role/contribution. In other words, my objectives and the rest of the team’s objectives don’t align.
My management knows that I want to do Product Owner work but there aren’t opportunities in this company at the moment. I am doing the best that I can in my current situation and maintaining a positive attitude. In my professional network, I have heard of other business systems analysts being stuck in a similar situations. Many have moved away from BA/BSA roles into being a PO, Scrum Master or developer. What is your advice for my situation? Should I resume my PO career elsewhere? Should I stay and learn as much as I can about technical/developer work?
Thank you!
Hi Tom,
Thank you for sharing your context and question with me. It sounds like you are in a difficult situation. Based on what you have told me, it seems that you are currently a member of the development team. If that's true, then you should not be assigned any work but choose tasks in the Daily Scrum in collaboration with the other team members.
To improve the situation, I would suggest that you have meetings with the Scrum Master, product owner, and your line manager. It may be not be easy but try to understand the Scrum Master and product owner, practice active listening, and try to empathise with them. Then share your perspective and emotions. Additionally, consider addressing the issue in one of the next sprint retrospectives to decide together how you can improve the situation.
If you have already done this or if these aren't viable options, then try to change teams for now and reconsider your longer-term career prospect and future at the company. As a product owner, you will need in-depth technical skills only if you look after a technical product that is integrated into a larger offering. Otherwise, you are better off developing the specifc product management capabilities the role requires.
Hope this helps and good luck!
Great blog!
I wanted to get your feedback on the following situation. I just started a job as a BA for a company that's never had a BA role but found it necessary to help the team. The devs and the project manager are so used to doing all the work the BA would be doing, the biggest example here is gathering requirements. The devs are totally capable of doing this but the goal is to get them coding more instead of doing things I could do. Any tips on how I should go about transitioning? Somethings I'm sure the development team has been used to for years! Change is not necessarily wanted by some developers but needed to help improve processes currently implemented. Also I'm only 3 years into my career as QA/BA/a little bit of development/Scrum Master. I got hired on for a pure BA role though, so it doesn't help that I'm also new and still learning.
Any feedback would be great! Thank you!
Hi Amanda, Thank you for sharing your feedback and question. I fully understand that you would like to focus on your job as a business analyst. In Scrum, however, discovering and describing requirements is a joint responsibility of the product owner and the development team. To help you decide how to best apply your role, I recommend reviewing it in one of the next retrospectives. Share your observations, idea, concerns, and needs with the Scrum team members and listen to their perspectives. Then decide how to best progress. Hope this helps!
Hi Roman,
I love your site (thank you) - I am currently working with some BA's in a Scrum environment. Whilst I understand that the efforts of backlog refinement are a team effort it is sometimes necessary for BA's to work on other supporting items such as Compliance Docs - As this needs to be done would you include it in the Backlog and estimate accordingly or view it as a separate piece of work managed elsewhere?
Hi Simon,
Thank you for sharing your question and feedback. I would suggest that achieving compliance, be it with internal standards or external ones like regulatory requirements, should be the responsibility of the entire development team. How the team carries out the related tasks is up to the group: It's part of the team's self-organisation. In other words, a business analyst who works on the team might carry out the compliance tasks just like a tester would typically carry out testing tasks.
Does this help?
I manage a hybrid BA and project mgmt team currently and the technology organisation in house is moving to SCRUM. Product management feel they are product owners but are struggling with the requirements engineering aspect. There seems to be several options, we all become product managers, we create a BA role purely around reqs engineering and documenting. Possibly some testing element but QA are embedded in the scrum team and we are using BDD. Or that the BA function is made redundant. Thoughts on how best to proceed or what to explore?
Thank you for sharing your question Clare. To help you make the right choice, I'd like to draw your attention to the fact that requirements engineering changes when Scrum is introduced. It is a collaborative effort shared by the product owner and the development team. In other words, the dev team should actively contribute to discovering, describing, and refining product functionality. This seems to rule out the second option you mentioned.
Additionally, when working on larger products, a single product owner is often not enough, and product ownership has to be shared amongst several people. A good model is to have one overall product owner and people who own product parts: feature and component owners. If that's a model you decide to adapt, some of the BAs could work as feature owners. This may well require that the individuals acquire new skills and/or deepen existing ones: Working as a feature owner means working in product management.
Does this help?
Hi Roman,
Thanks for your blog post. I would like to get your feedback about this case: A platform-driven company that offers to its customers (both end users and brands for which it represents a technology partner) digital products and services created a tech governance function to facilitate the dialog and collaboration between Tech and Business. In the Tech stack there are “functional” analyst and Platform Owners, in the Business divisions there are Product Owners, scrum masters and devs while the Business Analysts have been included in the Governance structure to work along with program managers and enterprise architects.
Questions:
1) shall I assume Business Analyst are mainly in charge of product backlog refinement, showcases, UAT?
2) should Platform Owners be considered as Technical product managers owning the vision, strategy and roadmap of their respective platforms/capabilities?
3) what is the difference between functional and business analyst? Maybe the former is in charge of a specific set of capabilities and support the platform owners while the last is a sort of E2E product manager?
Hi Fiammetta,
Thank you for sharing your questions. Here are my answers:
Ad 1: Product backlog refinement is a collaborative task in Scrum and should be carried out by the person in charge of the product together with the development team. As I mention in the article above, business analysts may be well suited to contribute to the backlog work, assuming they work on the dev team. But they would also be expected to take on other tasks to help reach the sprint goal.
Ad 2: Yes, you can look at platform owners as technical product managers, even though there is a difference between a traditional product manager and a product owner, as I explain in the article "Product Manager vs. Product Owner".
Ad 3: I had to look up the role description of a functional analyst as it's been a while since I last worked with such an analyst. Here is what I found: "A functional analyst is a type of business analyst who specializes in a specific technology, line of business, domain or industry." In the context of software platforms, such an individual may be a good candidate for taking on the platform owner role, assuming she or he has the necessary technical knowledge.
It might be helpful to consider that Scrum intentionally does not differentiate between different roles on the development team in order to encourage collaboration. No matter what the team members' specialist skills are, what counts is jointly reaching the sprint goal and creating value together.
Hope this helps!
Hi Roman,
I am a BA and have been involved in a GDPR project.
Testers: (outsourced)
I ended up writing test requirements for the testers, they originally only had happy path tests and about 30% of the tests I ended up putting in place. They had no negative tests
The issue I found with the testers is they have no "Business Domain" knowledge, they were no finding basic business domain errors. I was checking the results of what the testers had passed.
The testers can work their way through the functional screens, but can't identify the "business domain" issues.
Coders/Developers: (outsourced)
This is another group that has no "business domain" knowledge. They had written code that did not align with the business domain process. They had followed the business requirements (user stories) and acceptance criteria, but without basic business domain knowledge, the processes once put together after they were built failed.
The coders can write code but it is very basic, but again no business domain knowledge
From seeing the same issue in a number of different companies and most of the teams.
The conclusion I have come to is:
1. Testers need to know their systems and the basic business domain
2. Developers need to be very experienced to know how to create efficient and configurable functionality and also have basic business domain knowledge.
Without that basic business domain knowledge, the Developers expect detailed specifications - which goes back to the Waterfall process.
The company fired the last set of consultants (big 4) because the had the same issue.
They have another one of the (big 4) and the same problem exists.
Is it just we have ineffective developers and testers or do we go back to waterfall?
Hi Andy,
Thanks for sharing your context and question. I agree with your observation that without some domain knowledge, it is hard for developers and testers to do a good job. The question im my mind is how do you help the individuals acquire the relevant knowledge? The traditional approach is to specify all known requirements ideally in such a way, that they can be directly implemented. The agile approach is to involve developers and testers in collaborative product backlog work and discover and describe functionality together, see my article "8 Tips for Collaborating with Development Teams".
If close collaboration is not feasible for you, then you don't have to go back to a waterfall-based process. But you may want to select working with use cases or a similar technique that allows you to thoroughly describe the product's functionality, please see my article "User Stories or Use Cases?" for more information. Hope this helps!
Many thanks for this article.
please answer my following question:
Suppose that we have an IT company A, and a customer company B that want from company A to develop a system for them (i.e. for company B).
Now we need a person that recognizes the details of the requirements that company B needs.
And as I know that the person that recognizes the details of the requirements is the Product Owner.
My question is: from which company the Product Owner will be?
Will he be from A or B?
If from A: how can he recognize the details of the requirements of another company?
If from B: should he be a system analyst to make use cases?
REALLY I need the answers.
Best wishes
Thanks for sharing your question Muhammad. If it's a bespoke, custom product, then my preference would be to have company B fill the product owner role. Otherwise, the product owner should come from company A. Please see my article "Two Common Ways to Apply the Product Owner Role" for more information.
Additionally, I'd like to remind you that discovering and describing requirements is a collaborative responsibility in Scrum, which should be shared between product owner and development team. Unlike in traditional processes, there is no specialist like a business analyst who is dedicated to this task. Consequently, the team members will have to acquire some knowledge about the market (users, customers, competitors).
Hope this helps!
Very useful article. I am now approaching this career and I really found your opinion useful.
Thank you for your feedback Manuel. Glad you found the article helpful.
Thanks for this article - this is still a hot topic!! And one that's far from resolved.
One of the defining characteristics of "business analyst" job is the breadth of scope for business analyst ranging from the highly technical to the customer facing or process oriented. That means that a business analyst can fit sensibly all three roles in Scrum. You've covered team member and product owner, but, equally, I think some BAs have all the skills of a good scrum master. In particular, a focus on things like communication, facilitation, process improvement, and introducing enabling tools and practices.
This is also part of the trap - the idea of a BA as a proxy product owner is one; but equally they can be the proxy scrum master. And the reverse is true: when I've worked as a scrum master, I've had to resist being too actively involved in backlog refinement; similarly, the product owner needs to know when to leave the fleshing out of user stories to the team.
This is more a statement than a question, but it would be good to get your views!
Thank you for your comment Geoff. I fully agree: Whichever option is chosen, business analysts face considerable change. Effectively applying the roles in Scrum is one of the biggest challenges for organisations in my experience.