Agility and flexibility are vital in the fast-paced lifestyle we have. Time is the essence and people don’t want to spend it irrationally. It is no wonder that the traditional waterfall method is getting more “agile” every day.
One of the most common agile methods is Scrum. It constantly talks about prioritizing and doing things in an order that makes sense now; instead of something agreed several months ago. Agile also blurs several erstwhile roles and definitions and offers a fresher way of looking at things. We then tend to map former definitions to roles in Agile. It is often asked where a Business Analyst (BA) fits in Scrum. Should he/she be a Product Owner, is that closer to a ScrumMaster or should BA be a part of development team.
While the Scrum roles have a strict definition:
· Product owner – holds the vision for the product
· ScrumMaster – helps the team best use Scrum to build the product
· Development team – builds the product
And you may be tempted to put BA under a development team as there is no other defined role. However, like several other things in life, there may not be a "One size fits all" solution. There may be several factors in determining what may work best for your setup.
1. Yours is a big project with multiple stakeholders with interests in specific areas. There may be some requirements from technical team, some from legal, some guided by sales and yet others a prior executive commitment made. It is important that the final product is aligned with expectations from all stakeholders or a common ground is agreed on and there are no surprises in the end. Here you may want to have different members playing the role of Product Owner, Scrum master and BAs. Product Owner(s) are aligned with external stakeholders, bringing their interests to project team. ScrumMasters are responsible for maintaining and managing individual scrums. BAs are a part of development team, working closely with business stakeholders and Product Owners. A key here would be effective communication between scrum team members themselves (PO, SM, BA and development team) and also between different scrum teams. Scrum of Scrum needs to happen as diligently as daily scrums. You may also extend this to have representatives called to Sprint Review meetings.
2. Yours is a smaller setup, with a set of defined stakeholders. Here you may want to have the same person play the role of PO and a BA. He/She would work closely with customers, bring in the requirements, prioritize them, create and maintain the backlog. You need to make sure that the setup is smaller, enabling the person to play both the roles efficiently. PO must get the time to interact with external stakeholders, get their interests and requirements aligned and prioritized appropriately. BA must get the time to explain, review and test the requirements in every sprint.
3. There are distance/ time difference between key stakeholders and rest of the team. The team isn't very large, but it isn't very small either. Here, you may have the PO situated closer to the timezone of majority of stakeholders, enabling him/her to be available to them as needed. The BA may be interacting more frequently with PO and interacting with external stakeholders for complex requirements or discussions. The PO here may be a link between BA and external stakeholders for a while. If the BA is skilled enough in Scrum practices, it may be logical for him/her to play the role of ScrumMaster too. He/She can efficiently manage the scrum and at the same time, make sure that the requirements agreed are delivered. She may need to guide the PO also in managing the scope. Having an understanding of requirements is an advantage.
Perhaps the vital parameters of a successful agile delivery are innovation and adaptability to get more efficient. There would be several factors into play and you need to define what works best for you and your team. Make that a practice and keep it simple!