You are on page 1of 24

:

e
d
i
u
G
l
a
c
A Practi
e
l
v
o
e
p
D
m
e
l
i
g
e
n
A
t
&
s
t
s
y
l
a
n
A
s
s
e
n
i
s
u
B
s
a
h
n
t
a
v
i
r
h
S
l
e
a
h
c
i
M

BA

Copyright 2013 Accompa, Inc.


This work is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works
3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/
by-nc-nd/3.0/us/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco,
California, 94105, USA.
Accompa is a proud member
of the Agile Alliance.

Table of Contents
1.

Ahoy, Welcome to the Accompa Agile Voyage for BAs!

2.

So, What is Agile Anyhow?

3.

Agile Terminology: User Story, Product Owner, and Scrum Master

4.

More Agile Terminology: Epic and Theme vs. User Story

5.

What is Acceptance Criteria and Who Writes It?

6.

Even More Agile Terminology: Sprint vs. Release, Backlogs

7.

The Wrong Question

8.

The Right Question

9.

Practical Tips for BA Teams Adapting to Agile Development

10.

Best Practices - BA Teams Using Accompa for Agile

11.

Frequently Asked Questions

12.

Land, Ho!

13.

Recommended Resources

1. Ahoy, Welcome to the Accompa


Agile Voyage for BAs!
Hi there! This guide outlines practical tips on how
Business Analysis teams (hereafter referred to as
BA team) can successfully adapt their work
processes when their Development team switches
to Agile processes such as Scrum or XP.
While this guide is primarily intended for
medium-to-large companies (companies with 100
or more employees), smaller companies may also
find many of the concepts beneficial.
Anchors Aweigh!

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 1

2. So, What is Agile Anyhow?


Agile is a set of guidelines that helps software development teams
build software in a better way.

Agile is a set of
guidelines that helps
software development
teams deliver useful
increments of software
iteratively.

Development teams that use an Agile process deliver useful,


valuable increments of software iteratively - usually every 1-4 weeks.
In Scrum, the most popular Agile process, each iteration is referred to
as a Sprint.
As explained at the Agile Manifesto website, Agile is about better
ways of developing software. Agile manifesto includes 4 items:
1.
2.
3.
4.

Individuals and interactions over processes and tools.


Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

Development teams following various Agile processes are inspired


by this manifesto to develop software in a better way.
While there are many specic Agile processes that Development
teams follow, the most popular one is Scrum. As a result, this
guide will refer to Scrum terminology and processes. However, the
concepts in the guide should apply equally to other Agile processes.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 2

3. Agile Terminology: User Story, Product Owner, and


Scrum Master
User Story is a short description of a feature written
from the perspective of a user. User story is the key
requirements artifact in Agile projects, and follows a
simple format such as:
As a [type of user], I want [some feature] so that
[some benet].
User stories (see next section for practical examples)
are typically written on index cards or sticky notes, and
then arranged on walls to facilitate discussion.

User Story is
a short, simple
description of a feature,
written from the
perspective of a user.

User stories (or just Stories for short) usually do not


replace detailed requirements - it is, perhaps, best to
think of them as pointers to detailed requirements.
Product Owner is a new role recommended for Agile
teams by the Scrum Alliance. Product Owners (POs)
work closely with Development teams and perform
these duties:
Create, expand, and/or prioritize stories for a sprint.
Manage sprint backlogs. (Backlog refers to a
collection of stories)
Communicate product vision to the sprint team.
Be the nal authority representing customer interest
during the sprint.

Product Owner
(PO) works closely
with Development
team during sprint, and
acts as final authority
representing customer
interest.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 3

Agile Terminology: User Story, Product Owner, and Scrum Master


Scrum Master
(SM) makes sure
the Development
team follows Scrum
processes during the
sprint.

Scrum Master is another role recommended for Agile teams


by the Scrum Alliance. Scrum Master (SM) is usually a senior
member of the Development team - duties include:
Make sure Development team follows Agile/Scrum
practices & processes.
Work with PO to make sure release backlog is in good
shape and ready for next sprint.
Remove impediments to Development teams progress.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 4

4. More Agile Terminology: Epic and Theme vs. User


Story
We dened the term User Story in the previous section.

Epic is a large, highlevel user story.


Theme is a way of
grouping user stories.

Epics and Themes are two terms that are often


