3: Why Your Team Needs an Agile Business Analyst
The role of the traditional business analyst on an Agile
project team is, however, not as straightforward as the roles
previously described. With technical writers and trainers,
the timing of their involvement and their outputs may
differ in an Agile project, but their function remains
essentially the same as in traditional projects. Conversely,
for business analysts to be valuable members of an Agile
team, their role must shift from traditional business
analysis to Agile business analysis.
The emergence of the Agile business analyst
If you ask anyone who has worked on a traditional IT
project what the role of the business analyst is, they will
most likely tell you they are responsible for analyzing user
requirements and for writing the detailed functional
specifications used for development work. The traditional
business analyst is seen to be a key resource in the
'requirements phase' of the project, undertaking a range of
analysis and documentation activities, including:
requirements-gathering activities (stakeholder
interviews, workshops, legacy system reviews)
specification documentation, and
specification sign-off.
All of these activities usually occur before development
work is allowed to begin and, in some cases, may take
several months to complete. On a traditional project,
developers are generally put in a 'holding pattern' awaiting
the delivery of signed-off specification documentation by
the business analysts.
During the 'development phase' of the project, the
traditional business analyst may also be involved in
updating the specifications to include further detail to
3: Why Your Team Needs an Agile Business Analyst
clarify technical or business-driven changes to the
originally agreed requirements.
As traditional business analysts tend to have an intimate
knowledge of the functional specifications, they can also be
involved in the system testing, technical writing, and
training activities at the end of a traditional IT project.
There are other roles the business analyst may serve in
support of traditional IT projects (e.g. business case
development, assistance in funding submissions) and
other work they may do independent of the software
development (e.g. business process reengineering) but the
typical image of a traditional IT business analyst is the
person who hands the development team piles of
specification documentation, and then works with them to
interpret what it all means.
In an Agile project, there is no need to create piles of
upfront documentation, as the business users work directly
with the Agile developers to identify and clarify their
requirements, generally through face-to-face meetings and
hands-on review of the software in progress. This creates a
direct line of communication between the business users
who know what they need, and the developers who know
how to deliver their requirements in the most technically
achievable way.
Equally, there is no need for a business analyst to clarify
specifications as part of the development work. Any
questions the developers have can be answered directly by
the business user as part of their review sessions and, where
appropriate, through ad hoc phone calls and e-mails.
On occasion, the Agile team may even get the benefit of
having the business user co-located with the developers,

Get The Power of the Agile Business Analyst: 30 Surprising Ways a Business Analyst Can Add Value to Your Agile Development Team now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.