Description
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.
business analyst
in
agile process
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.
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
customer
Many 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 the
stakeholders and establish communication mechanisms
to understand why we are working on something before
we develop it.
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.
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.
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.
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 fe..ed in our team’s
understanding the value of each story.
doc_980238267.pptx
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.
business analyst
in
agile process
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.
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
customer
Many 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 the
stakeholders and establish communication mechanisms
to understand why we are working on something before
we develop it.
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.
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.
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.
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 fe..ed in our team’s
understanding the value of each story.
doc_980238267.pptx