BA's on Agile Projects?
January 01, 2017
The role of the business Analyst (BA) on agile projects in some ways parallels the role of the project manager (PM). In that, some people believe these roles are not needed at all! The Scrum Guide, for instance, that outlines the Scrum approach describes only three roles: Scrum Master, Product Owner, and Development Team. Even when you look deeper into the Scrum Guide’s description for The Development Team role, it does not mention analysts or analysis work. However, most organizations agree, good BAs are great assets for any team, be it plan-driven, agile or hybrid.
This article examines what BAs really do, looking at what stays the same on an agile project and what changes. The quick version is that the What and the Why fundamentals stay the same, but all the How, When, Where and With Whom details change dramatically.
Let’s start with What business analysts are supposed to do. (I say supposed to do rather than actually do because yours might watch cat videos most of their time and that is not what they are supposed to do!) Anyway, Business Analysts elicit, analyze, communicate, manage and validate requirements. They also help understand the business and make sure the solutions fit the business. In addition, they help translate technical issues to the business and facilitate stakeholder communications.
Why they do these things should be fairly obvious. To help 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.
The good news is that all these functions, roles, needs or whatever you want to call them still exist on agile projects. Also, to some extent, because agile timelines are often compressed, these functions become more critical for teams to remain productive and so good BAs are extra valuable.
Now for what changes; let’s start with the How? Agile teams typically do not create large, detailed requirements documents that get reviewed and signed-off before development begins in earnest. Instead, requirements may be captured as user-stories, or on index cards that act as reminders to go and have a conversation with the relevant subject matter expert prior to development. They are typically smaller in terms of how much scope they cover and depth of description. More like micro-requirements for attention deficit readers who only want small, bite-sized components.
This more granular structure actually provides greater options for moving and reprioritization within the backlog. People also tend to be better at estimating and testing things in smaller chunks too. However, it increases the number of elements to manage and so BAs who can help manage and visualize the big picture view of the problem are especially valuable. The shift to more “Visual and Verbal” formats occurs frequently on agile projects. No longer is the bulk of information written, instead, task boards and shared knowledge spread as teams collaborate and work in co-located spaces are the norm.
When the requirements are elicited, analyzed, communicated, managed and validated change also. No longer is there a project phase dedicated largely to the identification and understanding of most the requirements. There is much less confirmation of the requirements with sign-offs before getting started. Instead, they are gathered throughout the project, just-in-time for consumption by the developers and as they emerge from customer demonstrations and planning sessions. BAs have to remain ever vigilant for potential stories lurking in customer questions. The good news is the role of the Product Owner helps filter the important from the unnecessary and then assign a priority for development.
Where work typically gets undertaken changes on an agile project also. BAs should expect fewer dedicated offices and more open-space team rooms. This would make long, heads-down focussing on big documents more difficult, but works well for the thinner slicing and capturing of stories. Agile teams rely more heavily on face-to-face communications which are quicker, allow for questioning and clarification more effectively and also convey body language and emotion more easily.
Many agile teams have some or several distributed team members and so everyone needs to get familiar working with online collaboration tools. Requirements typically reside in online repositories accessible by stakeholders from anywhere. An adaptability and willingness for BAs to try and then master these tools is important for them to stay relevant and add value to the team.
Finally, the With Whom component; BAs still play an important bridge or translator role between clients, users and technical resources, but again the role changes. Agile development teams are encouraged to be generalizing specialists with a broader set of skills including talking to the business and gathering requirements. This plays directly into the traditional BA territory, but BAs are still valuable if they act as facilitators for this work. Maybe focussing more of their time on the most difficult to interact with stakeholders (business or technical) and making sure no voices go unheard and ensuring check-ins we all the stakeholders to confirm understanding occur frequently.
The deliberate shift from go-between to facilitator merits further review. We want to avoid the business being interviewed by a BA and then the BA passing on 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 go-betweens, but instead match-makers and conversation-starters. Sometimes asking the (apparently) dumb questions to get topics discussed between stakeholders and replaying conversation snippets back when there seems a difference of opinions.
BAs generally have good communication skills and a knack for identifying gaps in knowledge or contradictions. When we leverage those skills to facilitate conversations between business and technical resources they add a ton of value to any project.
In summary, the value BAs bring to project teams does not change in the transition to agile; providing they are willing and able to change their tools and approach to fit the new environment. While role titles may change, smart, co-operative and flexible participants will always be required to make projects successful. A savvy BA who is willing to adapt and pitch in where help is required will always be a welcomed and valued team member.
{Mike Griffiths is a consultant and author specializing in effective delivery. He wrote this article for ProjectManagement.com and it was first published here - membership required to view]
Good article. I have been on teams where there was no BA and on teams where there was a designated BA as part of the process.
I think this is also a matter of project scale. Certainly, there is always a need for BA skills: "elicit, analyze, communicate, manage and validate requirements. They also help understand the business and make sure the solutions fit the business. In addition, they help translate technical issues to the business and facilitate stakeholder communications".
On some teams, these skills are already present in one of the key Agile roles. On others, or if it is a larger project with many user stories, an additional person with those skills will definitely be needed.
Posted by: Lhanthorn | January 09, 2017 at 08:20 AM
BAs on the project team and in fact including anyone on the project team is a function of the characteristics of the project, the internal organizational environment and the external market situation. And all of these continually change over the project life span. And so the appropriate structure of the team will also change over the project life span. The agile project is a unique and complex project. The BA is usually a welcome addition.
Posted by: Robert K. Wysocki, PhD | January 10, 2017 at 06:06 AM