This is a very early draft of some material that may appear in the introduction to version 2.0 of the BABOK. I'd like to know if this helps clarify how the BABOK's tasks and KAs apply to different lifecycles. We hope that puttting it in the introduction will help illustrate how the material in the BABOK applies to people in different circumstances. Other changes will be made through the text as well.

Agile methods will not be the only ones to recieve this treatment--others will include Waterfall, Iterative, BPM, Business Rules, and more.

Feedback is appreciated, although it will be even more appreciated if you let me know how effective the presentation is, and not just whether you think I've correctly described the Agile point of view (although comments on that are welcome too). Finally, in these sections I have chosen not to try and summarize the arguments for or against any given method or viewpoint, but simply rather to summarize the perspective practitioners of that method have.

Agile Development

Description

Agile development methods seek to:

• Promote rapid and frequent delivery of working software
• Accept and even encourage frequent change in requirements
• Empower team members to make decisions
• Encourage frequent feedback from business stakeholders to the project team
• Minimize the amount of documentation produced describing the solution

Agile lifecycles are predicated on the assumption that stakeholders cannot accurately determine the requirements of a large project up front. Requirements will be incorrect due to change in the organizational environment, change in the understanding of the problem, conflict between requirements, overplanning that leads to implementation of unnecessary features, and so forth. As a result they advocate an exploratory approach to determining requirements, with stakeholders continuously assessing the solution as delivered to date and prioritizing their immediate needs.

The Role of Business Analysis

There are two common approaches to the business analysis role in an agile environment:

• Product Owner: the Business Analyst serves as the member of the project team responsible for assessing and prioritizing all requirements.
• Dispersal: the business analysis role is owned by multiple stakeholders in the project, all of whom are responsible for providing requirements directly to the project team. A member of the project team will take responsibility for planning and management of requirements, and may coach stakeholders to assist them with defining requirements.

Knowledge Areas and Tasks

• Enterprise Analysis falls outside of the scope of most Agile lifecycles.
• Requirements Planning and Management focuses on the prioritization of requirements. Allocation is accomplished through selecting the highest-priority requirements that can be implemented in a single release.
• Requirements Elicitation is performed primarily through discussion with stakeholders and prototyping.
• Requirements Analysis identifies features/scenarios of interest for use in prioritization, and then fleshes those out when they become scheduled for implementation.
• Requirements Communication focuses on informal methods of presenting requirements to stakeholders and the project team. Documentation of requirements is only performed as needed (and may be selected by stakeholders like any other feature).
• Solution Assessment and Validation occurs continuously, as each new release is assessed against the business need and key improvements identified.