The New Role of Business Analyst in Agile

The toughest role to transition for an organization with a traditional waterfall structure is that of the business analyst (BA) because of the radical shift necessary in the BA’s way of working.

Traditionally, BAs work far ahead of developers, spending months gathering detailed requirements during the design phase before handing them over to developers during the development phase. The product would then move to quality assurance for testing, and project managers would promise delivery dates, often without consulting those who were tasked with building the product. Many organizations have found the process inefficient, leading them to shift to the Agile model.

 In the new Agile world, and specifically with Scrum, BAs work with the team instead of working ahead of them. They are active participants in the Sprint, and they must be invested in the success of the whole team. There are some really obvious benefits of working this way.

Team Camaraderie: Being invested in the Sprint makes you a member of the team

One of Scrum’s core benefits is the opportunity to truly work as a team. It’s a good feeling to know someone has your back and will lend a hand if you hit a roadblock. Team members learn about one another on a personal level in a way that’s impossible when working in silos, and they learn to respect each other as they sweat and bleed side by side to find success.

Invested Team Members: Working together rather than working ahead

Being invested means actively working on committed user stories that help the team meet their Definition of Done. The Product Owner manages clarifying questions on acceptance criteria, allowing the BA to stay on task with the team during the Sprint. If the BA is working ahead of the team, possibly refining the next Sprint, they are not invested in the success of the current Sprint.

New Skills: Contributing in ways that are best for the team 

If a BAs core skill is creating detailed requirements, it may seem scary to be told they should no longer fulfill this role. They may even need to learn a new skill set, like documentation or front-end development. They will also assist with ensuring quality in the Sprint. Where manual testing is still used, teams pitch in to help QA resources at the end of the Sprint. As team members, BAs can help the team ensure user stories meet high quality standards.

Better Stories: Everybody’s input matters

User Story refinement is a team activity that allows the team to find the best possible solution for what they need to deliver. POs work with the customer to understand their needs and pain points. If the BA designs a solution they think will work without the team’s input, the chance of failure increases, and the team’s talents aren’t fully utilized. Additionally, failure to allow developers to learn, grow and experiment is a quick way to lower morale; their opinions should influence the solution, and the BA shouldn’t spend time force-feeding them requirements.

It’s not sink or swim; allow time for a smooth transition

As BAs transition, they might still work a percentage of their time in front of the team as the team works to understand the Scrum world and figure out how they want to work. The process of how to refinine new stories takes time to evolve. The Definition of Done usually takes several iterations and often changes in the deployment cycle before it’s nailed down.

Throwing BAs in the deep end and saying “swim” is not always the best approach. As teams nail down their refinement process, the traditional BA process of working ahead become less and less. They will start seeing refinement of user stories as a team activity that produces the best results, and will find ways to participate in the Sprint.

BAs increase their value within the organization and create the potential for new opportunities by being a member of a Sprint Team and expanding their skills. The world of product development is rapidly changing, so it’s necessary to learn new skills and work differently to keep up.

Five steps to a better refinement meeting Can you create twice the value in half the time at scale?