Recently, I was watching a webinar which stated there is no formal role for the BA in the Agile world. I completely disagree with this statement as I can attest, from my own Agile experiences, to the fact that my BA role is necessary, important, and distinguishable. However, it did lead me to contemplating the real differences of a BA in an Agile role versus a more Traditional/Waterfall role. I even posed the question to some of my peers on LinkedIn. After some conversation and consideration, I feel the differences in BA role can be summarized by different expectations for both documentation and relationships.
The first thing that stands out to me between Waterfall to Agile is the difference in documentation. In more first BA role ever, we used a Waterfall approach. We literally spent a couple months translating requirements into massive specification documents. There was significant thought and elbow grease involved as we worked to try to get all of our requirements right up-front. As I’ve began working in Agile BA roles, this is not the case. The documentation is much lighter and the requirements process is much more fluid. I focus on high-level business requirements and work with my IT partners to translate those into User Stories. I will add success criteria and make updates and revisions to User Stories. Then, these are added to the backlog.
The second big difference is the relationships. When working in a Waterfall BA role, I was on client sites for 2 months for one project straight collecting massive amounts of requirements notes. Then, there was a definite disconnect as I went back to translate my notes into documentation. There were follow-ups with the client for clarification, but for the most part, my focus was producing the deliverables. The development teams were not all that engaged until we got sign-off and approval of our requirements documentation. Within the Agile world, there is continuous facilitation and communication with both stakeholders and development partners. I find myself spending more time with my IT partners getting answers to their questions, and providing my stakeholders and Product Manager assistance filling in gaps and helping understand and prioritize various efforts.
In summary, the work in Agile and Waterfall is the same and the focus is definitely different, but the role of the BA is important in each. The Agile BA role involves much more consistent facilitation and, in my experience, more consistent working relationships throughout the project. The Waterfall BA focuses more heavily on documentation and getting requirements sign-off. I prefer the Agile world for the consistent collaboration. By staying more aligned with stakeholders and IT partners throughout the process, the project is less likely to deviate off course. In my mind, the risk of Agile development is losing sight of the big picture objectives. It is important that Sprints maintain themes and objective benefits for the business. All-in-all, I still prefer BA life in the Agile world.
- Bringing Your Company’s Business Analysts Together - March 20, 2015
- Working with External Clients for the First Time - March 20, 2015
- BA Life in the Agile World - March 20, 2015
- I have requirements approval! … Now what? - March 20, 2015
- Laying Out a Plan to Testing Success - March 11, 2015
- Advice for being a BA “Newbie” - March 4, 2015