This is the final post in my review of the impact of Agile on the tasks within the knowledge areas of the BABOK®. There are some interesting findings from this exercise. The implications are that while some business analysis tasks are performed within the development team, the business analyst role itself is more strategic and challenging on agile projects. A clear understanding of the BABOK tasks and how they should be addressed on Agile projects will dramatically increase your ability to deliver value through Agile projects.
So, What’s New?
First off, the business analysis tasks are not just aimed at documenting requirements. There are three primary targets of analysis activities. Many tasks address the features of the product. These are aimed ensuring requirements are elicited, communicated, and the solution is verified. There are business analysis tasks aimed at understanding organizational readiness and transition requirements. Finally, there are business analysis tasks aimed at understanding and improving the ability of the organization to develop and deliver the solution.
Secondly, all the tasks are still necessary. However, unlike a traditional project, where many of the analysis tasks are performed up front, they are performed continuously throughout the project. The requirements for the solution, the ability to deliver, and the readiness of the organization are evaluated incrementally throughout the project and the approach is adapted to improve fit and performance.
Finally, the understanding of requirements, organizational readiness, and development capabilities is progressively elaborated throughout the project. In Agile, the development team itself performs detailed business analysis activities within the development iterations. The business analyst continues to operate in front of and after the development efforts. Lightweight requirements documentation combined with an emerging understanding means the business analyst become an advocate for the product. They collaborate with the team to ensure a shared understanding unfolds. The business analyst also facilitates the understanding and implementation of improvements in the business analysis and organizational readiness processes.
Summary of Business Analysis Knowledge Areas
Business Analysis Planning and Monitoring. The tasks in this knowledge area are still primarily performed on the front end. The team will agree on the approach it will take in business analysis tasks. This means agreeing on who and how. All the task purposes in the BABOK still need to be planned – but planned to support the cadence of the team and the emergence of understanding through the project. The way the business analysis tasks are performed are not cast in stone, they will be updated through inspection and adaptation throughout the life of the project.
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.
Requirements Management and Communication. The existence of Requirements Management and Communication in a single Knowledge Area demonstrates the closely held traditional belief that documenting and tracking something is the best way to communicate it. It is important that the method of documenting requirements at the higher level is lightweight while still facilitating understanding, focus and priority. In Agile projects, communication should be viewed as completely distinct tasks. At the detailed levels, there is a transfer of context, purposes, and outcomes requirements that is best performed through conversation between the customer and the development team.
Enterprise Analysis. The business analyst will still carry primary responsibility for understanding organizational readiness, transition requirements, and solution verification. They will need to communicate findings from releases back into transition requirements to improve release performance. Gaps in the fit of the solution will feed back into the requirements backlog. Enterprise Analysis is very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value.
Solution Assessment and Validation. These tasks happen continuously in a progressive fashion. The Big Solution Architecture will still be developed with input from the Business Analyst as well as Architects. The Business Analyst will need to understand and address the impact that progressive elaboration has on the transition requirements.
Requirements Analysis. Prioritization and organization of requirements happens as part of backlog prioritization. The business analyst should make sure that business value concerns and risks associated with assumptions and constraints are clearly understood here. Like Enterprise Analysis these tasks are very strategic, often outside the scope of the typical Agile development team (presumed to be understood by the Product Owner), and are critical to the team’s ability to burn down risk early and get to business value fast.
Missing Tasks
I believe there are at least three areas regarding business analysis on Agile projects that are not addressed by the BABOK.
Enrolling Stakeholders involves making sure everyone understands how they will participate. Just documenting a process or developing some templates don’t ensure appropriate engagement. Stakeholders may play a role making sure shared understanding of the product requirements exists, they may be responsible for development process feedback, or they may need to participate in the transition of the solution.
Understanding Requirements is the new task or set of tasks that deal with generating the shared understanding of context, purpose, and outcome that is necessary for successful projects. Since the understanding of what is being developed and how it is being developed will emerge over the course of the project specific tasks must be in place to establish this shared understanding. This may sound like a subtle extension of communicate requirements but this is social in nature and is fundamentally different than the push of communicating requirements.
Organizational Learning extends Enterprise Analysis. Not only does the readiness of the organization to use the product need to be reviewed, the ability to develop, deliver, and support the product needs to be evaluated. This task includes the introspection, retrospectives, operations reviews, and outside review of best practices that the organization performs to improve its ability to use and deliver solutions.
Agile Business Analysis Summary
The common concept that Business Analyst’s add no value to Agile projects is flawed. It is true that some of the detailed business analysis activities will be best served through direct interaction between developer’s and the customer. The high level planning and coordination around these direct interactions should not be abandoned but should be managed to facilitate focus on business value and shared understanding while minimizing transaction costs.
Additionally, there are many critical business analysis tasks outside the scope of the development team. Particularly, the tasks involving Solution Validation, Enterprise Analysis, and the inputs to Requirements Analysis are very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value. A clear understanding of the tasks and purposes in the BABOK® demonstrates the strategic nature of Business Analysis tasks, highlights where the tasks should be performed within the Agile development team, and will increase the ability of the development team to achieve its objective of rapid delivery customer value.