The Information Technology (IT) industry does not have a
standard definition for 'business analyst' that applies to all
software projects. The role of the business analyst has
historically ranged from writing business cases, to detailing
system specifications, to testing and documenting the
developed solution, and doing everything in between. With
so much variation in the definition of the role of the
business analyst, it is not at all surprising that people can
misinterpret and underestimate the value that a business
analyst can bring to an Agile project.
This section identifies why the perception of business
analysts needs to break away from their roles on traditional
waterfall project teams, and focus instead on the value that
skilled business analysts bring to Agile teams.
Is pairing only for developers?
One of the primary strengths of Agile teams is that they are
multidisciplinary. Agile approaches forego the traditional
assignment of specific roles to each member of the team in
favor of having team members collaborate to achieve
whatever is most urgently required for the project, whether
it is:
designing the solution,
coding the features,
building the test cases,
or writing online help manuals for the users.
3: Why Your Team Needs an Agile Business Analyst
This collaborative approach is one of the core strengths of
Agile methodologies. It allows each team member to
achieve a more well-rounded understanding of the required
solution. It increases knowledge sharing and provides
greater flexibility for the team to focus resources on the
most critical activities. It enables teams to more readily
respond to unexpected staff leave with minimal impacts on
productivity. In essence, the multidisciplinary nature of
Agile teams enables all team members to be jointly
responsible for the delivery of a successful solution, not
just 'their part' of the solution.
It is for this reason that all Agile team members are called
'developers' instead of being assigned a title that constrains
them to delivering only one aspect of the solution (e.g.
'tester'). Included in this division of labor is the shared
responsibility of team members to work directly with the
business users to identify, apply, and refine their
requirements in the delivered software solution.
One example of this collaborative work is the requirements
identification and clarification process jointly undertaken
by the business users and the Agile development team in
the Scrum methodology. As noted in the previous section,
Scrum begins each project iteration (Sprint) with a sprint
planning meeting, where the Product Owner (the business
user), the ScrumMaster (the facilitator), and the entire
Scrum team (the developers) review the highest-priority
items identified by the Product Owner, estimate the amount
of work required for each feature, and agree on the subset
of features that will be included in the forthcoming sprint.
Prior to this session, the Product Owner will have prepared
the user stories and listed their requirements in top-down
priority order in the product backlog to focus the team (and
the discussion) on the most important features in the

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.