With the advent of Agile methodologies, project roles and responsibilities have transformed significantly.
Agile focuses on GTDQ, getting things done quickly. Anything that comes in the way of this goal, needs to be eliminated. As a result, many traditional IT careers are disappearing and new career opportunities are blossoming in their wake.
One of the IT careers impacted most by the Agile revolution is the Business Analyst. In this post, I’ll discuss how the role of the Business Analyst has transformed with Agile.
Does the BA still have a role in Agile Projects?
Yes, they do.
Much has been said about the relevance and importance of the BA’s role in IT projects in general. Since the BA is an established presence on IT projects, we won’t spend time debating it.
Instead, we’ll focus on elaborating the role a BA plays on an Agile project, and how this differs from Waterfall. Just so we’re clear, the BA has an important role to play even on projects following Agile methodologies.
Now that’s out of the way, let’s see how a BA’s role has evolved to adapt and succeed in an Agile world.
Ring-fenced versus end-to-end involvement
With Agile, the project team is empowered beyond what you’re used to with Waterfall and other traditional methodologies. and with more empowerment comes also end-to-end responsibility.
It is no longer enough for a BA to play a ring-fenced role – e.g. only document requirements, only focus on IT solutions analysis, etc.
To succeed in an Agile environment, you need to own Requirements Gathering, be deeply involved with Solutions Analysis, and be prepared to actively collaborate with Architects, Developers and Testers on a daily basis to achieve Sprint and Release objectives.
In other words, you need to be willing to step out of your comfort zone and take on tasks and activities that would normally not be considered a traditional BA responsibility.
Requirements gathering versus product ownership
BAs on Agile projects are increasingly aligning themselves to Product Owners. And for the right reasons.
If you’re working on a product that is even remotely successful, your Product Owner/s is probably splitting their time across multiple Scrums, markets, and time zones. The primary focus of POs tends to be to define a roadmap for the product, which they then expect their scrum teams to bring to life.
This means the PO won’t be sitting in on every Scrum call, or be on hand to provide requirements clarification. The BA can quite capably fill such voids, by deputizing for the PO and ensuring the Scrum team is aligned with the PO’s vision.
BAs that are willing to take this additional responsibility go on to take on PO roles eventually. Talk about career progression!
Upfront requirements elaboration versus piecemeal
In Agile, you don’t need to pin down all requirements to the lowest level of detail right upfront. You do, however, need to learn to understand high-level requirements and the solution and focus on elaborating a small piece of the puzzle to enable the first few sprints.
The ideal Product Backlog has mainly abstract requirements, with just the top-ranked user stories elaborated in sufficient detail. As your team begins picking off the top-ranked stories for sprint delivery, you should begin to elaborate stories further down the ranking order and bake in learnings from early sprints.
Support high-level solution design followed by in-sprint detailed design
We saw how understanding high-level requirements and solution helps make an Agile BA effective. This is achieved when you spend time with the PO, Architects, and Tech Leads to pull together a high-level solution design (HLSD) for your Product Backlog.
This solution design provides a reference point to all efforts at a lower level. When you have queries about how the system will handle a low-level requirement, you should be able to refer back to the solution design.
During Sprints, it is possible that your team discover factors and variables that alter the HLSD slightly, or (more rarely) completely. Most often, any minor ongoing changes to solution design are expected and welcomed.
This reflects the true learning nature of Agile – you enter Sprints armed with less detail than you normally would, and constantly discover and course correct.
Double-hat as a scrum master
Anyone can be a Scrum Master – especially the Business Analyst.
BAs by nature, are well suited to the responsibilities of the Scrum Master role, as they bring many of the skills necessary. Scrum Master roles are effectively an alternate career path for BAs who are seeking diversity and growth.
Bringing it all together
Agile has brought some much-needed rigor to software development by shining the spotlight on delivery instead of a process for process’ sake. Just as other project roles have adapted to Agile, so must the Agile Business Analyst.
The transformation required for a BA to adapt to Agile is straightforward. The question is, whether you will take this leap of faith. Would you?
