Business Analyst or Product Owner: Which Are You in an Agile Environment?
Identity Confusion
As Software Development processes change and as businesses adapt to delivering products and enhancements quicker, roles within Information Technology departments are continually changing. With these changes, IT Leaders have a tendency to rename positions without truly understanding the skill set and functions which accompany the title.
At the top of this list are the liaisons to the business: Business Analysts. Information Technology departments are obviously predominantly developers of some sort or another and thus, the leadership’s understanding of non-developer roles can lead to confusion; confusion within the team, the organization and with the actual employee.
The Business Analyst
The Business Analyst (BA) role was very clear in the Waterfall development methodology: liaise with the business; elicit requirements; create documentation such as Business Requirements and Solutions documents; and maybe assist with testing.
“Business Analysts possessing intellectual curiosity have voracious appetites for learning. They do not shy away from new or unfamiliar concepts. They tend to be very good listeners who absorb information like sponges.” Steve Blais
Business Analysts were the go-to source to so team member to bridge the gap between the business/client and the IT department. It is essential for BAs to understand the business processes, goals, future states, etc. It is also critical to be able to properly communicate in business terms when working with the client. However, the BA also had to be able to translate business-speak into requirements developers could use for programming.
Business Analysts are “an agent of change” as described by the International Institute of Business Analysis (IIBA). In order to be this “agent” the analyst must be knowledgeable of regulations, technology, reporting strategies, and key market indicators. It is also important for BAs to understand finance in order to do cost-benefit analysis, budgets and project estimates.
The Product Owner
The Product Owner (PO) originated in the Agile Scrum environment but has evolved to be used in most, if not all, Agile approaches.
The PO, according to the Scrum Guide, is the party responsible for maximizing the value of the product. Product Owners need to constantly examine the project’s progress, business needs and objectives to ensure the deliverables offer the highest value. POs will routinely reorder User Stories and tasks to maximize value for the business.
Since the Product Owner is responsible for the overall roadmap, she/he must collaborate with the business on an almost daily basis. This differs greatly from the Business Analyst who will normally meet with the business to gather requirements then return to primarily only engage with others in the IT department. BAs leave updates and other interactions to the Project Manager.
Product Owners will also spend much more time creating user stories, acceptance criteria and tasks in the Product Backlog than writing a Requirements Document upfront. The Product Backlog becomes the documentation for all to refer to. It is the source of truth and all changes are immediately input so that nothing is developed out of a “misunderstanding” or failure in traditional communication channels. And since the backlog is the project’s “bible”, the Product Owner will manage it and use it to translate the product vision into a form the development team can clearly visualize to ensure the client’s expectations are met.
Since Agile calls for development and releases in “iterations”, backlog tasks are only assigned and committed to during sprint planning so that work of lesser value does not rise to the top of the prioritized list. The Product Owner works with stakeholders to identify and organize the steps required for the next iteration while the current iteration is being developed.
Product Owners have decision making authority and are expected to exercise that authority to deliver for the client while optimizing IT resources.
Business Analyst or Product Owner — which do you need?
While Business Analysts are often more technical and more experienced in many aspects of the business, Product Owners have the responsibility to anticipate the business’s needs and to prioritize and reprioritize work to deliver high value, high quality solutions with each iteration.
Simply put, the Product Owner is the voice of the customer, whereas the Business Analyst acts as a representative of the development team.
My humble advice: Elevate your most experienced Business Analysts to become Product Owners and entrust them to create a lasting, valuable relationship with the business; IT can then become the reliable business partner modern organizations need and rely on.
