Role of Business Analyst in Agile Process (Professional Business Analyst Training organisation)
Out of many roles on an Agile team - developer, tester, project manager or product manager the role of the business analyst is probably the one whose the team is depend most frequently challenged. The role of a BA is to gather the requirements and often questioned, not the quality of work, but the “perceived� value delivered for the team - by clients.
Frankly speaking I’ve had a few identity crisis since I started working as an analyst on agile teams. So what does the Agile Analyst bring to the team ? I have noticed that when a project start with an business analyst, there is a two biggest benefits to the development teams have been there are...
Everyone on the team questions 'Why' including the customer Many seem to blindly believe that the business analysts' sole responsibility is to "write" stories. It is true for business analysts. In the agile world, it is essential for the business analyst to talk to the stakeholders and establish communication mechanisms to understand why we are working on something before we develop it.
Traditional BA (Waterfall)
Agile BA
Requirements are documented in Use Cases, Requirements are documented in Epics, User Business Requirements, Functional requirements, Stories and optionally Business (or Essential) Use UI Specifications, Business Rules. cases.
Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.
Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.
Focuses on ensuring the requirements meet the Focuses on getting a ‘sign off’ on the requirements. currentbusiness needs, even if it requires updating them. Often there is a wall between the BA/Business and Agile BA (Often called as Product Owner) is part of the Development team. the team. Tends to dictate solutions. Long turnaround.
Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions. Quick turnaround.
Focus on what the requirements document said. In Focus on the functionality of the developed other words, output (Artifact) is a well written software. In other words, output (Artifact) is the thorough requirements document. software that meets thebusiness needs.
And it is as essential for the analyst to then foster a shared understanding of this with the entire team. This two-way communication flow between development and business. On a distributed team of more than 20 people in the project retail client, our team wasn't understanding of the domain as a whole and what the work we are doing.
Why it is required. As I have spent a good amount of time to understanding the domain in the beginning I decided to do 'lunch and learn' sessions to share my learning using diagrams. And actually It helped the team to clear the dots by understanding where each story fits in.
As we continued to do this, we started to have valuable conversations like 'this is why we need this story' as we thinking more 'we have to create more stories in this area', 'finish the stories before the rest of the stories for this feature' and so on. The impact of such conversations put us to think what values each story was bringing in.
Which in turn helps me to start the right conversations with the business which feed in our team’s understanding the value of each story.