confused with user stories. Heres a brief denition of these
two terms.
Epic is a large, high-level user story. You can think of it as a
10,000 foot view of the desired feature. An epic is usually
broken down into multiple stories as the project progresses.
Theme is a way to group stories together and helps with
organizing and managing a large number of user stories.

ort
line Rep

Title: Pipe

nt a
er, I wa
g
a
n
a
m
the
a sales
n track
a
s
c
A
:
I
n
o
t
ti
a
p
so th
Descri
their
e report
in
l
e
e against
ip
l
p
p
o
y
l
e
k
p
e
s
e
e
w
y sal
ce of m
n
a
m
r
o
f
per
quota.

Figure 1: A Typical User Story

Example:
Heres an example of Theme, Epic, and User Stories for a
hypothetical project - a CRM Software used by sales
teams.
Theme:
-- Manage Salespeople
Epic:
-- As a sales manager, I want reports so that I can
manage my salespeople.
User Stories:
-- As a sales manager, I want a weekly pipeline
report so that I can track the performance of my
salespeople against their quota.
-- As a sales manager, I want a weekly activity report
so that I can track the prospecting activities of my
salespeople.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 5

5. What is Acceptance Criteria and Who Writes It?


Acceptance Criteria define additional details of a user
story needed to confirm when a story is completed and is
working as intended.
These are written from a customer perspective, and the
Product Owner has primary responsibility for writing them.
Acceptance criteria can serve as pointers to detailed test
cases written by QA/Testing team - similar to how user stories
serve as pointers to detailed requirements.
Acceptance criteria are usually written on the other side
of the index card containing the user story. This helps in
keeping them short and concise.

ny
Criteria:
rt for a
o
e
p
c
e
n
r
ta
e
p
ipelin
Acce
reate a p
c
o
months.
t
3
y
t
it
x
il
e
b
n
A
e
1.
all
in th
port for
eek with
e
r
w
e
d
e
in
l
ir
e
s
de
e a pip
to creat
y
it
il
b
A
2.
ne
rt for o
.
o
e
l
p
e
p
r
o
e
e
p
in
s
sale
pipel
create a
o
t
y
it
il
3. Ab
erson.
l salesp
a
u
id
iv
d
in

Figure 2: Acceptance Criteria for the User Story in Figure 1

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 6

6. Even More Agile Terminology: Sprint vs. Release,


Backlogs
As mentioned earlier in this guide, a Sprint is a
timeframe (usually lasting 1-4 weeks) during which a
useful increment of software is developed.
A Release refers to a sequence of two or more
sprints during which a business-facing release (major
or minor release) of the software is developed.
Sprint Backlog refers to a collection of user stories
being developed during a given sprint. Similarly,
Release Backlog refers to a collection of stories for a
specific release.
Project Backlog refers to all the stories for a given
project, including stories that are not yet assigned
to a release. Project backlog usually contains a
lot of epics - i.e. high-level user stories - that will
eventually be broken down into multiple user stories
before being assigned to a sprint.

Project

Releases

Sprints

Now that weve got the key terminology out of the


way (whew!), let us move on to the meat of this
guide.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 7

7. The Wrong Question


When development teams at an organization decide to switch
to an Agile process - a question sometimes asked by the
organization is:

How can our BA teams follow Agile


process too?
This is, unfortunately, the wrong question for most organizations,
because of the following reason: Agile is a development
process, whereas Business Analysis is NOT a development
process.
Although BA teams work closely with Development teams, the
role of BA teams is usually (or at least should be!) very different
from that of the Development teams.
BAs add the most value when they focus on:

WRONG Question:
How can our BA
team follow Agile
process too?

Gathering business needs from business units & stakeholders.


Creating business requirements and reviewing them with
business units & stakeholders.
Creating functional requirements & use cases based on the
business requirements.
Prioritizing requirements, using metrics like ROI.
Other similar activities with longer-term focus on meeting
business needs.
On the other hand, Agile sprint teams (including POs) tend to
have much more of a short-term focus. They are usually laserfocused on the current sprint (i.e. the next 2 weeks).
As a result of this difference in focus, How can our BA team
follow Agile process too? is often the wrong question. What is
the right question then?

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 8

8. The Right Question


A far better question for most companies is:

How can our BA teams work well with


Agile development teams?
Please note how this question shifts the focus to how BA
teams can work well with Development teams who use Agile
processes rather than following Agile processes themselves.
The rest of this document focuses on answering this question.

