Business analysts play an important role: They usually act as the link between the business units and IT, helping to discover the user needs and the solution to address them. In Scrum, there is no business analyst role. So what happens to the business analysts?
Option 1: Business Analyst Plays the Product Owner Role
One option for a business analyst 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 change: A business analyst turned product owner should now own the product on behalf of the company, and be empowered to decide what the product should look like and do, and when which functionality is released. The individual usually also has to learn new skills including leveraging product increments to understand what users need and how their needs can be best met, grooming the product backlog, and writing user stories.
Option 2: Business Analyst Works as a Team Member
The second option for business analysts is to work as team members. This is option is depicted by the following picture:
Business analysts working as a team member often help their peers groom the product backlog. 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 pick up new skills, broaden your expertise, and be open to work in new areas.
Avoid the Proxy Product Owner Trap
A common mistake is to deal with the role of business analysts in Scrum half-heartedly: Business analysts are neither play the product owner role nor are they team members. They rather end up as proxy product owners, a go-between the real decision maker and the development team:
Using a proxy product owner is not well suited for delivering new features: At a client of mine, the head of a business unit was asked to take on the product owner role for a new product. As he struggled to spend enough time with the team, 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. What followed was an increase in miscommunication, a slowdown in decision making, and a decrease in productivity and morale.
If, however, your objective is to maintain an existing product by delivering small, incremental releases, then you may want to continue working with your existing roles and consider employing a linear, Kanban-based process, as I explain in my post “Choosing the Right Lean and Agile Innovation Practices“.
Scrum is not bad news for business analysts, and the individuals still have a job to do. But just like other specialised roles, the work of a business analyst changes in Scrum. Analysts either play the product owner role or work on the team engaging in a broader range of activities.