Is there a role for business analysts in an agile environment?
I have been working as a business analyst for quite some time now, and that question keeps coming up. Business analysts feel like we have to justify our role in agile.
The fact that this question keeps getting asked stems from the Scrum Guide. The Scrum Guide defines three roles on the team: the development team, the ScrumMaster, and the product owner. You’ll notice there’s no mention of an agile business analyst role. Not to say we are the only ones left out—it also doesn't define roles for solution architects, testers, the quality assurance team, deployment manager, user interface designer, or even writers. We have all somehow gotten shoved into the development team.
It is no surprise, though, seeing as Scrum.org said that development teams are cross-functional. They have all the necessary skills a team will need to create a product increment. Not only that, but the association also doesn't recognize any titles for members of the development team or any sub-teams.
This is all well and good, except that in the Scrum organization I work in, all tasks carried out by the development team happen within the sprint cycle. However, work performed by a business analyst is not sprint-based.
How does an agile business analyst navigate this tricky situation?
3 Responsibilities for a BA in Agile
From my personal experience as a business analyst in an agile environment, some agile projects include a ScrumMaster or a project team performing the ScrumMaster’s duties, but not always. The constant roles have been the development team, a product owner, and a business analyst.
While the development team is in the initial stage of the agile process, a separate UI design team and independent quality assurance officer support them occasionally. It's noteworthy that other roles, like solution architects, deployment and operations, and document writers, are all outside the development team.
All roles in an agile environment have specific duties to fulfill, but I found myself taking on different roles, depending on the organization spearheading the project. However, I generally supported the product owner with some essential activities:
- Carrying out necessary assessments
- Creating business processes modeling and systems requirements
- Ensuring the user stories in the product backlog are correctly maintained
- Planning, writing, analyzing, validating, and maintaining project documentation
These functions were essential to the agile environments I found myself in. However, I soon realized that an agile development methodology could influence the way I functioned as a business analyst.
There were three specific areas where agile shaped the way I carried out my job role.
Communication
If you have ever worked in an agile environment, then you would know that enhanced communication is vital for the success of your projects. Agile needs alignment of all teams involved, including managers and users. The environment also relies heavily on user stories and active feedback loops.
But for communication to be effective, there needs to be a bridge between the various levels and teams in an agile environment. A business analyst serves as that bridge.
Bridging the gap between developers and product stakeholders is especially important. The business analyst can help out by translating the needs of the business into user stories and sending them to the developers, and by prioritizing various deliverables across all teams within the task list.
The business analyst should ensure all teams involved maintain discipline during the project.
Creating the product roadmap
A product roadmap is paramount to the timely success of any agile project.
Roadmaps help with:
- Turning the business needs into technological workflow management
- Mapping the schedule used in conducting project analysis
- Setting testing periods throughout the project lifecycle
By being that communication bridge mentioned in the previous section, the business analyst can gather all requirements and turn them into scheduled, actionable steps for the team.
Keeping the team on track
Keeping the team on course is another fundamental duty of the business analyst. They make sure the managers, developers, and users are all focused on the project's final goal.
I create a lot of models and share them with the teams to ensure that they are all on the same page. I consider modeling an essential tool for several helpful reasons:
- It translates the business requirements of the project into business values, functionality, and user experience
- It communicates the same mental picture to teams in different physical environments
- It serves as a constant reminder of the project perspective to everyone involved
Never let anyone make you feel like you have to defend your role as a business analyst in an agile environment. The BA provides significant value to an agile team in at least these three ways.
If you feel like you need greater flexibility or discipline to see optimum results, you need to rethink your approach to projects in agile. Focus more on improved collaboration, sharing knowledge, transferring skills, making work more visible, keeping project goals top of mind, and becoming an all-around specialist.