RIGHT Question:
How can our BA
team work better with
our Agile development
teams?

he n!
t
s
o
is i uesti
h
T
t q
h
g
i
r

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 9

9. Practical Tips for BA Teams Adapting to Agile


Development
I recommend that you
keep your BA team as
is - and add a new PO
(Product Owner) team
to your organization.

VP/Director,
BA

Manager, BA

Manager, PO

In my role at Accompa, Ive worked with BA teams at a number of mid-tolarge companies whose Development teams have transitioned to an Agile
process. Based on this, Id like to propose the following tips to BA teams.
Avast! Not all of these tips may work for your team - feel free to choose what
applies best, and adapt as needed.
1. Organization Structure:
A. I recommend that you keep your BA organization as is, and add a new
PO (Product Owner) team. See organization chart to the left.
B. PO team can be either within the BA organization or within the
Development organization. Pick the option that makes the best sense for
your company.
i. If in doubt, I recommend creating the PO team within your BA
organization.
2. Roles & Responsibilities:
A. BAs maintain a longer-term focus. They:
i. Create and manage themes and epics.
ii. Prioritize themes and epics working with business units.
iii. Create and manage project backlog for the project.
iv. Prioritize project backlog.
B. Before each release, BAs deliver release backlog to POs.
C. POs maintain a short-term focus. They:
i. Split release backlog delivered by BAs & organize them into sprints.
Break down stories to create smaller stories when needed.
ii. Dene acceptance criteria for each story.
iii. Prioritize stories within a sprint.
iv. Deliver sprint backlog to Development teams.
v. Attend daily sprint meetings with the SM & Development team, be
always available to answer questions from the sprint team, and act

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 10

Practical Tips for BA Teams Adapting to Agile Development


POs are full-time members
of sprint teams.
BAs, on the other hand, are
NOT - their interests are
represented in the sprint
teams by POs.

as the nal authority representing customer interest within the sprint


team.
vi. Work with BAs, UI designers, and others to create detailed
requirements for stories in upcoming sprints.
D. POs are full-time members (and integral part) of sprint teams. On the
other hand, BAs are not an integral part of sprint teams - their interests
are represented in the sprint teams by POs.
The following image depicts the approach I recommend:
(BA, PO)
Detailed
Requirements

24
hour

Daily sprint
meeting

1-4
weeks

BAs focus on longer-term


project backlog.
POs focus on short-term
sprint backlog.

Project Backlog
(BA)

Sprint
Backlog
(PO)

Sprint
(PO)

Working
Increment
of Software

Figure 3: How BA teams can successfully work with Agile Development teams
As you can see, BAs focus on longer-term project backlog (themes, epics, and
high-level stories), whereas POs focus on short-term sprint backlog.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 11

10. Best Practices - BA Teams Using Accompa for Agile


As Accompa is very
flexible, it is being used
by BA teams to manage
requirements for Agile
projects, traditional
waterfall projects, as well
as hybrid projects.

Note: This section is targeted at BA teams who are already using Accompa
cloud software. If your team is not yet using Accompa, you can just skim this
section to get a rough idea.
As Accompa cloud software is very exible, BA teams at more than 100
companies of all sizes - from Fortune 500s to growing startups - use it to manage
requirements for Agile projects, traditional waterfall projects, as well as hybrid
(hybrid of Agile and waterfall) projects.
Here are some best practices weve identied from discussions with BA teams
who use Accompa to manage requirements for Agile projects:
Gather requests from business units & stakeholder groups using SmartForms
& SmartEmails in Accompa.
Prioritize requests, working with business units, through the ROI Score and
Polls features in Accompa.
Create and manage themes using the Custom Object feature in
Accompa.
Use Accompa to create and manage epics. The Requirements object in
Accompa can be easily customized to do this.
If needed, create and manage high-level user stories using the Custom
Object feature in Accompa.
Use SmartViews feature in Accompa to group and manage data such as:
-- All epics for a theme.
-- All epics & user stories for a project. (Long-term project backlog)
-- All user stories for a theme.
Use Relationships feature in Accompa to track relationships between
themes, epics, and stories.
Prior to a release, clone the Project Backlog SmartView and apply
additional lter criteria in order to create the Release Backlog
SmartView. These additional criteria can be as simple as Release =
Release-5 or can be more complex depending on your needs.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 12

Best Practices - BA Teams Using Accompa for Agile


