Business Analysis in an Agile World - IIBA | International Institute of B...
https://www.iiba.org/News-Events/Best-Practices-for-Better-Business-A...
Home
About IIBA
Membership
Newsletters
Chapters
BABOK Guide
Learning &
Certification &
Development
Recognition
Join
Careers
Quick Tips
Business Analysis in an Agile World
Best Practices for Better Business
Analysis™
Author: Tazeen Shaikh
Communities
Introduction
Events Calendar
IIBA in the News
News Releases
Volunteer
IIBA Merchandise
Follow us...
Renew
Contact
Help
My Profile
Log off
News &
Events
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life
believing that it is stupid." - Anonymous
Since an agile business analyst is a relatively new fish in the sea of agile development, the purpose
of this article is to describe the key elements of an agile environment and the capabilities required
for BAs in that environment. This article identifies what it means for an BA in a software
development environment to thrive in an agile context. This article also discusses leveraging the
BA's current capabilities to be relevant in an agile world, and also how to develop additional
capabilities.
The Relevance of a Business Analyst in an Agile World
What is the new form of a business analyst in an agile world? Will it transform to a new role in an
agile world or will it take the form of scrum masters and product owners? These questions arise
when the business analyst role is considered in the agile paradigm. My observations of agile
projects have led me to believe that BAs are needed, but there are unique skills that support agile
business analysis.
Key Skills of a Business Analyst in an Agile World
The key flavours of agile are:
continuously evolving clarity,
holding the context in a consistent manner,
building trusted teams, and
gauging documentation needs.
The role of a business analyst can be viewed from the perspective of the outcomes it achieves in
the software development process. To achieve these outcomes certain activities need to be
performed. Outcomes are the key results which need to be achieved and outputs are the key
activities which need to be performed in order to achieve the outcomes. The following diagram
depicts the outcomes and outputs needed from a business analyst in an agile world.
Figure 1: Outcomes and Outputs of an Agile Business Analyst
1 of 6
2014-05-27 10:19 AM
Business Analysis in an Agile World - IIBA | International Institute of B...
https://www.iiba.org/News-Events/Best-Practices-for-Better-Business-A...
Evolving Clarity
Every software development project is initiated based on the goal which needs to be achieved.
There is always a business value associated with implementing software. This business
value/benefit is arrived at during the business case creation phase. Against this business case a
monetary value is calculated. The business case in most scenarios also takes the form of multiple
software development projects to enhance the company's IT capabilities.
When a software project begins its discovery phase it is the responsibility of the business analyst to
constantly evolve clarity around the business value/benefits to be delivered. The benefits to the
business are elicited by the business analyst as 'demand stories’. These demand stories are further
broken down into epics and user stories. The business analyst constantly drives clarity by ensuring
the demand stories are realized into the epics and user stories thus ensuring business benefits.
Key decisions around scrum cycle priorities and user stories/feature list priorities need to be arrived
at by driving clarity of the business goals. For example, if the goal of the software is to increase the
collaboration amongst the department silos, then the business analyst should focus on getting the
key features around collaboration, such as workflow management across departments scenarios,
elicited first. These business value/benefits are expressed in the form of business capabilities.
For example, improved collaboration amongst departments will have key business capabilities
defined as:
Ability to create a case which has all departments contribute to the case (on need basis).
Ability to view the case by all departments.
Ability to create/delegate tasks to more than one department.
In an agile world when these business capabilities are further elaborated using user stories it is the
job of the business analyst to constantly keep the bigger picture of achieving improved collaboration
as a business value for the business.
Constantly reiterating the business value is one part of evolving clarity. The other part is evolving
clarity between all the stakeholders of the project. For example, collaboration to be delivered as a
business value has to be communicated to the user interface expert, who will have to arrive at the
collaboration patterns of the user interface. The developers designing the business process flow
have to be made aware of the collaboration needs and design processes which take input from
different departments in order to arrive at the next course of action. The developers' focus is to
design the processes in a manner by which process data can be accessed outside the case and
new tasks be created. For collaboration design concerns to be reflected in the architecture design,
the business analyst constantly evolves clarity around collaboration and what collaboration means
to the business. What are the tasks/activities which a business analyst performs with an intention of
evolving clarity within an agile software project?
1. Preparing the skeleton flow: the customer for whom the software is being developed
knows what their pain areas are most of the time. The operational business users are
definitely aware of what troubles them in their existing processes and where the bottlenecks
are. The business analyst needs to arrive at a skeleton flow which will eliminate or reduce
these pain areas in the new software. The business users are mostly comfortable in stating
the user interface needs. Their visualization of what they need usually gets articulated as
user interface needs. The business analyst needs to connect with the UI way of visualization
to start preparing the skeleton flow from there on. UI can be the starting point and the BA
can then deep dive into business processes, business events which trigger the processes,
and key business scenarios. The skeleton flow can be painted using HTML mock-up tools
like 'Just in Mind', or even drawn on a whiteboard and photographed. Preparing the skeleton
flow upfront helps the customer create a tangible picture of what features are needed by
them in the software.
2. Rapid prototyping: once the skeleton flow is arrived at for specific user stories, business
analysts create rapid prototypes with the help of the development team to help in pinning
down the requirements. The development team and the customer both start getting a feel of
what is needed. Rapid prototyping is a vital technique to evolve clarity.
3. Actively collaborate with customer to share constantly: clarifying the picture and rapid
prototyping will clearly give an indication to what's known and what is unknown/not clear in
the user's mind. For example, with the intention of improving collaboration amongst the
department, we will define the key business capabilities like 'ability to create a case ' review
case ‘, ‘verify case data from other departments in order approve a case’. How the case gets
created on a customer requesting a 'change of address ' is probably clear, but internally how
each department interacts with the finance department probably still needs to be identified. It
is the job of the business analyst to define unclear scenarios and add them back into the
product backlog. A discussion can then be initiated with the business users to identify how
important interactions with finance department are in the context of achieving the goal of
collaboration. Can it be parked and backlogged, or does it need to be taken up on priority?
These definitions of known/unknowns outline the iterations depending on the levels of clarity
achieved. When the sharing happens for clear/unclear areas it gives a sense of direction to
the business users of where the software development is heading.
Holding Context Continuously
Once clarity emerges into the 'why' of the software project, the context of the 'why' has to be held
2 of 6
2014-05-27 10:19 AM
Business Analysis in an Agile World - IIBA | International Institute of B...
https://www.iiba.org/News-Events/Best-Practices-for-Better-Business-A...
continuously in the project. The business analyst provides the space for keeping the business goals
central.
1. Continuously build terminology: the business describes its operations/processes in their
own terminology. For example, first time prospects for Insurance who have never interacted
with an insurance company to obtain insurance are termed 'raw policies'. This term as 'raw'
will be unique to that particular insurance company. This terminology needs to be held by
the business analyst and a conscious effort has to be made to localize (making terms as
part of everyday conversations) within the development team. Eventually the goal is to make
the development team speak the domain language of the business software is being
developed for. This process creates a common context for communication between the
business users and the development team. This glossary of terms and their business
meanings should be documented, continuously updated, and utilized without exception in
the description of the User Stories.
2. Retrospection: the opportunity to see what we did earlier and what needs to change. When
an operational business process adopts automation certain activities become redundant, or
how the activities are carried out change. There arise certain technical or legal constraints
due to which processes have work around. For example, a decision has been taken to not
digitize certain physical forms into online forms due to legal constraints of digital signatures
not yet recognized by law for the process of registration. The context around this decision
has to be constantly reiterated to the development team to have a work around for these
physical forms. A physical channel of submission has to be kept open and managed. So
now even the earlier decision of digitizing all forms was taken now it has changed to
accommodate legal constraints. For the development team, additional work to create a
physical submission channel needs to be incorporated. The impact of developing and
managing this process and integrating it with the backend automated process now has to be
completely thought through. It is the role of the business analyst to visualize these scenarios
and alert the project management and business stakeholders to allocate time for the newly
introduced physical submission process. In an agile world where scenarios evolve rapidly,
the physical submission scenarios have to be parked in the product backlog and taken up at
the appropriate time depending on the needs of the business. Retrospection also serves as
an opportunity to correct wrong decisions. The agile world demands quick decision making.
With quick decision making, decisions are made in order to move forward, rather than wait
for someone else to make the decision. This demonstrates complete ownership and
accountability towards achieving goals. Only a self empowered business analyst will be able
to make quick decisions and take accountability for those decisions. Trusted environments
will create the space for retrospection.
Building Empowered Teams in Trusted Environment
This outcome has two responsibilities. One is to create a trusted environment and the second is to
build empowered teams in that environment. What does a trusted environment look like? What
relationship does it have to empowerment? Why is this specifically important in an agile world? How
does it become a business analyst's responsibility to create and manage such environments?
These are the predominant questions which come up when agile environments and business
analysis are thought about.
According to Dr. Duane C. Tway, Jr. in his 1993 dissertation, A Construct of Trust, trust is "the state
of readiness for unguarded interaction with someone or something." Dr. Tway developed a model of
trust that includes three components:
the capacity for trusting,
the perception of competence, and
the perception of intentions.
The capacity for trusting means that your total life experiences have developed your current
capacity and willingness to trust others. The perception of competence is made up of your
perception of your ability and the ability of others you work with to perform competently at whatever
is needed in your current situation. The perception of intentions, as defined by Dr. Tway, is your
perception that the actions, words, direction, mission, or decisions are motivated by mutuallybeneficial rather than self-serving motives.
In the context of an agile world these three constructs of trust become important, as an agile world
is characterized by highly uncertain environments marked with continuous, pressurized velocity to
demonstrate quick results. In such environments a willingness to trust others speeds up the
software development process. As the possibility of making mistakes and these mistakes becoming
visible to all stakeholders is high, trust in people's abilities creates a feeling of security. In this
secure environment a 'let's try' attitude thrives. In an agile world boundaries of traditional software
roles dissolve, hence trusting in the intentions of mutually-serving motives drives the smooth flow of
work.
What activities of a business analyst contribute to creating trusting and empowering environments?
1. Build 'Listening' in teams: assuming the empowerment of a business analyst is
self-acquired, building 'listening' into various teams becomes a key activity. When 'listening'
thrives, buy-in and conflict handling/resolution become relatively easier as all the teams
regard the business analyst with clear intentions of achieving their goals in the project.
Building listening is a gradual process which requires conscious effort on the part of the
business analyst to work with the available circle of influence. The listening will be built by
nurturing authentic relationships with stakeholders, demonstrating intellectual gravitas, and
3 of 6
2014-05-27 10:19 AM
Business Analysis in an Agile World - IIBA | International Institute of B...
https://www.iiba.org/News-Events/Best-Practices-for-Better-Business-A...
having and conveying insightful point of views.
2. Explicit understanding of shared responsibility: in a software development project there
is more than one stakeholder involved with different concerns which need to be taken care
of. For example, the IT implementation team of the business will have concerns around the
maintainability of software and will provide inputs for the System Admin User Role persona.
The business users will have concerns about the usability of the software, while the project
sponsors will have concerns around the costs and the business value being delivered. With
a stake in the outcome comes responsibility and where we have multiple stakes there is
bound to be conflicts. A business analyst will identify such shared/conflicting responsibilities
and resolve them so that appropriate prioritized requirements are elicited. A business
analyst will facilitate discussions around sensitive conflicts and help the business arrive at a
common ground so the project can be delivered smoothly. With clearly defined shared
boundaries, accountability rises and decisions and bottlenecks are resolved quickly and
efficiently.
3. Achieving the right balance between the functional utility of the software and the cost
of development: an empowered business analyst has a sharp eye on the business value
which needs to be delivered. At the same time the development team has to be constantly
reminded of the functional concerns being addressed through the software. The
development team with its technical skills being dominant tends to over-engineer as their
passion in life is technology. It's the business analyst who constantly weighs the technical
capability in terms of the functional capability. In an agile world where constant delivery and
continuous integration are the norm, over-engineering functionality can increase the cost of
development which can put further iterations into pressure. Having 'just enough' technology
is the role of the business analyst. Having said that, controlling the demands of the business
and educating them on the cost and utility of a functional capability is the role which the
business analyst has to play tactfully. Empathizing with the development and the business
teams and striking the appropriate balance for driving maximum business value, within cost,
is one of the key and most difficult capabilities which the business analyst needs to
demonstrate.
Gauging Documentation Needs
Important as it is to gauge 'just enough' technology it is equally important to gauge 'just enough'
documentation. The traditional role of a business analyst is to document requirements in a well
articulated manner for the business and development team. Good articulation is still a key skill but
the mode of representation in an agile world is more vocal than on paper. In order to achieve the
outcome of gauging 'just enough' documentation, the following activities are performed by the
business analyst:
1. Knowing the 'why' of documentation': the why of the documentation is the purpose for
which documentation as an activity is being performed in the software development life
cycle. There are 4 key purposes of documentation within a software project:
a.
b.
c.
d.
communicating what is to be developed,
referencing and tracking key decisions taken,
training, and
regulatory compliance.
To meet these purposes different time and effort is required and has to be determined by the
business analyst. For example, if the purpose of documentation is regulatory compliance, where
each piece of code written has to be recorded for auditing purposes, then to achieve this purpose
would require a lot of time and effort to ensure that the code written is properly tagged/commented,
and there is an ability within the software development management tool to auto-generate
documentation from the comments in the code. Awareness of the importance of maintaining
discipline in commenting has to be adequately communicated to the development team. On the
other hand, if the purpose of documentation is training then documentation activity will take a
different shape, creating, for example, user manuals or a comprehensive, searchable online help
function which communicate how to use the software. In an agile project where normally
documentation is considered an overhead, (when it can't be justified within the team), gauging the
'why' of documentation needs to be sorted out and planned for in iterations.
Arriving at the apt documentation methodology for the concerned stakeholders: once
the purpose for which documentation is needed is arrived at a documentation methodology
which achieves that purpose needs to be created. For user manuals, videos which
demonstrate application usage can be used. For regulation, audit purpose software which
creates documentation from comments section in the code can be used. It's the role of the
business analyst to educate the customer on proper documentation needs and arrive at the
appropriate documentation methodologies, and potential enabling tools which support agile
development. In today's socially interactive world technologies like wikis and social
interactive sites can be used to manage collaborative documentation building.
Conclusion
The skills of a business analyst in an agile world focus on achieving outcomes which deliver
business impact, rather than generate outputs which define business requirements. Business
analysts role may become more demanding in terms of delivering the requirements, rather than just
documenting requirements in a traditional world. Business analysts build collaboration capabilities
which revolve around empathetic communication and crisp articulation. Business analysts require a
hawk's eye on the business value being delivered, and any shift in the focus needs to be escalated
4 of 6
2014-05-27 10:19 AM
Business Analysis in an Agile World - IIBA | International Institute of B...
https://www.iiba.org/News-Events/Best-Practices-for-Better-Business-A...
and dealt with. With constant dialogue between multiple stakeholders, conflict management and
resolution forms one of the key skills without which a business analyst will not survive in an agile
world.
Every skill building process needs challenges. When a greater magnitude of challenge is met by
endurance and the right tools it builds a strong level of the skill within any role. The following table
defines the skills and the relevant challenges which a business analyst might have to overcome
when developing those skills. The tools and techniques are always a value add and are a means to
an end and not an end in itself.
Key Skill
Challenges in learning the skill
Tools an Techniques
Evolving Clarity
• Most business are investing in IT for
building new business capabilites rather than
simply automating existing business
processes. This means that customers as
well as the IT teams have clear visions of
what is needed but might not have clarity
around what that system should look like.
• Discovery
workshops to clarify
intent, facilitation
skills.
• Different stakeholders are engaged with the
project at different times, and with limited
involvement. It becomes critical for the BA to
evolve clarity around the goal and objectives
of the project at all times.
Holding context
continuously
Building
empowered
teams in trusted
environment
Gauging
documentation
needs
• Design Thinking
• Socialization of
ideas.
• In the course of a project the focus shifts
from the business goals to performing
defined activities and the connection
between goals and activities is lost. This
happens at all levels, from missing project
goals or missing PoC (proof of concept)
goals or missing goals for some specific
review process that has been established. All
stakeholders bring past knowledge and
experience into the project and tend to use
terminology which suits their needs. This
gives rise to confusion around similar
concepts. The BA must constantly drive
context for all stakeholders.
• Clarifying goals,
building common
language and
insisting on use of it.
• In large multi-location, multi-culture projects
each organization brings in a flavour of their
value system into the software development
process. This gives rise to various types of
communication channels and means of
communication. Core challenge is
maintaining balance between - on one hand
"have culture of making decisions and
maintaining healthy momentum" on other
hand "understanding who owns what and
who should make those decisions."
•Taking calculated risk
in favor of time at cost
of being wrong
• Understanding "just enough"
documentation for managing Complexity of
the Software Development Lifecycle (SDLC)
model – agile /Hybrid model and regulatory
compliances.
• Maintenance needs
of the IT application
as an indicator to
documentation
• Engaging/Enrolling
conversations to
achieve project goals
and intent.
•Conflict management
and prioritization in
line with goals
• Retrospectives to
quickly figure out
mistakes and bring
correction
• Use of modern real
time communication
apps like whatsapp,
trello, and twitter.
• Concept of user
stories, Wikis, social
collaboration sites
What nature has always taught us about survival in any environment is that a species has to evolve
and adapt itself or become extinct, or worse, unemployable. If business analysis as a profession is
to survive in an agile world it has to evolve to greater capabilities and a highly demanding and
interactive environment.
An aspiring /practicing business analyst can start building these skills within the current scope of
their role boundary. As the skills become polished, the circle of influence will broaden and give the
business analyst a much wider area to sharpen their capabilities further.
Wishing all the business analysts an exciting transformational journey into the newly evolved role of
an agile business analyst!
Bibliography
5 of 6
2014-05-27 10:19 AM
Business Analysis in an Agile World - IIBA | International Institute of B...
https://www.iiba.org/News-Events/Best-Practices-for-Better-Business-A...
Tway, Duane C., A Construct of Trust , Dissertation, 1993.
The Review Panel
®
IIBA and the author would like to thank the review panel for their critiques, insights, and thoughts
on the development of this article.
The review panel for this article was:
Hardeep Singh,
Angela C Hansen,
Darra Olson, and
Zoya Roytblat.
©2014 International Institute of Business Analysis | Trademark Notice
6 of 6
Advertise
Trademark Policy
Privacy Policy
Sitemap
2014-05-27 10:19 AM