The Business Analyst Role in Agile Software Development

As companies transition to Agile and Scrum to manage their software development projects, how does this affect the work of business analysts? Nancy Nee, VP Global Product Strategy at ESI International, shares her opinion on the role of business analysts in Agile software development projects and how this approach impacts the requirement gathering activity. She also provides some input on how to handle conflict between stakeholders.

Question: What is the role of a business analyst when a company adopts Agile approaches?
Answer: The role of the business analyst is much the same on an Agile project as it would be on a Waterfall project. The business analyst is still the point person to help develop and manage requirements. In an Agile project, business analyst’s role is to work with the product owner to help define the priority of the backlog, pushing those items forward on the schedule that will bring the customer the greatest value. Product owners make decisions about what the backlog is and which items should be developed first. This in turn helps the business analyst know which requirements (user stories) to further detail out for that iteration. The business analyst’s focus should be on eliciting and analyzing user stories, allowing for better prioritization of the product backlog. Business analysts will increasingly understand that successful user stories rely heavily on what they already know about requirements management and development (RMD). The business analyst’s RMD skills will be the foundation for successful Agile projects.

Question: What do you think about the business analyst taking the role of the product owner in a Scrum team?
Answer: The business analyst taking on the role of the product owner in a Scrum team is a common question in the business analyst community. The product owner is responsible for maintaining the backlog and priority of the backlog, thus, the Product Owner should have the business analysis competencies to this. To have a true business analyst step into the role of product owner will be difficult because the responsibility/accountability of a product owner is to represent the business and have the authority to make the decisions that will affect the business and that particular product. Typically, a business analyst does not have this decision-making authority.

Question: The availability of qualified customers to define requirements has always been an issue for software development projects. Does the product owner role solve this issue? What to do when there is a “noncompetent” product owner? What to do when there is limited availability of the product owner?
Answer: The product owner role is a critical piece to define requirements. The role of business analyst is needed to work jointly with the Product Owner to resolve the issue of unclear requirements. As stated in a previous answer, in an Agile project, the business analyst’s role is to work with the product owner to help define the priority of the backlog, pushing those items forward on the schedule that will bring the customer the greatest value. Product owners make decisions about what the backlog is and which items should be developed first. Value defined by the Product Owner, as the customer, is the main focal point of the role of Product Owner. The Product Owner must be someone from the organization that has the authority to make decision on behalf of the impacted business area, in order to realize the value of Agile as well as the business objective. A “noncompetent” Product Owner could be the sign that he/she does not have the authority to make the necessary business decisions or it could be an indication that the chosen Product Owner needs some training to understand their role on an Agile project. For Agile to be successful, the Product Owner must have this authority as well as availability to be accessible to the Agile project team 100% of the time. In many cases, the Product Owner is an active, full time member of the Agile team.

Question: How do you consider the requirement formats in the context of Agile short iterations and frequent releases?
Answer: In Agile, note cards are typically used to capture user stories that allow for the conversation to happen so that the team can better understand the Product Owners needs as well as a confirmation which shows the intent of the story and the validation tests that will confirm to the user that the story, when delivered, does what it is expected to do. This typically starts off the requirements process. In Agile, there are four levels of requirements. Themes or Epics are used to describe a larger piece of requirements that may include multiple features within it. Features are a collection of related stories. These two levels offer a great opportunity to use use cases because they can provide a simple visual representation of the product scope and allow for improved prioritization of the requirements. The other two levels are a bit more detailed and are known as Epic and Story. Epic is used to describe a Story that is too big to get done within an iteration/sprint and needs to be broken down into smaller chunks. Finally, Story is the smallest valuable business requirement.

Question: Can requirements techniques like UML diagrams still be used in Agile projects or if note cards are “enough”?
Answer: Use Case Diagrams, Models, UML diagrams, etc. are still necessary in Agile projects. You will typically see that “traditional” requirement analysis techniques are used at the level of Theme/Epic and Feature. These two levels offer a great opportunity to use use cases because they can provide a simple visual representation of the product scope and allow for improved prioritization of the requirements.

Question: For some systems, there are multiple and conflicting stakeholders trying to influence the requirements. For a mortgage system, front office people might want to request fewer information as possible to get quickly an answer to the customers and back office people wants more information to assess the credit risk. What would you advice a project do in this case?
Answer: In this particular example, it is important that the product owner to help define the priority of the backlog, pushing those items forward on the schedule that will bring the customer the greatest value. In the mortgage system, what are we trying to address as the need that brings the most value to the customer which in this case is not the front office people or the back office people, but their patrons or customers? Being to answer this question of ultimate end user/customer value, will help focus discuss and begin to bring the front office and back office people closer together on what is truly needed to achieve this value. In Agile, the focus on requirements is more about collaboration and converging. The goal of Agile is to deliver a workable, usable product every four to six weeks. This goal weights heavily on the role of the business analyst to help identify the “what” that the product owner needs, its value, and its priority. Consensus-driven approaches to RMD take longer and often do not achieve what the customer really wants which typically would happen with the front office and back office people’s needs. Accordingly, Business analysts need to focus on elicitation skills that are based on collaboration and convergence of requirements to deliver working products on a regular basis.

Biography: Nancy Y. Nee, PMP, PMI-ACP, CBAP, CSM, Vice President, Global Product Strategy, ESI International, guides clients in the development and implementation of learning programs customized to their specific needs. Her solutions reflect the insight of almost two decades of PM and business analyst experience in healthcare, information technology, financial services and energy. www.esi-intl.com