Role of Business Analyst

in Agile Process

(Professional Business Analyst Training

organisation)

Out of many roles on an Agile team - developer, tester,

project manager or product manager the role of the

business analyst is probably the one whose the team is

depend most frequently challenged.

The role of a BA is to gather the requirements and often

questioned, not the quality of work, but the “perceived”

value delivered for the team - by clients.

Frankly speaking I’ve had a few identity crisis since I started

working as an analyst on agile teams.

So what does the Agile Analyst bring to the team ?

I have noticed that when a project start with an

business analyst, there is a two biggest benefits to the

development teams have been there are...

Everyone on the team questions 'Why' including the customerMany seem to blindly believe that the business analysts' sole responsibility is to "write" stories.

It is true for business analysts. In the agile world, it is essential for the business analyst to talk to thestakeholders and establish communication mechanisms to understand why we are working on something before we develop it.

Traditional BA (Waterfall) Agile BA

Requirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules.

Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.

   

Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.

Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.

Focuses on getting a ‘sign off’ on the requirements.

Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them.

Often there is a wall between the BA/Business and the Development team.

Agile BA (Often called as Product Owner) is part of the team.

Tends to dictate solutions.Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.

Long turnaround. Quick turnaround.

Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document.

Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.

   

And it is as essential for the analyst to then foster a shared

understanding of this with the entire team. This two-way

communication flow between development and business.

On a distributed team of more than 20 people in the project of

retail client, our team wasn't understanding of the domain

as a whole and what the work we are doing.

Why it is required. As I have spent a good amount of time

to understanding the domain in the beginning I decided

to do 'lunch and learn' sessions to share my learning using

diagrams.

And actually It helped the team to clear the dots by

understanding where each story fits in.

As we continued to do this, we started to have valuable

conversations like 'this is why we need this story' as we

thinking more 'we have to create more stories in this area',

'finish the stories before the rest of the stories for this

feature' and so on.

The impact of such conversations put us to think what

values each story was bringing in.

Which in turn helps me to start the right conversations

with the business which feed in our team’s understanding

the value of each story.