The Case for Business Analysts on Agile Projects

A key principle of Agile is that communication needs to be tight between the business and developers. Here is the principle as outlined in the Agile Manifesto:

Business people and developers must work together daily throughout the project.

I previously made the case for the importance of daily team interaction. For this article, I would like to explore the question of who exactly are the “business people” who must work daily with development? Is this every business stakeholder, or a single point of contact? Some Agile devotees would argue against a point of contact: “Get rid of the middleman and directly hook up developers with the business people who can answer their questions.” Others see the need for a point of contact, but argue that a business manager is fine; no need for a fancy business analyst to translate for them.

Based on what I have seen, there are a few aspects that are important to consider when selecting the business contact for your project:

• Requirements gathering experience – The average business manager doesn’t think in terms of system functionality, but rather in terms of business need, e.g. “I want to collect my customer’s data.” The average developer then translates these business needs into technical requirements, e.g. “I’ll need to persist a Customer object via Hibernate to database.” The functional requirements (the specific field definitions, validations, core scenarios, exception scenarios, function buttons, integration points, etc) are often glossed over (“Just tell me the fields you want on the screen and I’ll knock it out for you.”). Expecting the business to articulate business needs and functional requirements, or the developer to define functional and technical requirements, usually means that the functional requirements will be short-changed. Your business contact should be experienced in coordinating business requirements with the various business stakeholders, asking the right questions, and then synthesizing these into a cohesive functional design that the developers can use to create their technical designs.
• IT savvy – It is important for the business contact to have been involved in past software development projects. This enables them to draw from their experiences to help avoid potential landmines and to implement best practices.
• Accessibility – To keep things going full steam ahead in the right direction, the team needs timely answers as business questions arise. Too often, the key business contact has a day job in the organization and ends up as the bottleneck. I have seen instances where the business contact can continue performing certain tasks from their day job, but they really need to be sitting with the project team most of the time. Ideally, they should be dedicated to the project.
  

Based on these considerations, if your business manager or developer is up to the task of defining the functional requirements on top of their other responsibilities, then go for it. For smaller projects I've even seen a project manager / scrum master handle both the business analysis and the testing quite well. For more significant projects, however, it is best to bring on a skilled business analyst to serve as point person for the business. The project sponsor and other business stakeholders still play important roles in defining the business needs, reviewing the functional design decisions, engaging in user acceptance testing, and generally guiding the project. The main point is to ensure that the project team has a business contact with the IT savvy, requirements gathering expertise, and availability. This will ensure quality requirements, quick and consistent feedback, and will greatly enhance your odds of a successful project.