Business analysts play an important role: Traditionally, they act as the link between the business units and IT, help to discover the user needs and the solution to address them, and specify requirements. But in Scrum, there is no business analyst role. So what happens to the individuals?
Business Analyst as Product Owner
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, as I discuss in more detail in The Agile Product Owner Responsibilities. The new product owner often has to learn new skills to effectively play the role. This may include creating a valid product strategy, developing an actionable product roadmap, and aligning the stakeholders—depending on the individuals current skill set. (You can test your know-how and identity gaps in your knowledge by taking my product management test.)
Business Analyst as Team Member
The second option for business analysts is to work as team members. This is option is depicted by the picture below.
Business analysts working on team often help their peers groom the product backlog. But as grooming is a team effort in Scrum, analysts working on the team 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.
Avoid the Proxy Product Owner Trap
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 blow.
Using a proxy product owner is best avoided—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 he struggled to fill the role effectively, the business analyst stood in as a proxy. While the analyst did all the detailed grooming work, the business unit head decided about the product features and when which functionally was released. Unfortunately, this resulted in miscommunication, a long-winded decision-making process, and poor morale.