Export the Release Backlog SmartView to Excel, and deliver that to POs.
POs can then import this into the Agile development tool being used by
their Development team.
-- Accompa also offers turnkey integration to popular Agile development
tools - such as Rally, VersionOne, JIRA, etc.
-- POs then create/expand user stories, and write acceptance criteria and manage these in the Agile development tool.

AGILE

Tool
Accompa

A
y B jects
b
e
o
sag gile pr
u
l
Too s in A
m
tea

Used
By

DEV
TOOL

(JIRA, Rally, VersionOne)

PO
BA

SM

PO
Dev Team

Used
For

Longer-term Focus

Short-term Focus (Sprints)

Project Backlog

Sprint/Release Backlog

Detailed Requirements

User Stories (Pointers to Reqs)

Business Needs

Sprint Tasks

ROI Analysis

Burndown Analysis

Figure 4: Tools used by BA and Development teams in Agile process


A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 13

Best Practices - BA Teams Using Accompa for Agile


Once a release is completed, mark the appropriate stories in the
corresponding SmartView as Completed using Mass Update feature.
Whether youre currently an Accompa customer or not - well be happy to
help you set up Accompa so that your BA team can effectively & efficiently
manage business requirements and functional requirements for Agile
projects.
Feel free to contact us, well set up a call promptly to understand your needs
and share best practices for meeting them.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 14

11. Frequently Asked Questions


BAs add value by
defining the right
things to build
whereas POs add
value by helping
build things right.

1. Can we eliminate the Business Analyst (BA) role in our organization, and
convert the BAs to Product Owners (PO)?
This is generally a very bad idea. The reason is as follows:
As we discussed earlier in this guide, BAs add the most value to your
organization by having a longer-term focus. This helps them understand
business needs, elicit requirements from all stakeholder groups and
convert these into long-term project requirements.
On the other hand, POs are required to have a short-term focus to
ensure that the current sprint is successful.
One way to think about this is:
BAs add value by helping define the right things to build whereas POs add
value by helping build things right.
If you eliminate the BA role and convert your BAs to POs it is very likely that
your projects long-term health will suffer.
2. Can we ask our BAs to play the PO role too?
This is also generally a bad idea. As we discussed above, BAs need to have
longer-term focus to be successful, whereas POs need to have short-term
focus to be successful.
Asking the same person to be both BA and PO is like asking the same
person to be:
A patient long-term buy/hold investor (a la Warren Buffett)
- and simultaneously A frantic, hair-on-fire day trader
If your organization is very small (for example: 3 programmers & 1 BA) and
you simply cannot afford another headcount you may be able to get
away with the same person playing both roles. That said, people who can
play both roles effectively (and simultaneously) are extremely rare.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 15

Frequently Asked Questions


In almost all other scenarios, asking the same person to play both the BA and
PO role is very likely a recipe for disaster.
3. Are detailed requirements really needed when following an Agile process?

It is best to think
of a user story
as a pointer to
a requirement
rather than as a
requirement itself.

This is a somewhat controversial question, as some Agile development teams


seem to think detailed requirements are evil. Im only slightly exaggerating!
However, for software of any complexity, most companies Ive spoken with
find it nearly impossible to build the software using just user stories.
The best answer to this question perhaps comes from Mike Cohn, one of
the best-known proponents of Agile and the author of the popular book
User Stories Applied: For Agile Software Development. Cohn has said: I
like to think of a user story as a pointer to a requirement rather than as a
requirement itself.
I believe this is a very important distinction to understand.
While user stories are great for planning sprints and following Scrum (or
other Agile processes) they are often woefully insufficient to document
all the requirements for a software of any complexity.
As a result, for many stories it is indeed necessary to create detailed
requirements, while using the stories as pointers to these requirements.
4. Where do we document detailed requirements (our Agile tool doesnt seem
equipped to do so)?
I recommend that you document detailed requirements using tools such as:
Small companies:
Microsoft Word, Google Docs, and Wikis.
Medium & large companies:
Accompa or a similar tool. Such tools allow your team to document
detailed requirements using structured data.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 16

Frequently Asked Questions


Then, you can point the user story to the detailed requirement. Accompa,
for example, offers turnkey integration with popular Agile tools (such as Rally,
VersionOne, and JIRA) to allow easy creation of such pointers.
5. When exactly should we write detailed requirements?

Many companies
find it beneficial
to create detailed
requirements for
stories in a sprint
backlog before that
sprint starts.

