Have you heard of an agile business analyst? Does this even make sense? Agile is to move quickly. How can a business analyst (BA) move quickly when he is loaded with the effort of understanding the scope, analyzing, collecting, and defining requirements, negotiating and convincing with stakeholders, make a technical team to understand the requirements and ensure delivery as committed?
This seems to be an absurd idea. In some organizations, the role of the business analyst is being merged with the role of the product owner as they follow agile or agile-based hybrid SDLC. This change itself is detrimental to the organization. Don’t you agree?
Any SDLC follows 4 basic steps: Transform, Develop/Test, Catch, Deliver.
Not, every team member is required at every step of the process. However, in most cases, a project manager and a business analyst are among the few roles who have ownership over all 4 steps. Especially talking about a business analyst.
A business analyst is a relationship-oriented role. The relationship with business stakeholders defines the requirements of the product/project and the relationship with the technical team ensures the delivery as committed. This bridge is being burnt in the agile cycle. Only the catch and dispatch process is being transferred over to the product owner. In a tight, the agile cycle, there isn’t much room for analysis. The course correction is preferred for the over-analysis of requirements.
What happens when the product owner catches the requirements and dispatches it to the technical team without appropriate business and the technical analysis?
Project deviation, scope changes, requirement abrasion, lack of reference, and delivery defects are some of the major issues that a project faces while advancing with the product owner on an agile cycle. Quantification of these issues costs about 20-25% of the project budget. Isn’t that an important miss?
Why is it that companies are ready to move into the agile cycle that provided this cost?
Project deviation provides a way for newer possibilities, scope change gives the flexibility to adjust new requirements based on ever-changing business and its’ needs, requirement abrasion is considered as an opportunity to build new requirements, lack of reference provides a blank slate and delivery defects paves the way to improved end delivery.
The type of project determines the software development cycle it follows. Usually, a long term well-defined project with an expected outcome follows a waterfall/hybrid software development cycle while the project with non-structured scope, a long-term effort with ever-changing outcome adjusting to business, and its needs would follow an agile software development cycle.
Does this mean that an idea of agile business analyst a myth? Or can we not take the benefits of a business analyst in an agile cycle?
The idea here is to ensure that a business analyst brings in the expertise to an agile cycle. This is only possible via the concept of agile business analyst. Here are some of the ways in which your agile project can ensure a breach of free success:
An agile business analyst can catch requirements in a logical order.
A business analyst can consider requirements based on impact, priority, and urgency. This ensures minimal back and forth conversation and traversing in the right direction upfront. Catching accurate requirements is an important art of an agile business analyst. There’s no time to revisit requirement during the shorter development life cycle.
The agile business analyst can metamorphose requirements.
The requirements come in many forms. Not all requirements are critical. Some of them are noise. An agile business analyst dictates requirements in the right priority. They transform requirements into pieces of deliverable which is better understood by the delivery team. A product owner cannot perform metamorphoses of a requirement which is exclusively a skill set of agile business analysts.
Agile business analyst ensures expected outcomes to deliver
Delivery defects are reduced with correct requirements, expected outcomes, and robust testing. To ensure the expected outcome, the delivery process needs to be flawless. Every requirement is defined by user stories that provide an acceptance criterion.
Acceptance criteria is a minimum viable outcome that aligns with the expected outcome and can be considered as a part of the deliverable. An agile business analyst will ensure drafting right stories with acceptable criteria which defines a clear path for delivery upfront.
Agile business analyst develops a continuous delivery model
Agile business analyst has the capability to keep the wheel rolling. They’re a transformative funnel through which a requirement passes down to the delivery path towards an expected outcome. This SDLC machine needs continuous fuel in the form of well-defined and informed information which is provided by an agile business analyst. As long as an agile business analyst does the job, this machine will remain on its course to deliver greater solutions.
Coming to our original question, is an agile business analyst a myth or a reality? There is a clear answer. It is a reality if an organization realizes the value, but it is a myth for immature organizations whose processes are ill-defined and are nowhere on a path towards best practices.
