What Should We Do With Our Business Analyst If We Are Adopting “Agile”?

If you read the Scrum Guide, you may realize a few things that you may have expected to be there. Where’s the Business Analyst in Agile organizations? In Scrum, there is no such a person. If you follow the Scrum Guide, any contributor would be considered part of the “Development Team”, which might work fine. There may be other options that could make sense for your team.

Could your Business Analyst serve the team is a different capacity? Possibly!

There is no single “right” answer to this situation, since there are many factors. Below are a few options you might consider.

Option 1 – Convert your Business Analyst to a Scrum Master

This approach is one that I have experienced while working with various organizations. This option might work out well if your Business Analyst is strong in process management, and has strong interpersonal skills. In my opinion, highly-technical analysts typically struggle to make the transition to a Scrum Master role because of a natural desire and inclination to dive too deep into the technical details.

Option 2 – Convert your Business Analyst to a Product Owner

There may be a natural fit for your Business Analyst to serve as a Product Owner, with a few caveats of course. Assuming that he/she possesses strong domain and customer knowledge, to be successful as a Product Owner, this person needs to be in a position to represent the stakeholders and make important decisions for the new Agile team. Aptitude and knowledge is important, but without authority, a Business Analyst in an Agile environment will likely struggle to be an effective Product Owner.

Option 3 – Convert your Business Analyst to a Team Member

This option may not require a “conversion” but just a slight adjustment to the role to encompass different responsibilities. Depending on what your Business Analyst’s current responsibilities are, he/she may not need to change the day-to-day responsibilities too much. Within an Agile/Scrum team, an effective team typically has multiple “T-shaped” individuals who have broad understanding of key knowledge areas, complemented by deep understanding of one (or two) areas. Your Business Analyst could become a “utility player” of sorts that can fill in to handle a variety of tasks such as writing/validating User Stories, building/execution test cases, etc. In my experience, the most effective and successful Agile teams will need someone like this at some point.

Before you embark on the journey of Agile transformation, it may be helpful to think through how you will provide opportunities for your current staff and motivate them to “jump on the train”. Hopefully the ideas that were shared in this article will give you a few ideas to consider.