The role of Business Analyst on agile projects is often overlooked. For instance, the Scrum Guide, describes only three roles: Scrum Master, Product Owner, and Development Team. Further, the Scrum Guide’s description of the Development Team role does not mention analysts or analysis work.
However, good BAs are great assets for any team, be it plan-driven, agile or hybrid. BA’s unique skill sets, and collaborative approach aligns with the agile mindset to deliver value to customers.
BA’s on Agile Projects
- The Work of Business Analysis
- How Business Analyst Work Changes on Agile Projects
- Enhancing Business Analyst Agile Knowledge
The Work of Business Analysts
Business Analysts elicit, analyze, communicate, manage, and validate requirements. They also help understand the business, ensure proper solutions, translate technical issues, and facilitate stakeholder communications.
Business Analysts ensure the project builds the right product, and requirements are not missed or misunderstood. They are also valuable to help facilitate and bridge communications between client, customer, and technical groups.
Business Analysis functions still exist on agile projects, and, because agile timelines are often compressed, these functions become more critical for teams to remain productive, making good BAs valuable. So how do BA roles change on agile projects?
How Work Changes for Business Analysts on Agile Projects
Given the nature of agile, business analysts need to understand how their role and work on projects must change on agile projects. BAs who apply their knowledge and skills to an agile environment benefit the larger project. Here are some ideas:
Help Visualize and Manage the Big Picture View of the Problem
The shift to more “visual and verbal” formats occur frequently on agile projects. Agile teams typically do not create large, detailed requirements documents that get reviewed before development begins in earnest. Instead, requirements may be captured as user stories or on index cards that act as reminders to have a conversation with the relevant subject matter expert prior to development.
Requirements are typically smaller in terms of scope and description, like micro requirements for attention deficit readers who only want small, bite-sized components. Task boards and shared knowledge spread as teams collaborate and work in co-located spaces. This more granular structure provides greater options for moving and reprioritization within the backlog. People tend to be better at estimating and testing things in smaller chunks as well. However, a more granular structure increases the number of elements to manage.
Define Requirements Through User Stories
Another significant change found in agile projects has to do with requirements. There is no project phase dedicated largely to the identification and understanding of the requirements. There is much less confirmation of the requirements with signoffs before getting started. Instead, requirements are gathered throughout the project from customer demonstrations and planning sessions. This process defines the work for developers.
BAs must remain ever vigilant for potential stories lurking in customer questions or other potential scenarios. The good news is the role of the Product Owner helps filter the important from the unnecessary and assign a priority for development.
Discover New Approaches and Tools
Where work typically gets done changes on an agile project. BAs should expect fewer dedicated offices and more open space team rooms. This makes long, heads-down focusing more difficult, but it works well for the thinner slicing and capturing of stories. Agile teams rely more heavily on face-to-face communication, which is quicker, allows for questioning and clarification more effectively, and conveys body language and emotion more easily.
Many agile teams have distributed team members, so everyone should be familiar with online collaboration tools. Requirements typically reside in online repositories accessible by stakeholders from anywhere. A Business Analyst’s adaptability and willingness to master these tools is important for them to stay relevant and add value to the team.
Emphasize Teamwork Over Roles
BAs play an important bridge or translator between clients, users, and technical resources, but, that role changes on agile projects. Agile Development Teams are generalizing specialists with a broader set of skills including talking to the business stakeholders and gathering requirements. This plays directly into the traditional BA territory, but BAs deliver value if they act as facilitators for this work.
In an agile environment, BAs should not interview the business stakeholders and deliver their understanding to the developers. These telephone-game handoffs dilute the message and are what cross-functional, co-located teams were created to avoid. Great BAs are not a go-between. They are matchmakers and conversation-starters asking questions to create discussion between stakeholders while replaying conversation snippets if there is a difference of opinion. BA’s ensure frequent check-ins with all stakeholders to confirm understanding and that no voices go unheard.
Enhancing Business Analysts on Agile Projects Knowledge
The value BAs bring to project teams does not change in the transition to agile if they are willing and able to change their tools and approach to fit the new environment. Role titles may change. However, smart, cooperative, and flexible team members will always be required to make projects successful. A savvy BA who is willing to adapt and pitch in where help is needed will always be a valuable team member.
BA’s who are interested in enhancing their skill set have lots of training options. Explore RMC’s popular eLearning skill building courses, including Agile Fundamentals and Emotional Intelligence. Both are great options when working on agile and hybrid agile projects. RMC also offers thoughtful live and recorded webinars to expand knowledge and skills. We’re here to help so contact us with any questions.