Agile Business Analysis Elicitation
Today I am discussing the tasks from the BABOK associated with Eliciation. These are the tasks to Understand the underlying needs rather than stated or superficial desires. There are four tasks associated with Elicitation. Again, I show the BABOK® purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.
Task: Prepare for Elicitation
| Purpose | Agile Impact |
| Ensure all needed resources are organized and scheduled for conducting the elicitation activities. | Preparing for Elicitation changes during the life of the project. Early on, it is done by the Product Owner (Business Analyst) to coordinate supporting materials and schedule resources to define the high-level requirements. This is coordinated by the Business Analyst. As the project progress, work is coordinated by prioritization of the backlog. The customer will be pulled in to work directly with the developers on a frequent (daily) basis to elaborate requirements. This task requires the scheduling of resources and the coordination of inputs to align with the progressive elaboration of the backlog. |
Task: Conduct Elicitation Activity
| Purpose | Agile Impact |
| Meet with stakeholder(s) to elicit information regarding their needs. | Early on, Conduct Elicitation is performed by the Product Owner or Business Analyst to define high-level requirements. As the project progress, the customer interacts with the development team directly during iteration planning and even during development. At each step the requirements are further decomposed to smaller units of business value. Finally, the customer interacts with the developers on a frequent (daily) basis to elaborate the requirements. |
Task: Document Elicitation Results
| Purpose | Agile Impact |
| Record the information provided by stakeholders for use in analysis. | The amount of documentation is a key distinction between Agile and traditional efforts. Early on, the Business Analyst will document elicitation results at a high level – with enough detail to communicate intent and value. The results will be gathered into a backlog that will be developed in more detail as the project progresses. At the end, the developer may make changes during interaction with the customer that invalidates the documentation. One of the tenants of Agile is “Working software over comprehensive documentation.” The code becomes “self-documenting.” The team must decide how to reconcile the difference between historical documentation and the working product. |
Task: Confirm Elicitation Results
| Purpose | Agile Impact |
| Validate that the stated requirements expressed by the stakeholder match the stakeholder’s understanding of the problem and the stakeholder’s needs. | This happens by the Team during iteration planning , during the development iteration, and at Customer Acceptance. The customer may change her mind about some specific element of a story after they have seen the result. This feedback becomes an input into the conduct elicitation activity. |
Elicitation Agile Summary
All of the tasks in Elicitation are important on Agile projects. Again, the primary distinctions in this Knowledge area are planning for continuous engagement with the customer and the progressive elaboration of requirements. In the event that the enterprise has governance requirements or there are contractual obligation, the team will have to negotiate how they will deliver documentation that is sufficient to support the needs of the business.
Tags: Agile, Big Agile, Business Analysis
[...] Elicitation. This knowledge area occurs continuously in a progressive fashion and responsibility for the product requirements changes hands during each iteration. These hand-offs associated with the various levels of elicitation can contribute to lost knowledge and increased transaction costs. An approach that ensures continuity of understanding is critical. [...]