Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Role of business analyst in agile process coepd


Published on

COEPD - Center of Excellence for Professional Development is a primarily a Business Analyst Training Institute in the IT industry of India head quartered at Hyderabad. COEPD is expert in Business Analyst Training in Hyderabad, Chennai, Pune , Mumbai & Vizag. We offer Business Analyst Training with affordable prices that fit your needs.
COEPD conducts 4-day workshops throughout the year for all participants in various locations i.e. Hyderabad, Pune. The workshops are also conducted on Saturdays and Sundays for the convenience of working professionals.
For More Details Please Contact us:
Visit at or
Center of Excellence for Professional Development
6th Floor, Sahithi Arcade, S R Nagar,
Hyderabad 500 038, India.
Ph# +91 9000155700,

Published in: Education, Business, Technology
  • Be the first to comment

Role of business analyst in agile process coepd

  1. 1. Role of Business Analyst in Agile Process (Professional Business Analyst Training organisation)
  2. 2. 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.
  3. 3. 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...
  4. 4. 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.
  5. 5. Traditional BA (Waterfall) Agile BA Requirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules. Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use 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 getting a ‘sign off’ on the requirements. Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them. Often there is a wall between the BA/Business and the Development team. Agile BA (Often called as Product Owner) is part of the team. Tends to dictate solutions. Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions. Long turnaround. Quick turnaround. Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document. Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.
  6. 6. 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 of retail client, our team wasn't understanding of the domain as a whole and what the work we are doing.
  7. 7. 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.
  8. 8. 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.
  9. 9. 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.