The Agile Business Analyst plays a key role in facilitating conversations between stakeholders, quality assurance / testing teams, customers, subject matter experts (SMEs) and software developers in an incremental, iterative fast-paced product development environment.
So, who is the Agile Business Analyst and why should business analysts who are already comfortable with the process of eliciting requirements in a traditional product development environment be concerned about becoming more agile?
Introducing The Agile Business Analyst Role
The Agile Business Analyst’s role includes facilitating communication, reducing the reliance on extensive documentation and reducing the length of the feedback loop in product development projects.
Collaborative – The Agile Business Analyst works closely with software developers, stakeholders, project managers and software testers and relies less on comprehensive requirements documentation at the inception of the project.
Flexible and Adaptable – Unlike a more traditional software development project, an agile business analyst expects and welcomes changes in requirements. Being Agile means that changing requirements is not made difficult because of extensive documentation, communication cycles or change management processes.
Just In Time Requirements – An Agile Business Analyst knows what is the right amount of requirements documentation to gather for a development cycle or iteration.
More Face to Face Meetings – Because the Agile Business Analyst focuses on less documentation and more face to face meetings or interviews with stakeholders, software developers or testers, Agile Business Analysts make use of more User Stories and less Use Cases for documenting requirements.
Iterative Development – And unlike requirements management practiced in a traditional waterfall software development life cycle, the agile business analyst only focuses on gathering, analyzing or validating the requirements needed in each iteration.
Between The Agile Business Analyst and Traditional BA
So, the Agile Business Analyst focuses on the deliverables for each iteration to o facilitate a faster development process.
Another key difference with agile business analysts is that they work with software testers or quality assurance professionals to elicit Test Cases directly from User Stories instead of from Use Cases.
Because Agile Business Analysts rely on face to face meetings and in-person communication, they work better in teams where the developers, stakeholders, project managers and testers are located in the same place and are committed to being involved on a continuous basis through the life time of the project.
The Agile Business Analyst gathers just-in-time (JIT) requirements through intense collaboration with customers, customer advocates, software architects, stakeholders and software testers.
Why Are We Not More Agile?
Traditionally, a business analyst is expected to gather all the requirements for a project at the beginning. These requirements are then shared with the Project Manager and Stakeholders as a static, fixed or immutable set of requirements.
This type of requirements gathering is common in product or software development project that make any or all of the following assumptions:
Business Analyst – The business analyst can gather, analyze, validate and specify all the requirements at the beginning of the project and before a single line of code is written.
Project Manager – The project manager needs to have a complete set of requirements to facilitate accurate project planning.
Software Tester / QA – The software tester needs to have a complete set of requirements before creating a test plan and user acceptance or QA tests.
Software Architect – The software architect needs to design the entire software system at the beginning of the project befor e a line of code is written.
Computer Programmers – That computer programmers need to receive an extensive and complete set of requirements preferably in Use Cases format before they start coding.
Traditional software or product development projects also assume that for developers to create a working product, they need to be told in detail, every basic, alternate path and exception flow through the system.
Customers – That customers have a mind, wants, needs and desires that can be completely known at the beginning of the project through extensive requirements gathering and documentation.
This also means that once the customer’s requirements is gathered or documented, it will not change during the life cycle of the product or software development cycle … at least not without extensive negotiation, documentation and signing-off.
The Role of The Customer Advocate
But is this true? Can the customer’s mind, needs, wants or desires be known and documented completely at the beginning of the project?
Does setting the customer’s requirements in stone assure a better product, a more satisfied customer and increase the chances of project success?
The needs of today’s customers are not set in stone. Far from it, the very process of gathering customers requirements can change what the customer wants.
The marketplace is always changing and product features become less important or even irrelevant in short periods of time.
The practice of planning projects or designing entire software systems completely, at the inception of a project is fraught with risks, estimates and guesses.
This practice often leads to more software features that are out of touch with the customer’s needs and more project failures.
Considering that so many projects planned this way fail, Business Analysts need to consider utilizing more agile communication skills to supply requirements when they are needed.
Unlike the traditional business analyst who works from the assumption that requirements once signed off on are fixed in stone or immutable, the agile business analyst plays the role of a customer advocate by assuming that requirements can and will change during the life cycle of the product development effort.
The agile business analyst welcomes changes in the customer’s requirements because they reflect what the customer really wants and not what was documented.
In doing this, the agile business analyst elevates the customer’s needs above the needs for more documentation.
The agile business analyst understands that there is always some uncertainty in the marketplace, so the planned features of a product or software application cannot be set in stone!
The agile business analyst understand that software developers do not need to have 100% of a product or project’s requirements extensively documented using Use Cases before they begin coding.
So the Agile Business Analyst relies more on communication, presentation and facilitation skills than written documentation in communicating with software / product developers.
Today’s constantly changing marketplace requires the Agile Business Analyst A customer advocate who elevates the customer’s needs above that of extensive requirements documentation!