Business Analyst and the Agile Business Analyst

Written by  
Often I have been asked how the role of the BA would change in an agile environment. Software development teams transitioning form a Waterfall methodology to an Agile methodology often have difficulty in clearly defining roles and responsibilities of the team members. This is especially true for the role of BA, as agile teams include a business owner who plays a more involved role than in a Waterfall process. 

Though there is a business owner working closely with a development team playing a product owner role, the role of a BA is extremely important in organizing the business needs and creating the roadmap for the team. Business Analysts serve a critical role in understanding the problem domain and digging into the root cause of the business need or the problem. Business Analysts have to adapt to the new process and understand not just the template of the artifacts that needs to be produced (Epics and User Stories) but the spirit of the agile methodology. This will help the team dynamics and will help avoid user stories written like functional requirements.

The following table tries to compare how the role of Business Analyst changes in an agile environment.

BA

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 current business needs, even if it requires updating them.
Often there is a wall between the BA/Business and the Development team. Agile BA/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 the business needs.
  Needs the ability to look at the big picture (with fewer details) but also needs the ability to break the big picture into smaller pieces, so that the development team can execute on it in two to three week intervals.
Focus on being very specific in the requirements (construed as inflexible) Leave room for negotiation (and be flexible) as long as the problem is solved.

 

Prabhu Sivakumar

Prabhu Sivakumar is a highly motivated thought leader with specializing in the Business Analysis, Product Management, Requirements Management, Business Process Improvement, Business Architecture and Project/Portfolio Management. With over fifteen years of experience in software development projects and products, Prabhu is well versed with the entire software lifecycle and has managed large cross functional teams delivering quality software. Prabhu has experience in both Agile and Waterfall methodology and has helped various organizations set up a repeatable requirements management process using requirements management tools. Prabhu excels in taking a business or a market need and breaking it down into manageable pieces creating a business or product road map which can be executed by a development team.

Prabhu is Pragmatic Marketing certified in Product Management and is also a Certified Scrum Product Owner. Prabhu is currently working as a Product Manager in the Technology division of ESPN.

Article source: http://feedproxy.google.com/~r/BusinessAnalystTimes-BusinessAnalysisHome/~3/gi6ZHS-4ZLY/business-analyst-and-the-agile-business-analyst.html

Comments

Powered by Facebook Comments

Leave a Reply

Your email address will not be published. Required fields are marked *