Many companies I speak with find it beneficial to create detailed


requirements associated with stories in a sprint backlog before that sprint
starts. This helps them with more effective sprint planning.
The following approach works well for many of them:
Creating detailed requirements 1 sprint in advance. This usually
translates to 2 to 4 weeks in advance.
Please note:
-- Detailed requirements for Agile projects are written iteratively. This
means: You do not need to make the detailed requirement 100%
comprehensive, like traditional waterfall projects. Instead, a detailed
requirement simply provides additional details for a story within the
context of that particular sprint.
-- Even when you create detailed requirements before a sprint starts,
youll still need to update them at the beginning of a sprint based on
questions from your Development team.
-- Creating detailed requirements too far in advance of a sprint will
diminish some of the key benefits of Agile.
6. Who writes the detailed requirements that stories point to?
Detailed requirements are usually written by someone with the following job
titles:
Business Analyst.
Product Owner.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 17

Frequently Asked Questions


7. How are the following related: Project backlog, Release backlog, and Sprint
backlog?
Project backlog consists of all items planned for the project, it is created and
maintained by the Business Analyst (BA). At the beginning of a release, items
are moved from the project backlog to the release backlog - this is done
by the BA in collaboration with the Product Owner (PO). At the beginning of
each sprint, items are moved from the release backlog to the sprint backlog
by the PO.
8. Who prioritizes the work the Development team will perform during a sprint?

The Product Owner


(PO) prioritizes
the work for each
sprint. PO does this
by prioritizing the
Sprint Backlog.

The Product Owner (PO) prioritizes the work for each sprint.
However, the Development team often has leeway in terms of actual work
sequence, while taking into account the priority assigned by the PO.
9. Who answers the questions the Development team has about a user story, or
the detailed requirement it points to?
The Product Owner (PO) answers such questions. PO works with BAs, as
needed, to answer these questions.
10. What role does the Scrum Master play in writing user stories and
corresponding requirements?
Scrum Master (SM) focuses primarily on helping the Development team
follow the Scrum process. As such, SMs play little to no role in actually writing
the user stories and the requirements to which these stories point to.

Do you have other questions youd like to see addressed in this guide? Let
us know at agile-ebook@accompa.com. We will email you back with the
answers, and will add them to future editions of this guide.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 18

12. Land, Ho!

When Development teams at a company switch to an Agile development


process, BA teams face many pitfalls as they transition their own work
processes to accommodate this switch.
This guide summarizes practical tips BA teams can use to make a successful
transition - and ensure they continue to play a valuable role in completing
successful projects that meet business needs.
I hope you found it helpful. If you have questions about how your BA team
can use Accompa to effectively & efficiently manage requirements for
Agile projects (or for waterfall/hybrid projects) - feel free to contact us. Well
promptly set up a call to understand your needs and share the best practices
for meeting them.
Heres to your success, matey!

BA

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 19

13. Recommended Resources


1. User Stories Applied: For Agile Software Development by Mike Cohn
Excellent book on the topic of User Stories, by a leading proponent of Agile
software development.
2. Why Scrum?
Short article gives a good overview of Scrum.
3. Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
Excellent book by one of the original proponents of Scrum, the most
popular Agile methodology.

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 20

About the Author


Michael Shrivathsan, Vice President of Product Management, is responsible for
all Product Management activities at Accompa, Inc. Michael has nearly 20
years of experience in Product Management & Product Marketing for several
successful companies in Silicon Valley.
During his career, Michael has managed Product Management and related
teams (Product Marketing, Business Analysis, and UI Design teams) at companies
ranging from small start-ups to Fortune-500 companies.
He is passionate about helping companies build winning products. Michael and
the Accompa team have helped more than 100 companies - from Fortune 500s
to growing startups - to build more successful products, more efficiently.

About Accompa, Inc.


Our mission: To help you build more successful products, more efficiently.
Business Analysis, Product Management, and related teams at more than 100
companies of all sizes (from Fortune-500s to startups) use Accompa to gather,
track, and manage requirements for Agile, waterfall, and hybrid projects.
Accompa is 100% cloud-based and is easy to deploy and use. For more details,
see links below...
Learn more:
View Product Tour
Get FREE Trial
Request 1-on-1 Demo

A Practical Guide: Business Analysts & Agile Development | Accompa, Inc | Table of Contents | pg. 21

You might also like