Page 1 of 8
We Get it. We’ll Help You Get it Too.
A
s the use of agile approaches
increases, business analysts
struggle to determine how their
role maps to the new approach and
how it has changed from their familiar
development process. Business analysts,
for example, often nd themselves
proclaiming “in everything I read/hear
about agile, I never see “business analyst”
mentioned!”
Even though the role of business
analyst is rarely mentioned in descriptions
of agile it does not mean that business
analysis does not occur. In fact, agile’s
focus on delivering value to customers
requires the entire team to collaboratively
perform business analysis on a frequent
basis. is and other characteristics of
agile change how a business analyst works
on a project.
One change that agile introduces is a
barely sucient process which does not
prescribe any documentation, including
requirements artifacts. at does not mean
that documentation is not produced,
rather the business analyst collaborates
with other team members to decide what
is needed to best deliver the solution,
including how much documentation is
necessary. Contrast this with the detailed
methodologies and standards for plan-
driven projects used by large organizations
that require business analysts to complete
extensive requirements documents. ese
artifacts lead business analysts, especially
less experienced ones, to document the
same requirements several ways using
dierent models and text even though
more succinct recording
of requirements is
sucient.
Another change with
agile approaches is the
use of short, time boxed
delivery cycles referred to
as iterations or sprints.
ese iterations include
all the work necessary to
go from a requirement to
a running, tested feature
that could be delivered
to production. e use of
iterations allows the team
to continuously reect
on their past eorts and
adapt their processes
to improve. e short
timeframe of iterations
(typically a week to a
month) means that the
scope for each iteration is
much smaller than most
traditional projects so
the business analyst only
needs to focus on the
portion of the solution being delivered
during that iteration. Business analysts
collaborate with other team members
to determine how much analysis is
needed at the beginning of the project
to establish the big picture, and during
each iteration in order to establish a
shared understanding without creating an
extensive requirements inventory.
A third change in agile is the existence
of the product owner role. e product
owner is the ultimate decision maker
and ultimate representative of business
needs for the project. In order to be truly
eective, the person lling the product
owner role should be well versed in many
core business analysis techniques, but
they rarely are. is provides the business
analyst an excellent opportunity to assist
the product owner as is discussed below.
Finally, all team members have the
opportunity to perform analysis so the
business analyst also coaches the other
team members on analysis techniques and
the appropriate stakeholders to contact.
Allowing multiple team members to
perform analysis prevents handos that
occur in phased based approaches, and
on an Agile Project?
Page 2 of 8
We Get it. We’ll Help You Get it Too.
keeps the business analysts on the team
from becoming bottlenecks to overall
team progress.
e activities that a business analyst
performs to advise the product owner and
coach the team, as well as other business
analysis considerations are discussed below.
What is agile really about?
ere are as many dierent denitions
of agile as there are people providing
denitions. For the sake of this paper,
agile is dened as collaboration among
stakeholders to deliver value to customers
in frequent increments with consistent
reection and adaptation. is denition
focuses on the characteristics that exist in
all agile environments, namely:
• Collaboration–howthepeople
involved in the eort work together
which includes both the delivery team
and project stakeholders
• Delivervalue–thetruepurposeof
eorts is to provide value to customers,
whether that is through new software,
more ecient processes, or new
products.
• Frequentincrements–theteamdelivers
values every few days, weeks, or months
rather than once at the end of a project
• Consistentreectionandadaptation
–theprojectteamreectsontheir
approach and the product on a regular
basis and adjusts accordingly.
Agile approaches allow teams to focus
on delivering the highest value as set by
the business in the shortest time. Teams
using agile approaches self-organize to
rapidly and repeatedly inspect actual
working software in iterations ranging
from one week to one month in duration.
At the end of each iteration, anyone can
see real working software and decide to
release it as is or continue to enhance it
for another iteration.
e biggest impact of iterations on
business analysts is the lack of an analysis
phase. Instead of performing all analysis
work to develop detailed requirements
at the beginning of the project, business
analysis occurs throughout the project
with an initial high level picture of the
overall scope, followed by more detail on
specic features when they are delivered.
e key is knowing the sucient
amount of business analysis necessary to
understand the problem and the aspect of
the solution currently being delivered and
still keep the project moving forward.
Another aspect of agile approaches
that impacts business analysts is the
lack of prescription. Agile approaches
are based on the premise that simple
rules generate complex behavior so they
provide a minimalist framework for
teams to organize their work and leave
the rest to the self-discipline of the team.
So while agile approaches do not require
Agile Roles
Because of the focus on teamwork
and collaboration, roles in agile
approaches are more general in
nature than those of more plan
based, or traditional prescriptive
approaches. Tasks specific to the
business analyst are not prescribed
in an agile environment, so business
analysis practitioners need to know
where business analysis techniques
need to be applied in a project.
There are four primary roles included
in an agile project.
The Product Owner is the ultimate
decision maker for the product. This
role is responsible for defining the
product vision, prioritizing features
according to business value, and
answering team questions.
The Scrum Master is the guardian
of the team’s process. This role is
responsible for ensuring the team
has the appropriate environment to
succeed, removing obstacles, and
enabling close cooperation across all
roles.
The Team
dedicated to the project full time who
are responsible for self-organizing
to deliver value to the customer in
each iteration. The team determines
how the product is developed, and
how the work is divided up to do that
based on the conditions at the time.
A Stakeholder is anyone who can
impact the project and provide input
to the business objectives of the
in the project are part of the team.
involved in the project may still interact
with the product owner to provide their
input on the product backlog.
Page 3 of 8
We Get it. We’ll Help You Get it Too.
any documentation, they do not prohibit
any either. Rather it is the appropriate
amount of documentation. When teams
are deciding what to document in an
agile project, business analysts may
suggest they ask the following questions:
• Isthissomethingastakeholderis
requesting?
• Isthissomethingtheteamneedsin
order to eectively do its job?
Because the business analyst is not
so focused on trying to document all
requirements, rules, etc. for a separate
development team, they can focus more
timeonactualanalysis–didweconsider
all the scenarios that may occur? Are we
keepingoursolutionconsistent?Dowe
know what unintended consequences we
may be creating with this change?
A nal aspect of agile that represents
a departure from traditional approaches
is the focus on teamwork over rigid
specialization. e most noticeable result
to business analysts is that everyone
on the team is encouraged to talk with
stakeholders directly to understand their
needs. Business analysts may initially
consider this a threat until they realize
that they have an opportunity to coach
their teammates how to be the most
eective performing this activity, and they
get to expand their toolkit by helping the
other team members with their tasks.
Agile teams don’t always start out
being completely collaborative. Teams
will often initially fall in the trap of
having developers only do development,
testers only doing testing, and of course,
analysts only doing analysis. Business
Analysts help move the team toward a
more collaborative nature by adopting the
two roles that position them to be a truly
value added member of the team:
• BusinessAdvisor(supportingthe
Product Owner)
• BusinessCoach(Actingastheanalysis
expert on the team)
e nature of the change in the
business analysts’ work is focused
exclusively on how they interact with
their team members, product owner, and
stakeholders. ey are no longer solely
responsible for requirements so they
will have a lot more interaction helping
their team members improve their
analysis skill sets and focusing on more
strategic focused activities through their
interaction with the product owner.
The Business Analyst as
Business Advisor
Most agile approaches have a specic
role to represent the ultimate business
decision maker, such as the role titled
product owner. e product owner sets
the product vision and is responsible for
understanding and representing the needs
of the business and user stakeholders.
e product owner determines which
requirements are most important prior to
the start of each iteration and determines
how to release value incrementally to
best satisfy the needs of the product
stakeholders.
A business analyst does not always
have the decision making authority
necessary to be an eective product
owner, but they can become indispensible
by supplementing a product owner’s lack
of time or business analysis skill sets.
A business analyst supports a product
owner by helping them analyze the
business domain, stocking the product
backlog, and grooming the product
backlog.
Analyze the Business Domain
e business analyst helps the team and
product owner understand and describe
the business domain and problem to be
solved by facilitating the discussions that
explore the following questions:
• Whatbusinessprocessesneedtobe
revised, created, or eliminated?
• Whatinformationdowewanttoknow
about and track about various entities?
• Whatstakeholders(suchascustomers,
suppliers, vendors) and systems are
involved in the eort?
• Whatpoliciesandrulesguidebusiness
behavior and decisions?
While it is important to establish a
shared understanding of the business
domain, this can’t take a great deal of
time, especially because the models
change as the project progresses and the
team learns more as they proceed through
the project. To keep this analysis focused,
business analysts time box their analysis
investigation, prioritize the topics being
analyzed, and stay on task with any team
discussions.
e business analyst helps the team
decide if the requirement models are
useful beyond the life of the project.
Factors to include in this decision are
the eort required to keep the model up
to date and the value of the model after
the project. If the model is only needed
for a brief discussion to gure something
out, a sketch on a whiteboard persisted
in the form of a digital picture may be
sucient. If the diagram is necessary
throughout the project or is expected to
live on past the end of the project, the
team may wish to establish the model in
using a modeling tool. is decision is
an aspect of generating the appropriate
amount of documentation.
Stock the Product Backlog
Stocking the product backlog means
to establish a list of user stories that
represent the overall scope of the
project. A user story briey describes
functionality or a feature valuable to
either a user or customer of a system or
software solution. In the remainder of
this paper, user stories, and their bigger
Page 4 of 8
We Get it. We’ll Help You Get it Too.
variant, epics will be referred to as stories
unless there is value in distinguishing
them. Business analysts help the product
owner derive stories from the models
created during business domain analysis.
is is analogous to identifying the
business requirements for the project and
establishing the initial scope.
Additional stories emerge as the
project proceeds and are elicited from
models created or updated as well as
through conversations with impacted
stakeholders throughout the project.
Business analysts help the product
owner, stakeholders, and the team create
stories as a reminder to deliver some
functionality represented by the models,
or discussed in a conversation. Stories
can be derived from requirements models
such as data models, process ows, work
ow diagrams, use cases, business rules,
and user interface diagrams.
Stories also result from conversations
with stakeholders. ese conversations can
vary from an informal chat to a planned,
facilitated workshop specically for the
purpose of establishing a list of stories.
Informal conversations resulting in
new stories occur throughout the project
and are a big advantage of projects in the
agile environments. e use of a product
backlog–alistofthingstodeliveron
the project - allows the team to take
note of these new requirements as they
occur without being distracted from
the immediate work of the iteration.
e requirements are placed on the
product backlog for further analysis and
consideration by the product owner.
New stories also surface during
work in the iterations and during
end of iteration demos. Seeing some
functionality delivered inspires
stakeholders to consider additional
features that may be needed or to think of
other scenarios where the system should
behave dierently.
Groom the Product Backlog
Grooming the product backlog refers to
maintaining the product backlog so that
it remains a tool for the product owner
and team and not a burden. Business
analysts help the product owner groom
the product backlog by considering
purpose, prioritizing the stories,
organizing the stories, splitting epics into
user stories, and ensuring a complete
description of the solution.
rough understanding how a story
supports the purpose of the project and
organizational strategy a business analyst
can help the product owner decide
whether a story should be included on
the product backlog and the approach
used to deliver that particular story.
e Purpose Based Alignment model
makes it easier for teams to understand
the organization’s strategy by looking
at what activities are dierentiating
and making project level decisions
accordingly. By placing stories in the
appropriate block, it helps the team
determine how to:
• Deliverstoriesthatsupport
dierentiating activities uniquely.
• Deliverstoriesthatsupportparity
activities in the simplest way possible.
• Looktoworkwithanother
organization to deliver stories that
support partner activities.
• Decidewhethertodeliverthosestories
that support the “who cares” activities.
Business analysts can help the product
owner order the product backlog by
providing information on stakeholder’s
perceived value of the various items in
the product backlog. e model does
not provide guidance on priority, but
there are other techniques used to gather
priority information from multiple
stakeholders. Two of these techniques
are value points and buying features. In
the value points approach, stakeholders
are asked to get together as a group
and indicate the relative value of stories
in comparison to other stories in an
approach similar to planning poker.
In the buying features technique,
stakeholders indicate how much each
item in the product backlog is worth to
them by spending an amount of “feature
dollars” across some or all of the items
in the backlog. e amount of feature
dollars they assign to a given item
indicates the importance they place on
that particular requirement.
Prioritizing a backlog certainly helps
introduce some
order to a backlog,
but teams often
need other ways to
order requirements.
Business analysts help
the product owner
and team keep the
product backlog easy
to follow and manage
through a variety of
techniques including
grouping the stories
into themes, and
organizing the stories
into releases and
iterations.
Page 5 of 8
We Get it. We’ll Help You Get it Too.
Teams working with a fairly large
product backlog on a complex project
nd grouping the stories into themes
a great way to add some hierarchy to
the product backlog. Stories that satisfy
dierent aspects of the same need or
that need to be grouped together to
deliver complete customer value are good
candidates for themes.
Teams also organize the product
backlog into releases and iterations to
provide an indication of when specic
stories are targeted for delivery. Exactly
when stories get assigned to a release or
iteration depends on the point in the
lifecycle.
Duringroadmapplanningbusiness
analysts help product owners and
stakeholders organize the stories in the
product backlog into releases based on
priority to deliver the highest value stories
rst. Stakeholders get an initial feel for
when they can expect functionality to be
delivered and available.
Duringreleaseplanningbusiness
analysts work with the product owner
and team to decompose epics in the
current release into user stories and
identify the iteration in which each
story may be delivered. e release
plan changes as work on the iterations
proceeds. e release plan helps the team
determine if they need outside assistance
from any outside resources or if stories are
complex and need to be analyzed during
the iteration prior to their delivery.
Duringiterationplanningtheteam
commits to delivering a set of stories in
that iteration and the product owner
makes any necessary changes to the
release plan.
Business analysts often work with
the team to right size stories for delivery
within an iteration. Stories are of dierent
sizes based on how close they are to being
delivered. Epics are too large to deliver
within a single iteration, and exist as
reminders of general functionality that
needs to be further dened as the time
for implementation nears. is further
denition creates user stories, which
are small enough to deliver within an
iteration and planned to be delivered in
the near future. ere are many dierent
ways to split stories. Two frequently
used approaches are splitting stories on
operational boundaries (create, read,
update, and delete) or on data boundaries
(dierent pieces of information associated
with an entity).
A nal way that Business analysts help
product owners is to help them ensure
that the portion of the solution being
Project Lifecycle in Agile
The iterative nature of projects in an agile environment changes the form of the
project lifecycle, but not the activities that are performed.
levels, at differing levels of detail. The nearer term the plan, the more detailed
it is.
In Product visioning, the product owner describes how the organization or
product should look in the future in order to implement organizational strategy.
Business analysts support product planning through working with the product
owner to define the vision for a product and purpose of the project.
team and stakeholders, help the product owner determine at a high level what to
deliver by stocking the product backlog with epics and user stories (stories).
and stakeholders, help the product owner prioritize the stories in the current
release and identify in which iterations the stories are targeted for delivery.
In iteration planning, the team commits to deliver a set of stories and identify
a corresponding set of tasks needed to deliver those stories. This set of tasks
creates the sprint backlog. The business analyst fully participates in this activity
as a member of the team and may facilitate this activity.
Page 6 of 8
We Get it. We’ll Help You Get it Too.
delivered in current iteration and release
is fully explained. Some questions to ask
to ensure the description of the solution
is complete:
• Doweknowwhichusershavethesame
goal?
• Aretheresomeuserswhoshould
not be able to use the functionality
developed?
• Arethereanyscenariosthatwehave
to account for in order to provide the
expected value?
• Dowehavesucientinformationto
meet the goal requested by the user
stories?
• Dowehavesucientinformationto
enforce the identied rules?
• Whatunintendedconsequencesoccur
if we deliver these user stories?
• Dowehaveacompleteunderstanding
of the process that will use this
functionality?
Business analysis skills are vital for
analyzing the product backlog for
completeness. As a result, Business
analysts either perform this analysis or
coach other team members in how to
perform this analysis. Involving the entire
team increases the chance of identifying a
complete understanding of the problem
and description of the solution.
The Business Analyst as
Business Coach
Duringtheworkofaniterationthe
business analyst interacts with the team,
acting as the analysis specialist on the
team. Some of the activities the business
analyst performs or provides coaching
to the team during an iteration include
facilitating collaboration, generating
examples, transferring knowledge, and
being a good team member.
Facilitate Collaboration
Collaboration within the team and
between the team and stakeholders is
vital for project success. Business analysts
facilitate collaboration through helping
with stakeholder analysis and acting
as a language coach. Business analysts
have the clearest understanding of the
stakeholders involved in the project so
they can provide suggestions on which
stakeholders that team member should
talk to for information.
Once they have helped their
teammates identify the appropriate
stakeholders to talk to, business analysts
turn their experience translating “business
speak” into “technical speak” and vice
versa by helping team members from
dierent backgrounds and team members
and stakeholders “speak the same
language.” ey change from translating
the messages between two people talking
from dierent perspectives to helping
those people talk to each other.
Generate Examples
Teams in an agile environment use
examples to clearly communicate
business intent, provide more detail
about stories, and to conrm those
stories were delivered properly. Examples
are a good technique for remembering
the information discussed during
conversations, communicating that
information to the team members
who will deliver the user story, and for
conrming the user story was delivered
properly.
Teams use the same examples to
communicate requirements to the
implementation team and describing tests
to ensure consistent understanding of
expected system behavior. e examples
are real world - meaning that they
are possible, even if they are not very
probable.
Any team member can generate
examples, but business analysts may
do the bulk of this work if the team
determines that analysis needs to occur in
the iteration prior to when user stories are
delivered.
Examples can take a variety of forms.
When describing the enforcement of
business rules, the appropriate form is
as a table. Communicating examples as
tables makes it easier to grasp the content
and spot gaps and inconsistencies. When
describing a process, the Given, When,
en format is more appropriate.
Examples are also generated to
consider normal use, abnormal but
reasonable use, and abnormal and
unreasonable use to identify dierent
scenarios. Some good questions that
teams ask when generating examples
include:
• Howshouldweverifythatthisuser
story is implemented completely and
correctly?
• Pretendthatwehavealreadydelivered
thisthing–howwouldyouactually
test it?
• Aretherecaseswiththisparticularuser
story that we have not identied how
the system should behave?
Transfer Knowledge
Business analysts along with the product
owner have the best grasp of the big
picture of the project and where it
ts within the organizational strategy.
ey spend a considerable amount of
time during the work of the iteration
transferring to the other team members
the information gained while they were
acting as a business advisor.
e best way to transfer that
knowledge is to involve the team
members in the analysis of the
business domain and the stocking
and grooming of the backlog. Because
Page 7 of 8
We Get it. We’ll Help You Get it Too.
the entire team cannot be involved in
each of these exercises, some relaying
of this information is necessary. is
information can be transferred by posting
the business domain information on
information radiators, or a common
shared area, available to the team to refer
to when needed.
Be A Good Team Member
Business analysts get the opportunity to
help their teammates clear bottlenecks.
Doingthisimprovesrelationshipswith
other team members and gives the BA an
opportunity to expand their toolkit and
learn new skills through performing tasks
generally performed by other roles such
as testing, user interface design, preparing
test data, training, and providing an
update to an executive sponsor.
Conclusion
Agile approaches do not prescribe many
roles, primarily because the focus on
collaboration makes the establishment
of many roles unnecessary. is lack
of dened roles oers business analysts
an excellent opportunity to expand
their horizons both from a business
perspective, as well as a technical
perspective. Business analysts work
closely with their product owner to
position the product to best deliver
value to stakeholders, in the process
building their domain knowledge and
experience solving business problems.
Business analysts also work closely with
their team mates to improve everyone’s
analysis skills as well as acquire new
skills including testing and perhaps even
some coding skills. ese opportunities
position the business analyst to look
beyond a specic role and work with
their teammates to deliver value for their
customers, and improve their worth in
their organization. n
Cohn, Mike, (2004), User Stories Applied: For Agile Software Development, Addison Wesley.
Cohn, Mike. (2005), Agile Estimating and Planning, Addison-Wesley Professional.
Cohn, Mike (2009), Succeeding with Agile: Software Development Using Scrum, Addison-Wesley Professional.
Cohen, Greg (2010), Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams, Super Star Press.
Pichler, Roman (2010), Agile Product Management with Scrum: Creating Products that Customers Love, Addison-Wesley Professional.
Pixton,Pollyanna,NielNickolaisen,ToddLittleandKentMcDonald(2009),Stand Back and Deliver: Accelerating Business Agility, Addison Wesley.
Key BA Skills for Agile Projects
A high performing business analysis professional on the team increases the likelihood that the resulting product meets true
business needs and fits in well with the current business environment. If an experienced business analyst is not available, at
least one team member must have extensive business analysis training and experience. Key business analysis skills that an
agile project needs:
involved with
picture and envision possible solutions
decisions, and implementation decisions
that may lead to problems
depending on the need of the project
stories, use cases, and informal modeling. These are the
primary requirements techniques used by agile teams.
B2T Training is focused solely on providing business analysis training and professional development. We were established to provide the
highest quality business analysis training and support for ongoing development of business analysis professionals. We bring over 25 years
experience in business analysis to our offerings.
B2T Training developed the first comprehensive BA training program in North America and has been a model for other training
organizations. As experts in the field, B2T Training continues to shape the Business Analysis discipline and the careers of BA professionals
in major corporations across the globe through its high impact training sessions and valuable resources. To support students in their
transition from the classroom to their projects we provide individualized mentoring and consulting services to help companies develop
their mentoring strategy.
B2T Training is an endorsed education provider of the IIBA
®
and registered education provider of PMI
®
.
We Get it. We’ll Help You Get it Too.
Page 8 of 8
