Business Analysts and Agile Development - Practical Guide

: 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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Ahoy, Welcome to the Accompa Agile Voyage for BAs! So, What is Agile Anyhow? Agile Terminology: User Story, Product Owner, and Scrum Master More Agile Terminology: Epic and Theme vs. User Story What is Acceptance Criteria and Who Writes It? Even More Agile Terminology: Sprint vs. Release, Backlogs The Wrong Question The Right Question Practical Tips for BA Teams Adapting to Agile Development Best Practices - BA Teams Using Accompa for Agile Frequently Asked Questions Land, Ho! 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.
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 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.
User Story is a short, simple description of a feature, written from the perspective of a user.
Product Owner (PO) works closely with Development team during sprint, and acts as final authority representing customer interest.
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.
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. 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.
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.
ort line Rep
Figure 1: A Typical User Story
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
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. Now that weve got the key terminology out of the way (whew!), let us move on to the meat of this guide. Project
Releases
Sprints
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?
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
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.
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
VP/Director, BA
Manager, BA
Manager, PO
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
Daily sprint meeting
24 hour
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.
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.
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.
Tool
Accompa
(JIRA, Rally, VersionOne)
DEV TOOL
PO SM Dev Team
AGILE
A y B jects b e o sag gile pr u l Too s in A m tea
Used By
BA
PO
Used For
Longer-term Focus Project Backlog Detailed Requirements Business Needs ROI Analysis
Short-term Focus (Sprints) Sprint/Release Backlog User Stories (Pointers to Reqs) Sprint Tasks Burndown Analysis
Figure 4: Tools used by BA and Development teams in Agile process

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.
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.
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? 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.
It is best to think of a user story as a pointer to a requirement rather than as a requirement itself.

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.

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 [email protected]. We will email you back with the answers, and will add them to future editions of this guide.
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
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.
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

Business Analysts and Agile Development - Practical Guide

Uploaded by

Copyright:

Available Formats

Business Analysts and Agile Development - Practical Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Analysts and Agile Development - Practical Guide

Uploaded by

Copyright:

Available Formats

: 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

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

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

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

ort line Rep

Figure 1: A Typical User Story

5. What is Acceptance Criteria and Who Writes It?

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

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

7. The Wrong Question

How can our BA teams follow Agile process too?

8. The Right Question

9. Practical Tips for BA Teams Adapting to Agile Development

Practical Tips for BA Teams Adapting to Agile Development

Project Backlog (BA)

Sprint Backlog (PO)

Working Increment of Software

10. Best Practices - BA Teams Using Accompa for Agile

Best Practices - BA Teams Using Accompa for Agile

(JIRA, Rally, VersionOne)

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

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

Best Practices - BA Teams Using Accompa for Agile

11. Frequently Asked Questions

Frequently Asked Questions

Frequently Asked Questions

Frequently Asked Questions

12. Land, Ho!

13. Recommended Resources

About the Author

About Accompa, Inc.

You might also like