One of the hottest topics in the technology world today is what role a Business Analyst plays in agile software development and project management. Within the context of the Scrum method for doing agile work, the question is whether the BA can fit any of the primary three roles (Scrum Master, Product Owner, or Development Team Member). The Business Analyst isn’t mentioned as one of the three, so what is a BA to do if they want to do a great job in a Scrum Master role?
And if the BA is applying for a Scrum Master job, what skills should the Business Analyst showcase on their resume to make the case they’re the best fit for the position?
I happen to think business analysis is such a versatile field, one that employs such highly useful skills, that a BA can succeed brilliantly in any of the essential Scrum roles. So, let’s start with the Scrum Master.
Rule #1 For Succeeding in A Scrum Master Role as a Business Analyst
The #1 rule for succeeding in the role is to remember your key function as Scrum Master: you are a servant leader whose purpose is to solve problems and remove obstacles. Doing this successfully helps ensure delivery of the project.
That may sound different from what a BA normally does, but it really isn’t. Consider a couple of things that a BA does in the typical BA job:
- Why does a BA gather requirements? To solve the problem of describing what a business solution is supposed to do.
- Why does a BA conduct a JAD session? To resolve the obstacle of people not talking to, and understanding, one another because of lack of coordination.
See what I mean? The Business Analyst’s role is also to solve problems and remove obstacles. That makes the BA a natural fit when reaching for a Scrum Master role.
There are some differences, though. The Scrum environment is intensely collaborative. Many tasks that a BA might have previously done alone, like gathering or managing requirements, can now be a team effort. In the Scrum environment, then, the BA can expect to lead problem solving by facilitating group collaboration and helping to arrive at a consensus.
Business Analyst as Scrum Master: Facilitating Meetings
The BA is no stranger to facilitating meetings. Conducting JAD sessions, interviewing business reps, resolving stakeholder conflicts, fielding questions from executives. The BA does it all. That experience with running and facilitating meetings serves the BA very well when stepping into the Scrum Master role.
Scrum requires several different meetings. They include the daily stand up, product backlog review meetings, and sprint review meetings. While the purpose of each meeting varies, the end goal is the same: resolve problems and move the project forward to conclusion.
The Scrum Master is expected to facilitate these meetings and run down the solution to the problems participants encounter. The BA-as-Scrum Master knows how to do this in spades.
Business Analyst as Scrum Master: Identifying and Working with Stakeholders
The BA’s experience in identifying and working with stakeholders comes in very handy in the Scrum environment. If the BA is assuming a Scrum Master role in the same environment they were was in before, they may have lots of institutional knowledge to draw upon. That can only help in identifying essential stakeholders.
But even if the BA is new in the organization, having a BA’s knowledge is essential in identifying and working with stakeholders. A BA knows when to bring in a customer, a user, a business sponsor, or executive at precisely the right moment in time. These stakeholders will eventually want to (or need to) interact with the Scrum team’s activities. The BA-as-Scrum Master knows the right person to bring in for the right purpose at the right time.
There’s also inevitably going to be conflicts between stakeholders, perhaps even conflicts between members of the Scrum team. When this happens, the BA’s skills in communication, conflict resolution, and stakeholder management will be exactly what the team needs to get past the problem.
Business Analyst as Scrum Master: Developing Epics, User Stories, and Their Acceptance Criteria
Epics and user stories are requirements. They’re just stated in a different way to accommodate the quick, short bursts of development effort over the course of a few weeks (sprints) that you use in Scrum. They usually take the perspective of a user of the solution in trying to define what the Scrum team should develop.
But they’re requirements, that’s the key point. No matter how you write epics and user stories, or in what format, they’re still requirements.
And does a BA have a role to play in creating good requirements? Um, yes.
The same goes for acceptance criteria. In the traditional BA world, these criteria match what the solution does with the original requirements to ensure compliance. The BA helps to write them.
It’s no different in Scrum. Each user story must have related acceptance criteria to help guide whether the solution works properly. The BA as Scrum Master lends their experience to help make that happen.
Again, officially the Scrum Master role is that of facilitator. But if a BA steps into the Scrum Master role, you can bet they’re going to be taking a leading role in crafting great epics, user stories, and acceptance criteria. The team will thank you for it.
Business Analyst as Scrum Master: Prioritizing the Product Backlog
The product backlog is a list of features, functions, software bugs, epics, and other requirements reserved for future implementation. It’s sorted by priority based on the business value each entry would bring when/if the team implements it.
The Product Owner usually takes primary responsibility for managing the backlog. However, the BA-as-Scrum Master also has a role to play. Managing the backlog is basically requirements management, which is another important BA skill. The BA-as-Scrum Master can advise the Product Owner on how to prioritize the backlog.
What features does the business consider critical vs. nice-to-have, and why? What prioritization scheme should the team use? And who should the Product Owner work with to ensure they prioritize everything properly? These are some of the questions that the BA playing the Scrum Master role can help answer.
Business Analyst as Scrum Master: Managing Scope
Scope means the boundaries of a project as agreed upon by stakeholders, in terms of the requirements the team will deliver given the available period of time and money.
Every BA probably dreads the word “scope” at one point or another. Unfortunately, stakeholders can sometimes become unhappy with a project’s current scope and may seek to change it midway through the project. We call that “scope creep.” It can have all kinds of bad consequences, including total failure of the project.
The BA must “put out the fire” before it gets out of control. She must bring all the communication skills and experience at her disposal to manage stakeholders and get them to stick to the original agreement.
It’s no different in Scrum. The Product Owner may try to change the requirements or acceptance criteria half way through a sprint. The project could fail if the team allows that to happen. So, the BA-as-Scrum Master must once again call upon her BA “powers” to get the Product Owner back on track as per the original agreement.
As you can see, the Business Analyst is incredibly well positioned to be an outstanding Scrum Master. It comes down to leveraging your BA skills to the hilt and understanding the relationship between those skills and your job expectations in the Scrum Master role.
What advantages do you feel a Business Analyst brings when being a Scrum Master? Leave your thoughts in the comments!