You are on page 1of 22


0 to 60 Guide

Agile Business
Over the last ten years, Agile has grown from
relative obscurity to being the new standard for
product development. It has produced better
products faster, and teams have enjoyed the more
sustainable work pace.

But Agile wasnt designed with Business Analysts

in mind. We have had to forge our own path,
integrating analysis into the agile environment,
and creating a new role for ourselves.

This guide is designed to help you understand

your role and to grow in your agile business
analysis career.

We hope you find it to be of great use, and we

look forward to your feedback.

Don Hussey

Managing Director
NorwalkAberdeen 2 2017 NorwalkAberdeen



What is

Agile is a new way to develop products, usually There are many ways to be agile. In this guide, we
software, but really anything. will usually refer to Scrum, the most popular
method. Where there are important differences
Its all about people. among the methods, we will call those out.

Its all about collaboration. Well talk a lot about process. But thats not the
point. Process is important, but not as important
Its all about mindset. as the items on the left.

Its all about continual improvement.

But in the end, its really all about creating

products your customers will love. 4 2017 NorwalkAberdeen
Individuals and Interactions
over processes and tools

Working Software
over comprehensive documentation Agile
Customer Collaboration Values
over contract negotiation

Responding to Change
over following a plan

All of Agile is wrapped up in these four values from the Agile In your organization, do people run the projects? Or do
Manifesto ( If you learn only one thing projects run the people?
from this guide, make it the values above.
As a Business Analyst, do you feel like you can let go of
We value all of the things listed above, but we value the lengthy documents in order to focus on the product your
things on the left more. customers will use?

Agile isnt about finding a new process or super-duper new Whats more important: working with your customers to
tool to control peoples lives. Its about valuing our colleagues, create something great, or sticking to the letter of the law as
products, customers, and flexibility. defined by a Statement of Work or contract?

If you follow these four values, it doesnt matter what When your market environment changes, do your projects
methodology your organization follows: you are agile. rapidly shift course? Or do you stick to the plan, even when
its no longer relevant? 5 2017 NorwalkAberdeen

Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile

processes harness change for the customer's competitive

Deliver working software frequently, from a couple of weeks to a

Agile couple of months, with a preference to the shorter timescale.

Principles Business people and developers must work together daily

throughout the project.

Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the job

The most efficient and effective method of conveying information

to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

The principles on the right can be found at Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
They are the principles that the various agile
methodologies are based on. Methodologies are Continuous attention to technical excellence and good design
enhances agility.
important, but remember that our values and
principles are what make us agile. Simplicity the art of maximizing the amount of work not done
is essential.

If you dont work on software, feel free to replace The best architectures, requirements, and designs emerge from
the word with product. self-organizing teams.

At regular intervals, the team reflects on how to become more

In the pages that follow, we will look at each one effective, then tunes and adjusts its behavior accordingly.
closely. 6 2017 NorwalkAberdeen
Our highest priority is to satisfy the customer through early and Deliver working software frequently, from a couple of weeks to a
continuous delivery of valuable software. couple of months, with a preference to the shorter timescale.

Everyone agrees that the customer comes first. But if our processes Imagine a project that is two years long, that delivers a product
arent set up to enable it, it wont happen. after that time is up. There are so many things that can go wrong:

Our customers want what they want, how they want it, and as soon The project can run late, preventing the customer from
as possible. The whole point of Agile is to make that a reality. getting the benefit the product provides
Market change may make the product irrelevant, causing
Have you ever been on a project status call where everyone the project to be canceled, and representing a complete
reported how things were going? Have you ever said, financial loss of investment
requirements are 25% complete? Customers arent focused on The need to deliver on a particular target date may force
that. They want to have actual product in their hands. Thats what management to incur unsustainable work hours on the
this principle is all about. project team, causing inefficiency and burn-out

By delivering a portion of the product every month, on average,

each of these risks is dramatically reduced, and the customer is
able to take advantage of the incremental benefits delivered.

Welcome changing requirements, even late in development. Agile Business people and developers must work together daily
processes harness change for the customer's competitive throughout the project.
BAs have often been referred to as bridges between business and
This principle turns requirements orthodoxy upside down. technology teams. We have certainly created value by helping the
Requirement change in waterfall projects can be financially two sides to find common understanding, but it has come with a
expensive and can wreak havoc on project schedules. cost.

However, we have to reconcile those issues with the reality that Bridges are almost always bottlenecks. As the business creates
businesses, industries, and markets are experiencing a higher analysis tasks for BAs and developers create hundred-question lists
degree of change than ever before, making many products for the BA to take up with the business, the process comes to a
obsolete even before theyre completed. standstill. And bridges can collapse in having one person ferry
between the two teams, the enterprise takes on the risk of having a
By delivering product functionality quickly and piecemeal and single point of failure in a key process.
giving customers direct control over feature prioritization, we have
the opportunity to adapt to change, keeping our teams and Instead, we agile Business Analysts ensure that the entire team
customers nimble. works closely together daily, freeing us up to do the analysis work
that will add the most value to our products and customers. 7 2017 NorwalkAberdeen

Build projects around motivated individuals. Give them the The most efficient and effective method of conveying information
environment and support they need, and trust them to get the job to and within a development team is face-to-face conversation.
Face-to-face communication is critical. Some methodologies even
Its a bad management technique to put your people in a difficult mandate that the team and customers be located in the same
situation where they dont have the tools to do the job and then workspace. Why is it so important? Speeding up collaboration,
put pressure on them to deliver. But we see this all the time in the cutting down on waiting time, and building team identity are only
work place. Instead, agile teams are given the resources they need a few of the reasons.
to get the job done.
You might say, But our developers are in another
The team is all-important in Agile. They are 100% responsible for city/country/time zone! Thats okay to be agile is to be flexible.
creating, testing, and delivering the product. They need Use webcams. Talk with teammates one-on-one by phone. Keep
management support to get this done. your conversations with them informal. These work-arounds can
compensate for not being co-located and will pay dividends over
the short-term and long-term.

Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
The customer doesnt care about requirement documents. The indefinitely.
customer doesnt care what the code looks like. The customer
doesnt care about milestones or story velocity or burn-down Working long hours over the long-term will burn out the team and
charts. The customer only cares about the product features make you ineffective.
delivered and their quality.
Customers dont care how long or hard you work. They just want
Accordingly, that is how we measure progress on agile projects. their product.
Since user stories represent blocks of working product, we use
them to gauge how well we are doing. Focus on creating a work environment that is effective. Fine-tune
your working processes to maximize the utility of each day and
So, yes, the internal metrics of story velocity and burn-down charts hour. By doing this, youll increase your productivity and set up a
do matter to us. But remember that the ultimate goal is getting sustainable process that can run indefinitely without crashes.
great product into the customers hands. 8 2017 NorwalkAberdeen

Continuous attention to technical excellence and good design Simplicity the art of maximizing the amount of work not done
enhances agility. is essential.

One criticism of Agile that holds some degree of merit is that it Work smarter, not harder is often a dictum given by
gives short shrift to technical design. Many teams have jumped management to teams that are forced to work around constraints
right into development without first ensuring that the design is and insufficient amounts of resources to get the work done.
tenable, and many more have failed to maintain it as their projects
have evolved. But thats exactly what we need to do. We must be lean in our
approach to the work. We will not program code that we dont
Theyve ignored this principle to the detriment of their product and need for this sprint/iteration. We will not write excessive
customers. In agile projects, the team must always be designing documentation that isnt useful. We will take sensible shortcuts
and refining their product. whenever possible.

Similarly, we Business Analysts must constantly be focused on But we will never compromise on the quality of our product.
refining our work products. Is the backlog properly prioritized? Are
there missing elements that we should be working on instead? Are
acceptance criteria up to snuff? These all enhance agility too.

The best architectures, requirements, and designs emerge from At regular intervals, the team reflects on how to become more
self-organizing teams. effective, then tunes and adjusts its behavior accordingly.

When you go to the grocery store with your significant other, how Some things dont work. Some practices are inefficient or counter-
do you shop? productive. Some things that initially seem like a good idea
arent. As Agilists, we are committed to regularly considering how
Do you have some third party directing you on what to buy and in we do the work and improving it.
which order? Do you figure out roles before you go into the store
and stick rigidly to them throughout the trip? The more often we do this, the better our process becomes and
the less we become attached to bad practices.
Or do you simply have a list of needed items, communicate with
each other while shopping, and separate as necessary to pick up

Thats self-organization. The team members understand the work

that needs to be done, and they do it without management
directing their steps. It requires communication and trust and is
hyper-effective. 9 2017 NorwalkAberdeen


The mindset of a project team member

varies considerably between agile and Mindset:
waterfall projects.
Agilists tend to value flexibility over vs. Agile
predictive planning.

Waterfall Agile
At the beginning of the project, we will determine what At the beginning of the project, we will establish the
needs to be done, predict how long each activity will take, team and the product vision. We will plan sprints at a
Plan assign each activity to responsible parties, and deliver high level, but postpone detailed planning change
according to schedule. occurs rapidly, and we need to adapt to it.
We will define project scope at the beginning of the project. We will help the Product Owner to set scope as she sees
When the scope is delivered, we will know our work is fit. No one knows exactly what the scope should be at
Scope complete. Changes to scope must be approved by senior the beginning, and shell need flexibility to keep up with
management. the marketplace.
As the Business Analyst, requirements are my most As a team member, I am jointly responsible for
important contribution to the project. Ill devote delivering the most valuable possible product to our
Requirements considerable upfront time to ensuring the requirements are customers. I will work with the PO, customers, and team
as perfect as possible. to contribute however I can.
Change represents both risk and opportunity. We need to Change happens constantly, and its often counter-
Change keep an eye on trends to make sure we are not blind-sided. intuitive. We will be nimble and adapt to it as it unfolds. 10 2017 NorwalkAberdeen




Team Members Product Owner ScrumMaster

Responsible for creating the Business representative to Servant leader focused on
product the team overcoming team obstacles
Design, develop, test, and Acts as the business owner of the Runs the Scrum process for the
implement the product product team
Estimate the effort of each user Determines priority and ranking Radiates information to the team,
story of product backlog items ensuring everyone is updated
Determine sprint scope and own Writes the majority of user stories Seeks to overcome impediments
the commitment to the business and acceptance criteria to help team remain focused on
Create and manage delivery delivering the product
plans 12 2017 NorwalkAberdeen


All the agile methodologies lack an explicit

Business Analyst role. This is where self-
organization comes into play. The
The Business Analyst must determine
which role he must play, based on team
dynamics and the organizations need.

BA as Team Member BA as PO Assistant/Proxy BA as Product Owner

Helps create the product Catalyzes product ownership Represents the business
Performs all the duties of a team Works extremely closely with the Performs all the duties of the
member (typically excluding the Product Owner to enable the PO Product Owner, typically under
technical work) to effectively handle her role the direction of a senior product
Works with the Product Owner to Writes the majority of the user manager
develop user stories and their stories and acceptance criteria,
acceptance criteria Provides input to the PO on
Works with the rest of the team prioritization and dependencies
to address business-related Assists the PO with backlog
spikes and obstacles management and story mapping
Proxies have additional decision-
making authority 13 2017 NorwalkAberdeen




On agile projects, we typically document requirements in terms of Examples

user stories.

User stories are bite-sized statements of functionality desired by a As a Sales Manager,

certain type of stakeholder for a particular reason. They are I want to see a report of daily customer contacts,
typically a single sentence long, with the following format: So I can effectively manage my team.

As a __________________________ (role)
I want __________________________ (requirement) As a Marketing Analyst,
So I __________________________ (rationale) I want a chart showing web page traffic over time,
So I can gauge how effective content changes are.
User stories are not lengthy specifications of every last detail of the
feature. Indeed, user stories are often written on index cards. Scott
As a blogger,
Ambler described the user story as a reminder to have a
I want to be able to apply HTML styling to my blog posts,
conversation with your customer, and thats about right.
So I can adequately structure my content.
They dont have to be perfect, only understandable to the reader. 15 2017 NorwalkAberdeen



Just as user stories are high-level expressions of requirements, Examples

acceptance criteria specify the details that testers should check
when verifying a user story is complete and defect-free. User Story:
As a blogger,
Developers use them as kind of a checklist when developing the
I want to be able to apply HTML styling to my blog posts,
feature and writing automated tests for it. In that way, acceptance
So I can adequately structure my content.
criteria act as requirements also.
Acceptance Criteria:
Try to keep your acceptance criteria succinct and to the point. Just
like user stories, they can be as informal as the team can handle. User can italicize, bold, and underline text.
Theyre not fancy test scripts. User can create numbered and bulleted lists.
Acceptance criteria are the flip-side to the user story literally. If User can indent and unindent text.
youre writing the user story on an index card, the acceptance User can change the font to any of the following: Arial,
criteria go on the other side. Helvetica, Times New Roman, Calibri, Courier, Wingdings. 16 2017 NorwalkAberdeen


Epics are user stories that are too big to

effectively complete in a single sprint. A
user story typically comprises no more
Epics: than 1/6 of the teams velocity.
Splitting Instead of working on epics directly, the
Stories team decomposes them into user stories
what we usually call story-splitting.

Here are some strategies to do that.

Functional Breaking a function into
Author blog post
Edit blog post
Decomposition smaller sub-functions
Publish blog post

EXAMPLES Epic Choose account type

Process Breaking up a process into
sub-processes or process
Submit identification
Bank account
Decomposition steps opening
Request debit card

Structural Breaking a complex item up
Site traffic chart
Social media summary
Decomposition into smaller pieces
dashboard E-mail metrics table 17 2017 NorwalkAberdeen


Agile in Action
11:00 Okay, the PO said that blogging is a new high-
priority epic. He asked me to break it down into
features and stories and review with him later.

11:45 It seems like the core features are: (1) Authoring

blogs, reading blogs, and integrating calls-to-
action. Im going to break stories out that way.
A Day in
the Life 1:15 I have lunch in my cubicle today there is a
webinar (from NorwalkAberdeen, of course)
that I want to catch up on.

2:00 One of the developers calls me over to help

figure out a solution with the data architect. We
apparently need some data we dont have.
Agile doesnt fix all problems, unfortunately.

3:00 I reviewed the blogging epic/features/stories

8:30 I arrive to work, chat with a team member, and with the PO. He said that we should add
go through e-mail. tagging as a feature. He wants to get all the
functionality done over the next two sprints. Ill
9:00 Daily scrum. One of the developers said there
have to spend some more time prioritizing the
are inconsistencies between two stories; Ill
backlog with him over the next couple days.
meet up with her later to figure it out.
4:25 Gave a heads-up to the ScrumMaster that we
9:30 Chatted with the developer. No inconsistency
would likely be shifting gears in the next sprint
after all, but we ended up clearing up lots of
to handle blogging. She shrugged and said,
other questions she had.
10:15 Had a conversation with one of our
5:00 I go home, instead of working another five
salespeople. He has a lot of blogging
hours. Agile is all about maintaining a
requirements. Ill have to chat with the PO.
sustainable pace. 19 2017 NorwalkAberdeen


The Agile mindset is crucial. Mastering and

integrating the values and principles of the Agile
Manifesto is more important than learning any
Never walk into a retrospective without first
considering how you and your team can improve.
Throughout the sprint, jot down ideas, and share
them with the team at the retrospective.

Keep user stories short. Dont depend on them as Dont worry too much about agile processes. Its
documentation. Consider them reminders to have valuable to learn the process, but its more
a conversation about the requirements. valuable to create a collaborative spirit in your

Keep acceptance criteria simple. Dont depend on The most effective Agilists are a combination of
them as documentation either. Consider them purist and pragmatist. Knowing when to strive for
reminders about things to test and verify. adherence to agile methods and when to simply
get the job done most expediently is a sign of
leadership. 20 2017 NorwalkAberdeen

Adaptive Planning An approach to planning in which plan details
are more detailed in the short term and less
detailed in the long term, enabling flexibility
and adaptation to change.
Agile An approach to product development
characterized by close collaboration with
customers, short and iterative delivery, and
sustainable work pace.
Glossary Agile Manifesto A collection of four values and twelve
principles published in 2001, which laid the
groundwork for agile software development.
Backlog A collection of planned work items.
Burn-Down Chart A chart depicting the remaining amount of
work to be delivered in a sprint, usually
broken down by day.

Daily Scrum A daily Scrum meeting in which team Sprint A 1- to 4-week iteration, producing a
members summarize the previous days releasable version of the product.
accomplishments, their plans for the current Sprint Backlog The list of user stories comprising the scope of
day, and any impediments they face. the sprint.
Daily Stand-Up Term popularized by Extreme Programming, Story Point An arbitrarily-scored metric reflecting a
equivalent to the Daily Scrum. relative amount of product development
Epic A requirement statement or category that is effort.
too big to deliver effectively in a single sprint. Story-Splitting The process of breaking epics and large user
Predictive Planning An approach to planning in which stories into smaller, more manageable stories.
management makes predictions about team User Story A short statement of a product users need,
productivity and external factors and bases specifying the user type and rationale.
plans around those predictions.
Velocity The number of story points delivered by a
Product Backlog The list of user stories that have not yet been team in the course of a sprint.
assigned to a particular sprint.
Waterfall A phased approach to software development
Spike A work item representing issue resolution or in which a phase does not begin until the
research. previous phases work is complete. 22 2017 NorwalkAberdeen