Have you heard of agile business analyst? Does this even make sense? Agile is to move quickly. How can a business analyst move quickly when (s)he is loaded with effort of understanding the scope, collecting, analyzing, and defining requirements, convincing and negotiating with stakeholders, make a technical team understand the requirements and ensure delivery as committed?
This seems to be an absurd idea. In some organization, a role of the business analyst is being merged with a role of 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: Catch, Transform, Develop/Test, 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 has 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 project/product and the relationship with technical team ensures the delivery as committed. This bridge is being burnt in agile cycle. Only the catch and dispatch process are being transferred over to the product owner. In a tight, agile cycle, there isn't much room for analysis. A course correction is preferred over analysis of a requirement.
What happens when a product owner catches the requirement and dispatches it to the technical team without appropriate business and 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 agile cycle provided this cost?
Project deviation provides a way for newer possibilities, scope change gives 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 way to improved end delivery.
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 free success:
Agile business analyst can catch requirements in logical order
A business analyst can consider requirement based on impact, priority and urgency. This ensures minimal back and forth conversation and traversing in the right direction up front. 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.
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 analyst.
Agile business analyst ensures expected outcomes to deliver
Delivery defects are reduced with correct requirements, expected outcomes and robust testing. To ensure expected outcome, the delivery process needs to be flawless. Every requirement is defined by user stories which provides an acceptance criterion. Acceptance criteria is a minimum viable outcome which aligns to 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 up front.
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.
Author: Nimil Parikh
Nimil Parikh is a new generation business analyst with experience improving processes and services at 2 Fortune 100 companies. He has helped users' company-wide to improve workflows and reduce costs by millions of dollar.
He adds value by his ability to context switch while providing cross-functional business solution and ensuring timely delivery by managing and streamlining business processes and driving strategic leadership. He is known to introduce IT business transformation and ensure successful implementation.
Nimil possess MBA from San Jose State university, MBA Marketing and Information technology engineering from India. Nimil lives in Campbell, California. He enjoys challenges and believes in making things right. Reach him via email – [email protected]