About Agile Business Analysis.
This transition can be a big change for some BAs, and a subtle one for others. It all depends on the mindset and patterns you have already established. To smooth out the transition, let’s explore what agile is really all about.
Agile Myths Related to Business Analysis
Myth —> There is no role for a BA in agile
Myth —> There are no requirements in agile
Myth —> There is no planning in agile
Myth —> Agile doesn’t look at the big picture of the solution
Explaining The Myths
The myth that there is no BA role in agile comes from those practicing Scrum. Scrum is one of many agile frameworks that teams use. Scrum recommends that teams follow the Scrum Guide to learn and perform Scrum correctly. The Scrum Guide lists 3 roles on an agile team: the scrum master, product owner and the development team. This is where many practitioners, trainers, and coaches interpret no BA role.
I have talked to some of the original Agile Manifesto authors, and some that are also very close to Scrum and even contributed to the Scrum Guide. When I ask them about this issue, they are all VERY clear that analysis is a must in agile, and it’s up to the entire agile team to determine who has the skills to make sure it happens.
In a document like the Scrum Guide, the authors must keep things as simple as possible. They are catering to all types of teams and organizations. This is why they limited Scrum to 3 simple roles. This does not mean that there aren’t other roles on the agile team.
The Scrum Guide needs to make sense to all types of organizations and teams, and it doesn’t try to choose from existing titles in small or large organizations to accommodate everyone. It’s up to the team to determine how to make sure all of the key activities happen. And every organization and team has existing people with titles that do not match the Scrum Guide exactly. The authors of the Scrum Guide did not intend to change anyone’s title or force new titles on anyone.
So, anyone who says there is no role in agile for BAs, is either taking the Scrum Guide too literally (and shouldn’t be) or is misinformed and does not truly understand Scrum and agile.
Need more proof? The Agile Alliance, which is the umbrella organization for “all things agile, that all agile frameworks align to” partnered with the IIBA (International Institute of Business analysis) to write The Agile Extension to the BABOK. This publication promotes agile analysis and defines the agile BA role for organizations and teams who use BAs.
Yes, Agile teams use BAs!
Teams and organizations using an agile approach are using BAs and BAs are proving to be essential to agile success.
Agile analysis is a critical part of the team’s success. Without agile analysis, teams risk building something that the users and customer just don’t need. They risk building a solution or product that does not meet expectations or worse yet, creates adverse impacts internally and for customers.
Agile Analysis IS Agile Planning
It’s all about planning what will deliver value next, mid-term and long term. This analysis isn’t easy! It’s an incredibly complex, relationship-oriented, and evidence-based art. Teams that do not plan and analyze, simply don’t deliver valuable results.
We have all seen or experienced bad analysis: the system that needs to be rebuilt due to a critical requirement discovered too late, a system that just didn’t make sense to us as a user, a website or app that just didn’t work and we had to make a call to get help, or a new system or feature that made a mess elsewhere in the system or process.
Just because a team is agile, does not make them immune from these issues. In fact, agile teams need analysis even more due to the speed and dynamically changing nature of agile work.
Agile BAs are critical to making sure what is built is what matters most!
BA Role on an Agile Team
The business analyst role on an agile team is multifaceted and complex. It’s not an easy role!
The agile BA role is involved in all aspects of the team. From helping the product owner develop a compelling vision and success metrics all the way through the process of development and ensuring effective and realistic test cases.
Product Owner Collaboration
Sometimes the BA is assigned the product owner role, and sometimes the BA is a sidekick of sorts to help the product owner be successful! Agile BAs collaborate with the product owner on the product vision and the impact metrics the team uses to evaluate their success. Agile BAs evaluate the user and solution to see how the impact metrics are performing. Then, they work with the team, product owner and stakeholders to refine and prioritize backlog items based on user feedback.
User Perspective for the Team
Agile BAs facilitate deep conversation about user scenarios, bringing the user and customer context to the team every day.
They are a big part of backlog refinement and elaboration. Agile BAs are available to the development team to answer questions about backlog items and the user, data, and process perspective. Agile BAs help the development and QA teams develop test cases that are realistic and effective.
Agile BAs ruthlessly protect the team from feature bloat. They keep the team focused on customers by creating small chunks of valuable work so the team can maximize learning and get user feedback.
Agile BA Competencies
The following skills are found in the best agile BAs:
- Facilitation
- Designing collaborative & engaging meetings
- Guiding decision-making processes
- Creating shared understanding of complex problems and the solution vision
- Relationship building
- Communication (verbal, non-verbal, written)
- Influence without authority
- Abstract thinking
- Decomposition from big picture to smaller pieces
- Working with ambiguous concepts
- Visual modeling of complex concepts into simple pictures
- Analyzing and visualizing the user and customer journey
- Analyzing and visualizing the data flow, relationships and customer impact
- Understanding user goals and communicating the goals and context to the team
- Defining, modeling and analyzing rules logic
- Defining, modeling and analyzing business, systems and user processes