4: What are the Risks of Not Having an Agile Business
Analyst?
71
The danger of the unquestioned business user
Direct engagement between the Agile team and the business
users
When business users are presented with the opportunity to
create a new system or to replace an existing one there
is a tendency for them to see the solution as their one great
chance to make their work easier, to improve efficiency, to
correct all of the previous wrongs that have historically
impacted their business area. This opportunity can create a
strong sense of enthusiasm for the project among the
business users, as well as excitement for all of the potential
that a new solution can provide. In some respects, their
eagerness to identify the capabilities of the new solution is
a very positive thing, as this means the business users are
likely to put in enormous amounts of effort in support of the
project. There is, however, an equivalent risk of the
business users reverting to a 'kid in a candy shop' mentality,
making the specifications for the proposed system an
unfettered wish list of everything they could possibly
imagine.
Agile approaches endeavor to address the potential of
business users coming to the table with an 'all and sundry'
capabilities list by requiring them to assign priorities to all
of the requested features. The intention of this approach is
not to unduly restrict the business users from considering
the full scope of solution capabilities; it is intended to force
the business users to think critically about the capabilities
they are requesting, and to identify which of these
capabilities will provide the organization with the greatest
business value. The resulting list of prioritized features is
what drives the decision of what the Agile development
team will focus on in each iteration, and shapes the scope of
4: What are the Risks of Not Having an Agile Business
Analyst?
72
high-priority capabilities the solution overall will deliver.
When business users are left to make these priority
decisions on their own, however, the outcomes may not
reflect what the business truly needs in the solution.
As one example, consider a situation where the business
users have requested the Agile development team build an
online application form that will allow organizations to
nominate themselves for an industry award. The business
users detail the requested features of the online form, such
as:
the 55 information fields applicants need to fill in,
including the preferred order and layout of the fields
the subset of 32 fields that are mandatory
the business rules for the calculation fields
the selection values for the drop-down lists
the help text that should appear on the screen, next to
each field
the instructions and due dates for the organizations to
send their application fee checks through the mail.
In the requirements review session, the requested form
capability is described by the business users in a few high-
level user stories, for example:
As an award applicant, I want to be able to submit my
application form online so I can fill it in more easily and be sure
all of the information is correctly provided.
As an award application processor, I want the information
submitted in the application forms to be complete and accurate
so I can easily add them to the application processing system.
As an award application processor, I want the system to
automatically calculate the required application payment amount

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

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