Normally in Agile development, people don’t mention about Business Analyst role. So what will be the true story behind the scene?
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. (Roman Pichler)
What will BA do in a Scrum team?
Option 1: product owner
This is a natural move. The individual needs to own the product on behalf of the company instead of analyse and get features approval from specific clients. For that significant change, the individual might need to learn new skills to adapt new role.
Option 2: team member
The role of business analyst as a team member will mostly to address and help other members groom product backlog. Since this responsibility is for the whole team, business analyst inside a Scrum team usually covers additional tasks as well like writing technical documents, coordinate with testers.
The role of a Business Analyst in an Agile project is not well-defined just as there is no defined role for a Project Manager on an Agile project. On small, simple Agile projects there may not be a need for either of these two roles but that is frequently not the case on large, complex enterprise-level projects.
The role of a BA is often neglected – it is assumed that the Product Owner plays that role but it can be difficult for a Product Owner to perform that role without some assistance on very large complex projects
(chuckc3)
Option 3: proxy product owner
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.
(Roman Pichler)
Why this model is not-recommended? Because it requires many communication to verify each single decision thus brings lots of miscommunication, misunderstanding as well as inconsistent product requirements. At the end, no one is really the Owner of Product.
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. (Roman Pichler)
Conclusion
There is no fixed direction, solution for a traditional business analyst to follow in Scrum world. But I think from the above suggestions, insights, we’re all more clear about the basic concepts.
Scrum is not a plug-and-play environment that will guarantee that product development will succeed. If improperly managed, the product development will not adequately scale to the customer’s requirements, which will increase costs, impact return on investment, and lead to instability. (Sriramasundararajan Rajagopalan)
Reference:
- http://www.romanpichler.com/blog/business-analysts-in-scrum/
- https://www.scrumalliance.org/community/articles/2014/february/mapping-of-the-product-manager-role-to-product-own
- http://agilemodeling.com/essays/businessAnalysts.htm#ProductOwner
- http://managedagile.com/the-role-of-a-business-analyst-in-an-agile-project/
