“We’re going Agile,” my new client announced to me. I smiled. Flashbacks of an idyllic Agile past floated through my consciousness. I remembered my former team’s collaboration, the laser sharp focus on an iteration, the self-organizing empowered teams, the frequent sense of fulfillment after product delivery.
As the conversation progressed, it went downhill. “I guess we won’t be needing Business Analysts anymore,” he said. My happy bubble popped… no better yet… it exploded! Nothing could be further from the truth. Suddenly, I was out to prove how Business Analysts (BAs) are still relevant in this brave new world of Agile.
“The requirements document is going away,” said my client. No document screams Business Analyst (BA) more than the infamous requirements document. In plan-driven methodologies such as Waterfall, this type of document is completed by the BA to capture the project requirements from business stakeholders. Considering that this document was created during the analysis phase of a project as a precondition to the design and development phases, it needed to include all project requirements at one time. It was not uncommon to painfully end up with documents pushing 100-200 pages in length! This took a considerable amount of time and effort for the BA to write and for business, development, and quality assurance teams to review. It was easy to see why my client thought that if the big requirements document went away, so would BAs.
Here is the catch: Although Agile does not prescribe any documentation, this doesn’t mean it forbids it either. In Agile, rather than having large project phases with prescribed documentation, the work is broken down into small increments with a focus on the prioritized Minimum Viable Product (MVP). The Agile team collaborates to decide how much documentation is required and when. For instance, if the focus of an iteration is to perform a UI update, the documentation to help facilitate this shared understanding may consist of a BA documenting user stories and wireframes. It doesn’t make sense to create an unnecessary process flow diagram just because an organizational template prescribes it.
In addition, rather than performing all analysis for a project at one time, a BA performs a more high-level analysis on items that are far along on a product roadmap, but more detailed analysis on those items higher in priority that may soon be pulled into an iteration for development. The BA also helps the Agile team breakdown user stories into the right size for iteration planning as well as categorize them into Epics or Features for easier management.
“What about requirements traceability?” asked my client. Traceability of user stories against higher level Epics and Features is a natural part of user story creation and refinement. Tasks or work against each user story such as development or quality assurance (QA) work is traced as well. Traceability against each user story is tracked individually rather than the commonly used “Requirements Matrix” in Waterfall methodology that is tedious to update.
Getting Started
The bottom line is that a BA’s goal should not be relegated to a document. A document is merely a tool, not the end goal. As a BA, the goal is to ensure a high-quality product is delivered that meets a business need, regardless of the methodology used. We need to get away from putting business analysis into a box or a document template. How?
- The first step is to educate yourself on the Agile methodology your organization is pursuing.
- Secondly, advocate for yourself! Make sure your Agile transformation team knows the specific areas in which business analysis adds value and continues to be relevant.
- Lastly, be open to possible role name changes, upskilling, and obtaining additional certifications to prove your competence.
When all is said and done, business analysis continues to be an integral part of a product’s success. This wasn’t the first time I had given this discourse and I’m sure it won’t be the last. “I’m willing to give it a shot,” said my client. I smiled.
