I am still in disbelief that so many are saying that there is no role for a BA in agile.
Are you still fighting this battle too?
Though it frustrates me every time, I do understand where this idea is coming from, and I want to share some thoughts and perspectives.
Here is my case for both sides of this industry argument.
The “No BA In Agile” Argument:
The Scrum Guide does not say there is a BA role—it says the agile team roles are scrum master, product owner, and the development team. Many teams start with Scrum in their agile transformations and get trained on Scrum and certified based on the Scrum Guide. This is taking the Scrum Guide far too literally!
By using this argument, the focus is on titles when that is not what I believe the Scrum Guide authors intended. As a “guide,” it needs to be generic to be readable and understandable to many different types of organizations with many different titles, and also many ways of organizing titles and roles.
The agile team needs to be cross-functional and needs to have all of the skills needed to deliver value to the users/customers. Teams that skip analysis, build crappy solutions. Some teams do not use the BA title, but do great analysis and build awesome products, where other roles are doing the analysis. Teams need people with analysis skills for discovery, refinement, prioritization, elaboration, and delivery work. It doesn’t have to be a person with the title of “BA” who does the analysis work.
Historically, BAs in some organizations have been seen as document zombies. BAs in these organizations simply see their role as cranking out endless pages of requirements documentation and to be note-takers. If this is the BA role that you know, I agree, this role is not needed in agile. If you, your team, and the organization believe that BAs are more than documenters and note takers and that BAs facilitate decision making, inspire collaboration and conversation, and analyze beyond what others think and say. Then yes, BAs or someone on the team has to play this role.
To bring it full circle, I am not advocating for documentation going away. I am advocating that documentation in the form of long detailed spec documents changes to documentation that is useable in agile. Things like visual models as assets that the team uses to inspire deep conversations. Analysis models that help the BA analyze the context of the data, people, rules, and process to invoke the right decisions about impact and priorities.
The “Agile Teams Need BAs” Argument:
In many organizations, BAs have been seen and used as catalysts for problem solving and advocates user-centered solution delivery. These analysts guide the team on the intersection of people, process, data, and systems for the big picture and offer a strategic link to the organization’s systems, products, and processes. This view of the BA highlights the skill set needed on agile teams.
That being said, many organizations have many talented professionals titled BA, who have a crazy amount of skills to offer an agile team!
Agile analysis is needed for agile teams to be successful. Agile analysis consists of things like:
- Analyzing the user need and impact desired
- Defining, measuring, and evaluating the solution against impact metrics
- Leading the team in user-centered thinking
- Creating a product vision, and value-centered road map and release plan
- Creating and refining the backlog
- Elaborating on the backlog just in time with acceptance criteria
- Keeping the user-centered approach in helping the development team understand user scenarios
- Keeping the user journey front of mind and analyzing for gaps
- Leveraging feedback loops to update the backlog items as needed
- Facilitating deep conversations about the user’s goals and needs
So, if an organization uses BAs already and believes this is what BAs do, it seems counterintuitive to not have BAs do this work on an agile team.
If organizations have never used BAs previously, they may need to consider it to make their agile teams more successful.
5 Reasons Agile BAs Are Critical to an Agile Team
1. Many large organizations are struggling with the product owner role. They need BAs to partner with POs to bring customer focus as the team refines the backlog and delivers the work. BAs help manage value delivery!
2. BAs have a holistic and detailed view of the customer, user, data, processes, and systems. Without this view, teams will struggle to deliver solutions that hit the speed, relevance, and quality metrics leaders are looking for agile teams to hit.
3. BAs truly care and have compassion and empathy for users. It’s in their DNA! When empowered to make users and customers awesome, BAs will rise to the occasion and represent the user needs on the team.
4. Great BAs speed up the team by having backlog items ready for the team. BAs can facilitate high-quality and fast feedback loops with users/customers which are critical to agile, speed, and innovation success!
5. BAs are T-Shaped skilled team players. Great BAs have a wide skill set that comprises of technical, leadership, business, analytical, facilitation, and communication skills needed to help agile teams thrive! T-Shaped team members are those s that have deep expertise and have the ability to collaborate cross-functionally and apply their deep knowledge and skills in other areas to benefit the team.
Is agile analysis leading to success on your agile team? Are BAs empowered to truly play a BA role to help their agile teams deliver real value?
If your team or organization is taking the Scrum Guide too literally and missing out on analysis, you might be missing the key agile success—using an Agile BA!