During the past few years there has been a trend developing in the software industry toward agile development processes. Unfortunately for the business analyst (BA), much of the literature regarding agile development focuses on the perspective of the developer, largely ignoring the role of the business analyst. BAs play a key role capturing requirements on large, software-intensive projects. Yet agile methodology emphasizes face-to-face communication over written documentation. Teams are co-located where programmers and their "customers" interact directly as a means of eliciting requirements. Organizations that are moving toward agile development may wonder if a has a role in agile software development. The answer, as addressed by this paper, is a resounding "Yes."
Business Analyst's Traditional Role
Having a BA on an agile team will complement the technical knowledge of the developers, reducing the risk that the team will only see one side of issues. When it comes to a software project, the typical BA has one foot in the systems world and one in the business process world. According to the International Institute of Business Analysts (IIBA), a business analyst focuses on the "set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems."[i] The solution is not simply a system solution but a holistic business solution, extending beyond the typical focus of a software developer. A BA is typically adept at working with business processes in the abstract rather than the concrete. His responsibility is to see the big picture, which includes the business context as well as the operation of the system. Developers, on the other hand, tend to view the operation of the system in terms of the concrete operation of the software. Their focus tends toward understanding how to make the specification operate in terms of software. [ii]
Advertisement
A BA's traditional tasks consist of determining functional and non-functional requirements using a variety of elicitation techniques, communicating requirements to business and technical people, estimating requirements, defining requirements attributes, prioritizing requirements, identifying and managing stakeholders, defining and reporting on metrics, managing the scope of requirements though base lining and change control, and ensuring that the requirements are validated. In order to perform these tasks, a BA has a different skill set from that of a developer. BAs must be good communicators who can interact with a varying audience. They must be able to communicate in the language of the business - at a level equal to the stakeholder - and they must be able to understand and use technical terms when communicating with the development side of the team. The BA must have strong negotiating, presentation, and writing skills. This skill set is not common among software developers. BAs on an agile development team complement and extend the skills typically found in development teams.
Customer on Agile Teams
Agile development doesn't happen without support from customers. According to Vinekar, "using an agile approach entails formidable responsibilities on the client's part" where the customer will have a hand in "identifying and prioritizing features and continuous, active, collaboration throughout the development."[iii] A successful agile team requires the right customer with a combination of aptitude and ability and a team that is willing and able to work closely with the on-site customers. If more than one on-site customer is needed, each customer's vision must be aligned to represent the same ultimate vision. If any of these points are not true, the agile development project may experience significant difficulty. A highly knowledgeable customer will be in demand from the operations side of the business and from the agile team. There is a great temptation within the business to pull an expert customer from a development project in order to address operational issues, often times leaving a junior, less knowledgeable (and presumably more expendable) customer representative on the team.[iv]
The BA can help in two ways: by reducing the workload on the expert customer and by acting as a mentor for junior customers. The knowledge and skill set of the BA includes techniques for eliciting requirements. This can ultimately reduce time constraints by efficiently eliciting requirements and guiding the expert customer. For example, the BA can use storyboards for visually-oriented customers, interviews when requirements are complex, and either focus groups or requirements workshops when several customers are involved. A typical BA is skilled at a variety of elicitation techniques. The BA can help train the junior customer to specify good requirements, aiding him to understand the context of the requirements and the ramifications of the requirements. Ultimately, the BA can act as a liaison between the junior on-site customer and the experienced subject matter expert, helping the junior customer to learn more about the product and be effective in specifying requirements.
Getting the Requirements Right and Getting the Right Requirements
BAs specialize in requirements and have the skills to ensure quality; namely that the requirements are complete, correct, feasible, necessary, and unambiguous. BAs are also trained in evaluating the impact of requirements changes. Both of these skills are increasingly important in agile development where face-to-face conversation is the preferred means of communication and requirements are expected to change.
Requirements serve as an understanding of what should be created not only from the perspective of the requirements consumer (the developer) but also from the perspective of the provider (the on-site customer). A close relationship between the on-site customer and development makes formal, written documentation unnecessary in agile development, especially since requirements are expected to change. The customer is assumed to be available to ensure the correct interpretation of the requirements, so detailed documentation doesn't add enough value to the bottom line product to be worthwhile.
Face-to-face communication may be the fastest mechanism, but verbal communication is notoriously imprecise and prone to both interpretation and change. Often, customers specify requirements and do not appreciate the impact of what they've said will have on the ultimate solution. It is not uncommon for customers to miss the interplay between requirements and specify new requirements that conflict with other aspects of the system. Certain requirements are critical in that they have a significant impact to the operation of the entire system - any changes to these types of requirements would ripple through the system. These requirements must be documented so as to reduce any misunderstanding or assumption. BAs have the technical writing skills to document requirements, using both text and diagrams. More importantly, they are experienced in identifying and tracking the relationships of requirements to business objectives.
Aside from helping customers appreciate the impact of their requirements, BAs typically have the skills to develop visual models. Several methodologies, including the IBM Rational Unified Process (RUP), suggest maximizing visual models of requirements since visual models are easily changed, are absorbed faster than text, can be more precise than text, and are quicker to develop. When it comes to documenting requirements, both textually and visually, BAs can greatly help the effort by aiding the customer with correct quality specification or requirements.
As an example, a given customer may be very well versed in the current system, so well versed in fact that he has difficulty explaining the operation and requirements of the system in terms that a non-expert can understand. The BA can help in such a situation by collecting a glossary, developing good definitions, and graphically depicting the operation of the system. The BA can act as a sort of translator, putting the requirements in terms that the agile team can better understand.
Multiple Customers
Frequently, the stakeholders and on-site customers are different people. It is impractical to have all stakeholders on-site as part of the development effort. The BA can act as a coordinator, working with the stakeholders to understand their vision and assisting the on-site customers during requirements specification to ensure that the requirements do not conflict with the stakeholders' vision. The BA can also act as a coordinator when more than one customer is involved in the project. Projects can fail if the on-site customer who is specifying the requirements doesn't have a good understanding of the ultimate project vision. The original extreme programming project (C3) went over budget and was cancelled precisely because the requirements specified by the on-site customer prevented the team from moving toward the stakeholders' "big picture."[v] In such cases, it is the BA's responsibility to keep the project aligned with the overall vision by coordinating both aspects of the development effort though meetings and documentation, making sure that the requirements are on target with the vision.
Aside from on-site customers being aligned with the overall vision, there are a number of situations where multiple customers must be engaged in an agile project, complicating the project even further. Agile development teams should be small, around ten people. Larger projects often require multiple teams of agile developers working on the same product for multiple iterations and each team would necessarily have a different on-site customer. A complex product may also require multiple specialist customers. In either case, multiple customers must all share the same common vision and goals. Coordination will ensure that each is providing specifications that are synchronized. Engaging BAs as business savvy coordinators makes sense in such a situation and is aligned with the skill set of BAs.
Summary
Teams that are practicing agile development would do well to engage business analysts. Due to the collaborative nature of agile development, the BA's skill in seeing both the business and system perspectives of the product can be vital to the success of an agile development effort. Including a BA who can act as a liaison, facilitator, and documentation specialist on an agile team will complement the developers and help reduce the risks found on teams with homogenous skills.
As a liaison between the on-site customer and the development staff, the BA can speak the language of both the business and the system and can aid in gauging the technical feasibility of the business needs, ensuring that the development team sees the larger business context. A business analyst can help both parties see incompatibilities of a requirement from the technical or business perspective and take advantage of reengineering the business processes to make the software more efficient.
As a facilitator, the BA can coordinate multiple customers. The business analyst can serve as the point of expertise for multiple projects, attending requirements specification and product demonstration sessions for each of the customers.
As a documentation specialist, the BA can ensure that the impact of a requirements change is understood. The BA can also use visual modeling to help specify the system with greater accuracy than either textual or oral documentation.
The responsibilities of the BA do not change dramatically with agile development, only the formality of the BA's work. The BA can still be responsible for functional and non-functional requirements, clearly communicating and managing requirements. The BA can still be active in identifying and managing stakeholders, managing scope of requirements, and ensuring that the product matches the requirements and achieves business objectives.
About the Authors Dr. Charles Suscheck is a principal consultant with Cardinal Solutions Group, a consultancy focusing on software development, software process, and requirements management. He specializes in agile software development methodologies and business modeling with nearly 25 years of professional experience in information technology. Dr. Suscheck has held positions of Process Architect, Director of Research, Principle Consultant, and Professional Trainer at some of the most recognized companies in America. He has published numerous articles and spoken on topics of interest to the business analysis community at national and international conferences such as OOPSLA, ECOOP, and Borcon.
Michael York is co-founder and Executive Vice President of Cardinal Solutions Group, an IT consulting firm with more than 200 professionals in Cincinnati, Columbus, Charlotte and Raleigh, NC. Since starting Cardinal Solutions with Kelly Conway in 1996, Mr. York has focused on the development of Cardinal Solutions' software delivery capabilities and business development. Previously, Mr. York was one of the co-founders of PCS Technologies, a software development firm established in 1985 that specialized in distribution management systems for large consumer retail companies. PCS was acquired by Retek in 1995 (Oracle acquired Retek in 2005).
[i] International Institute of Business Analysts, Business Analysts Body of Knowledge 1.6, 2006 accessed on 10/1/07 from http://www.theiiba.org
[ii] Weinberg G. The Psychology of Computer Programming, Dorset House Publishing Company, 1998.
[iii] Vinekar V, Slinkman CW, and Nerur S. Can Agile and Traditional Systems Development Approaches Coexist? Information Systems Management 2006; 23(3), pp. 31-42.
[iv] Stephens M, Rosenberg D. Extreme Programming Refactored: The Case Against XP, Apress, 2005.
Having practiced Agile for the last 3 years, I have seen that the needs for an "external" BA depends on the type of company. Typically a product company is averse to external BAs - while non product companies frequently face the dearth of qualified resoruces to take up the challenges of becoming a Product Owner. In these cases having the external BA is absolutely critical for success.
I have also observed that documentation is very important - working software is not only about software which works - but more about software which can be used. Which means users will need to be trained, ops will need to be managed, etc. In most cases the scrum team is not the best qualified to address these needs. The BA (if present) acts as an effective bridge to "external" resources who can focus on the job of documentation.
1
January 19, 2008
Bruce Maples: ...
A true BA is not the same as an SA. A Business Analyst should know, in detail and at their fingertips, all the domain knowledge and process knowledge for their business area. If their business area is willing to also empower the BA to make decisions for the area within a given software project, then the BA would make an excellent Product Owner. I don't think the knowledge and history would be the block; I think it would be the delegation of authority.
2
November 29, 2007
Steven Gordon: ...
BAs turning their understanding into documents only inhibits the interactions that make agile work. It also does no good for business analysts to understand the requirements on behalf of the development team, so either 1. the BA has to become an integral part of the development team on a daily basis so that their understanding is fully shared with the team on a real time basis, or 2. the BA has to become an integral part of the customer team so that they can fill the role of on-site customer effectively (i.e., Scrum's Product Owner).
Under case 1 above, the BA needs to pick up some kind of development skills (usually testing) in order to be integrated well enough into the development team that their domain knowledge gets shared. Occasionally, I have seen a BA function well as the "Scrum Master". Having the BA write the user documentation can work if there is enough user documentation to justify it and they can do that work in the team room instead of isolated in a cubicle.
Under case 2 above, the BA needs to be given the authority to make product decisions, especially prioritizations. If the BA has to go verify every decision with the customers, then they are just a conduit that limits communication bandwidth between developers and customers. On the other hand, the BA also has to spend enough time directly interacting with customers to be sure to keep up with changing needs in the real world.
Articles 
During the past few years there has been a trend developing in the software industry toward agile development processes. Unfortunately for the business analyst (BA), much of the literature regarding agile development focuses on the perspective of the developer, largely ignoring the role of the business analyst. BAs play a key role capturing requirements on large, software-intensive projects. Yet agile methodology emphasizes face-to-face communication over written documentation. Teams are co-located where programmers and their "customers" interact directly as a means of eliciting requirements. Organizations that are moving toward agile development may wonder if a has a role in agile software development. The answer, as addressed by this paper, is a resounding "Yes."
