The Agile Business Analyst, A Customer Advocate?

Part 12 of 20 in the Series: How To Become A Business Analyst
The Agile Business Analyst

The Agile Business Analyst

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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:

  1. 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.

  2. Project Manager – The project manager needs to have a complete set of requirements to facilitate accurate project planning.

  3. 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.

  4. 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.

  5. 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.

  6. 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?

  1. 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.

  2. The marketplace is always changing and product features become less important or even irrelevant in short periods of time.

  3. 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!




6 Discussions for “The Agile Business Analyst, A Customer Advocate?”

  1. Daniel

    Thanks Kingsley,

    this is really impressive and progressive stuff.

    I like it!

  2. Scope in Agile / Iterative Projects is defined keeping in mind that requirements may change and are not set in stone and that on-going converations are required to validate the requirements, scope and deliverables of the project.

    You will depend more on collaboration with customers and stakeholders and feedback that you get.

    You will loosely define the requirements in User Stories at a very high level. Then you will collaborate / discuss with the customers / stakeholders to fill in the details that are relevant to each Iteration.

    What has your practice been and what has been working for you?

    • laith obeidat

      to be honest i feel a little bit confused what i am practicing exactly, as i told you before i feel i am working using both methodoligies!!
      here is how do i work:
      1- we define the project scope in a high level (in this phase the project cost and time is determined).
      2- we start gathering the detailed requirements document of all the modules defined in the scope document to obtain approval from the client.
      3- after the approval we start the developmant phase.
      4- during the development the client could ask for changes; if its within the scope we do it, otherwise we consider as an out of scope issue we ask for an extra cost or time.

      in my opinion every single detail should be gathered from the client and documented to let him involved in the development process, and also i work closley with the project manager, Technical team leader and QA, to obtain an internal approval on the requirements document. my reservation regarding the agile methodolgy, why to gather each module seperately while i could do that once (in the planing phase), because out of my experience i found that sitting with the clients alot will put you on endless loop to come up with an agreed requirements :S

      i would like to hear if i am working correctly and what is your opinion about my concern ??

      • Agile Project Scope determination in #1 step is OK.

        #2 step may need a closer examination. You should be focusing on the detailed requirements only the prioritized issues for the current iteration.

        #3 the approval process may need to be changed to become more of deciding which features go into what iterations.

        Your disapproval with the Agile Process is based on the rational for gathering detailed requirements on an iterative business.

        Agile Projects adopt this, so that all th attention / focus goes into writing code / software which the customer gets to see and then provide input / feedback which is incorporated into the next project.

        So, you have a continuous feedback loop built into the process and your customer gets to having an early working build

        • laith obeidat

          thanx for your quick replay :D

          well, as i understood from above gathering requirements shall be as follows using Agile process:
          1- specify iterations.
          2- specify features priority (of the selected iteration).
          3- gather detailed requirements of the high priority features.

          the follwoing questions occur:
          1- when to start gathering the requirements of the low priority features?
          2- why to focus on coding while we could build a prototype using other some tools (such as visio, snapshots, wirframe) which will take less time than coding and got client’s feedback?

          thanx alot for your cooperation :D

  3. laith obeidat

    i guess we can’t be as BAs to be more agile or more traditional, for me i guess i am working between the two methodoligies depending on the clients needs.

    but i have an important question in my opinion, how do we define the project scope using the agile methodolgy ??

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Newsletter

Article Series

Other Posts In Series

Spotlight

  1. Exacticity Incorporated
    2977 HIGHWAY K
    SUITE 222
    O'FALLON, MO 63368
    UNITED STATES

  2. Toll Free: 1-(866)-385-0190

Log in /