Agile business analysis v1 sample

Agile business analysis
© Adaptive Processes Requirements excellence! Page | 1 of 182
Copyright notice
All rights reserved.
All trademarks of copyrights mentioned herein are the possession of their
respective owners. We make no claim of ownership by the mention of products
that contain these marks.
Contents of this document should not be disclosed to any unauthorized
person. This document may not, in whole or in part, be reduced, reproduced,
stored in a retrieval system, translated, or transmitted in any form or by
any means, electronic or mechanical.

Introduction
As the book title suggests, this book is a guidebook for the agile business
analysts. We value your time and hence the book is designed to be extremely
specific to agile business analysis.
This book is authored by qualified business analyst who has worked as agile
business analyst.
Feedbacks and suggestions on the book
We will be glad and thankful if you can share your feedbacks and
suggestions on the book. Please send your feedbacks and suggestions to
Info@AdaptiveProcesses.com.

Table of contents
ABOUT ADAPTIVE PROCESSES CONSULTING ........................................... 7
ADAPTIVE WORKSHOPS CATALOGUE .................................................. 9
1. WHAT AND WHY OF AGILE BA ................................................. 11
Who are Agile BAs anyway?.................................................. 11
But then Scrum DOES NOT have a role for business analysis?................. 11
What is Business Analysis?................................................. 12
What is Agile Business Analysis?........................................... 13
BTW, what are requirements?................................................ 14
Are there different types of requirements?................................. 14
Why requirements are crucial to project success?........................... 18
2. UNDERSTANDING AGILE PROCESS .............................................. 19
Why traditional waterfall failed?.......................................... 19
How can one fix issues with traditional waterfall failed?.................. 20
Agile manifesto............................................................ 21
Principles behind the Agile Manifesto...................................... 22
Now what’s Scrum?......................................................... 24
3. AGILE BA RESPONSIBILITIES AND SKILLS ..................................... 35
Expectations from an Agile BA.............................................. 35
KEY SKILLS FOR AN AGILE BA....................................................... 36
Communication – Oral and written.......................................... 36
Stakeholder management..................................................... 41
Knowledge of business and specific industry................................ 46
Knowledge of the organization.............................................. 48
Knowledge of the solution.................................................. 49
Knowledge of Agile BA process.............................................. 49

Knowledge of elicitation and modeling techniques........................... 50
Knowledge of office tools and modeling tools............................... 50
4. PLAN BUSINESS ANALYSIS ................................................... 51
TECHNIQUES FOR PLANNING ......................................................... 51
Acceptance criteria........................................................ 51
Release planning........................................................... 52
Sprint planning............................................................ 52
Stakeholder list........................................................... 53
Time boxing................................................................ 54
ACTIVITIES .................................................................... 55
Understand and document system context..................................... 55
Identify requirements sources.............................................. 57
Identify and prioritize stakeholders....................................... 59
Define constraints......................................................... 63
Decide on Agile requirements management tools.............................. 65
Plan releases.............................................................. 66
Plan sprints............................................................... 67
5. ELICIT REQUIREMENTS ...................................................... 69
Steps of elicitation....................................................... 70
Common challenges in elicitation........................................... 72
Impact of communication on requirements.................................... 72
Understanding transformational effects..................................... 73
Modeling requirements...................................................... 75
ELICITATION TECHNIQUES .......................................................... 76
Activity diagrams.......................................................... 76
Business rules catalog..................................................... 78
Document analysis.......................................................... 79

Implicit requirements analysis............................................. 81
Interface analysis......................................................... 82
Interviews................................................................. 83
Matrix Model............................................................... 87
Non-Functional requirements................................................ 87
Observation................................................................ 90
Persona.................................................................... 92
Problem tracking........................................................... 94
Process modeling........................................................... 97
Prototyping................................................................ 98
Requirements workshops.................................................... 103
State chart diagram....................................................... 106
User stories.............................................................. 107
ELICITATION ACTIVITIES ......................................................... 109
Determine suitable elicitation techniques................................. 109
Prepare for eliciting requirements........................................ 110
Elicit requirements....................................................... 112
Document elicitation results.............................................. 118
Confirm elicitation results............................................... 120
6. MANAGING REQUIREMENTS ................................................... 123
Requirements life cycle................................................... 124
Significance of requirements conflicts.................................... 125
Manage requirements conflicts............................................. 126
TECHNIQUES FOR REQUIREMENTS MANAGEMENT ............................................ 129
Impact analysis........................................................... 129
Inspection, aka formal / technical review................................. 130
MoSCoW.................................................................... 133

Post it notes............................................................. 133
Sprint retrospective...................................................... 134
Sprint review............................................................. 135
Structured walkthrough.................................................... 136
Walk-through, aka lightweight review...................................... 141
Workarounds............................................................... 143
Agile requirements effort estimation...................................... 144
Agile requirements communication.......................................... 144
ACTIVITIES ................................................................... 145
Agile requirements management process..................................... 145
Manage requirements traceability.......................................... 151
Maintain requirements for re-use.......................................... 155
7. DOCUMENT REQUIREMENTS ................................................... 157
QUALITY CRITERIA FOR REQUIREMENTS ................................................ 159
ACTIVITIES ................................................................... 161
Establish project glossary................................................ 161
Organize requirements..................................................... 163
Prepare initial requirements package...................................... 164
Prepare final requirements package........................................ 166
8. VALIDATE SOLUTION ....................................................... 167
ACTIVITIES ................................................................... 167
Validate design models.................................................... 167
Define transition requirements............................................ 173
Validate solution......................................................... 176
Identify workarounds and future improvements.............................. 177

About Adaptive Processes Consulting
Adaptive Processes is a leading global
player helping its clients improve their
business analysis and business analysis
capabilities and practices.
Our values
Key facts
Consulting, training, staffing
and products for business
analysis and business analysis.
200+ person-years consulting
experience.
200+ Clients across the globe.
10+ Fortune 500 clients.
Successfully conducted 200+
workshops in India, US, Thailand,
Philippines, Malaysia.

Unique benefits of working with us
Our key clients
Govern
ment

Adaptive workshops catalogue
Category Course Name
Business analysis Certified Business Analyst Professional (CBAP® )
(Endorsed by IIBA® , Canada)
Business analysis Certification of Capability in Business Analysis
(CCBA) (Endorsed by IIBA® , Canada)
Business analysis Certified Professional in Requirements
Engineering(CPRE) (Endorsed by IREB, Germany)
Business analysis Elicitation techniques
Business analysis Requirements modeling using UML
Business analysis Behaviorial skills for Bas
Business analysis The ACE BA program
Agile Certified Agile Practitioner
Agile Introduction to Agile and Scrum
BSC Balance Score Card
CMMI CMMI for Services
CMMI Introduction to CMMI for Development
CMMI CMM Implementation Workshop
CoBIT Introduction to COBIT
Excel Excel for Executive Managers
ISO 27001 Certified ISO 27001 Implementer
ISO 27001 Certified ISO 27001 Internal Auditor
Project Management Introduction to MS-Project
Project Management Project Management Basics
Project Management Program Management Professional
Project Management Stakeholder Management
Six Sigma Six Sigma Green Belt

Project Management Certified Software Team Lead
Software Engineering Configuration Management
Software Engineering Good Programming Practices
Software Engineering Introduction to Software Quality
Software Engineering Requirements Management
Software Engineering Software Engineering Principles
Software Engineering Introduction to Software QA
Software Engineering Software Reviews
Software Engineering Software Testing Principles
Software Engineering Software Metrics
Software Engineering Statistics for Project Managers
Software Engineering Statistical Process Control
Please note that we modify course catalog based on changing business needs.
For the latest information, always refer to our web-site,
www.AdaptiveProcesses.com.

1. What and why of Agile BA
Who are Agile BAs anyway?
The world has moved to agile way of software development. We will learn
more details about agile processes in the next chapter. Since agile
projects operate in a different approach compared to plan driven approaches
such as waterfall approach, it is essential that business analysts learn to
work in agile projects.
We will use a simple definition of agile BAs – BAs who work in agile
approach based projects.
But then Scrum DOES NOT have a role for business
analysis?
Scrum is the MOST popular agile development approach. However, Scrum does
not mention role of a BA.
What Scrum provides is the product owner role.
Is product owner a BA?
Answer is yes. Product owner is indeed a BA.
Can there be business analysts other than product owner?
Again the answer is BA.
Additional business analysis capabilities are a requirement to detail out
product requirements. Product owner is typically a very senior person,
sometimes almost the Product owner in traditional projects. Obviously,

sponsor will not have the necessary bandwidth to get involved in detailing
requirements.
Also it may not be possible for the product owner to be available to the
scrum team and stakeholders as much time needed business analysts can work
as shadow product owner.
What is Business Analysis?
Business analysis is a broad term that depicts a wide variety of tasks,
starting from developing strategy for an organization to describing
stakeholders requirements into solution requirements.
Business analysis body of knowledge (BABoK®) defines business analysis as
“Business analysis is the practice of enabling change in an enterprise by
defining needs and recommending solutions that deliver value to
stakeholders.”
Business analysis enables an enterprise to articulate its needs, rationale
for change, and to design and describe solutions that can deliver value.
Business analysis can be performed within a project or across the
enterprise. It can be used to understand the current state, define future
state and determine activities required for transition.
Business analysis can be performed from various perspectives like agile,
business intelligence, information technology, business architecture,
business process management etc.

What is Agile Business Analysis?
From this books perspective, we will use the term “Agile Business
Analyst” as the Business Analyst who works in “Agile based projects”.
Agile business analysis is a systematic and disciplined approach to the
specification and management of requirements with the following goals:
1. Knowing the relevant requirements, achieving a consensus among the
stakeholders about these requirements, documenting them according to
given standards, and managing them systematically.
2. Understanding and documenting the stakeholders’ desires and needs,
they specifying and managing requirements to minimize the risk of
delivering a system that does not meet the stakeholders’ desires and
needs
For the purpose of this book which is targeted towards software business
analysts in agile projects, business analysis will primarily involve
following activities:
1. Act as shadow product owner
2. Interact with stakeholders to gather their needs
3. Understand requirements from other sources
4. Elaborate stakeholder requirements to solution requirements
5. Ensure requirements quality
6. Develop acceptance criteria
7. Test fulfilment of requirements

BTW, what are requirements?
IEEE Definition
A requirement is:
1. A condition or capability needed by a stakeholder to solve a problem or
achieve an objective.
2. A condition or capability to be met or possessed by a solution or
solution component to satisfy a contract, standard, specification, or
other formally imposed documents.
3. A requirement may be unstated, implied by or derived from other
requirements, or directly stated, and managed. One of the key objectives
of business analysis is to ensure requirements are visible to, and
understood by all stakeholders.
Requirements describe, but not limited to, past, present, and future
conditions or capabilities in an enterprise, organizational structures,
roles, processes, policies, rules, and information systems.
Are there different types of requirements?
Requirements
classification
Description
Business
requirements
Higher-level statements of needs, goals or objectives,
why a project has been initiated; its objectives,
metrics, needs of the organization as a whole. For
example: Adaptive to introduce trainings for global
customers.

Stakeholder
requirements
Needs of a particular stakeholder or class of
stakeholders, and how they interact with a solution. A
bridge between business requirements, and solution
requirements. For example, requirements from Trainer: A
web-based platform to conduct web-based training.
Solution
requirements
Characteristics of the solution that meets business
requirements, and stakeholder requirements. Categorized
into be functional, and non-functional.
Functional requirements describe behavior, and
information that the solution will manage, capabilities
that the system will be able to perform in terms of its
behaviors or operations, specific IT application actions
or responses. Typically linked to business processes or
operations that the organization manages.
Must provide video, audio, and text based interaction
between trainer, and participants.
Must have provision for both online and off-line
interactions.
Non-functional requirements, also known as quality or
supplementary requirements, capture environmental
conditions under which the solution must remain
effective, or qualities that the systems must have rather
than the behavior or functionality of the solution. For
example, requirements related to capacity, speed,
security, availability, information architecture, and UI
presentation.
Must have availability of more than 99.9% time for the
workshop duration.

Transition
requirements
Capabilities needed to facilitate transition from current
state of the enterprise to a desired future state, but
not be needed once the transition is complete. These
requirements are temporary in nature, and cannot be
developed until both an existing, and new solution are
defined. Typical transition requirements include data
conversion from existing systems, skill gaps to be
addressed etc.
Training of trainers on the new web-based platform.
Example of requirements:
Type of req. Description
Business To enable digital commerce for the organization.
Stakeholders
(Customer, Sales
Head, Finance etc.)
Sales Head
It must support payment by multiple methods such
as credit card, debit card, bank transfer.
Should be flexible for newer payment methods.
It must support multiple currencies.
Solution requirement
Target audience :
Developer
Payment amount – Can this be negative?
Is there a minimum order amount?
Is there a maximum order amount?
How many decimals to be supported?

Why requirements are crucial to project success?
It has been observed that 60% of IT projects do not meet intended business
objectives. 70% of the IT project problems are attributable to poor
business analysis. IT changes are too rapid for business. At the same time
most IT professionals not conversant with business. The project delivery
team delivers what has been described by agile business analysts.
Costs of fixing requirements defects usually increase exponentially with
each passing project phase. For instance, the effort to fix a requirements
defect is up to 20 times higher if the correction is done during
programming as opposed to fixing the same defect during business analysis
phase. If the defect is fixed during acceptance testing, effort involved
may be 100 times higher. This is especially true of non-functional
requirements as non-functional requirements tend to affect system
architecture more than functional requirements.

2. Understanding Agile Process
Why traditional waterfall failed?
Agile is probably the biggest buzzwords of software development industry.
But what is agile? Before Agile, we had plan driven approaches such a
Project Management Body of Knowledge (PMBoK) or Capability Maturity Model
(CMMI).
Traditional waterfall worked in the following manner:
These projects would have a dedicated requirements phase which may take
anywhere between 3 months to 6 months. Then equal amount of time will be
spent on design. Construction will be double the time and testing will be
similar to requirements phase. Deployment will be slightly smaller.
Overall, we will end up with project durations ranging anywhere between 2
to 4 years.
These are typical numbers, sometimes projects can even be 5 years long.
Over this long period, few things happen:
1. There are changes in the need due to changes in market place.
2. Market places are changing rapidly due to rapid change in technologies.
3. Stakeholders did not have any opportunity to use and provide feedback on
the product. Finally when they get to see the product, they discover
many aspects.

4. It is extremely difficult to specify requirements, especially with
respect to usability aspects unless one uses the product.
Planned driven approach had a fixed goal and the project tried to meet the
goal.
All these finally results in a product which stakeholders do not find
meeting their needs. Now too many change requests come up (I had seen
projects where 600 change requests were raised during UAT). So the project
budget needs to be revised and the project misses its deadline. Also the
older methods demanded large amount of documentation to be created upfront
which literally go waste due to so high number of changes.
The problem with software products is users find it really hard to specify
their requirements well. All these issues forced software practitioners
which can overcome issues with waterfall approach.
How can one fix issues with traditional waterfall
failed?
The key drawback of the traditional waterfall model was the in-ordinate
long duration of the waterfall. The 2nd
major drawback was stakeholders
typically saw the product at the end of project. Now what happens if we
divide the projects in many short waterfalls? This is exactly what agile
does. Agile is essentially waterfall in short cycles.

There are 2 major advantages:
1. We can course correct our plans if our needs change.
2. Get user feedbacks in a prompt manner.
Now if you observe the above diagram, team changed its course mid-way to
achieve the new goal. If the scrum team would have followed the original
plan, it would have reached a place which was no longer desired by
stakeholders.
Agile manifesto
We use of the word agile in this book derived from the agile manifesto.
Put simply, agile development is a different way of managing IT development
teams and projects.
A small group of software developers got together in 2001 to discuss their
feelings that the traditional approach to managing software development
projects. Projects were failing far too often as they did not meet user
expectations. They came up with the agile manifesto, which describes 4
important values.

Agile manifesto says:
We value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.”
Source: AgileManifesto.org
Principles behind the Agile Manifesto
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals.
6. Give them the environment and support they need, and trust them to get
the job done.
7. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.

8. Working software is the primary measure of progress.
9. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
10.Continuous attention to technical excellence and good design enhances
agility.
11.Simplicity--the art of maximizing the amount of work not done--is
essential.
12.The best architectures, requirements, and designs emerge from self-
organizing teams. At regular intervals, the scrum team reflects on how
to become more effective, then tunes and adjusts its behavior
accordingly.
Some more principles that can be followed during agile projects are:
1. Stakeholders collaborative and cooperate for project success
2. Active user involvement is extremely critical
3. Business sets priorities
4. Requirements can always but remain fixed for an agreed period
5. Capture initial requirements at a high level; keep them lightweight and
visual
6. Develop small, incremental releases and iterate
7. Focus on frequent delivery of products
8. Complete each feature before moving on to the next
9. Testing is embedded in every iteration – test early and often

Now what’s Scrum?
Scrum is an agile development method, which concentrates particularly on
how to manage tasks within a team-based development environment. Scrum is
the most popular and widely adopted agile method. This is because it is
relatively simple to implement and addresses many of the management issues
that have plagued IT development teams for decades.
A scrum team typically consists of around seven people who work together in
short, sustainable bursts of activity called sprints, with plenty of time
for review and reflection built in. One of the mantras of scrum is
“inspect and adapt,” and scrum teams are characterized by an intense
focus on continuous improvement—of their process, but also of the product.
Let us understand parts of scrum: the various roles, artifacts and events
that occupy the sprint cycle.
Roles
Scrum recognizes only three distinct roles: product owner, scrum master,
and team member:
Product Owner
The product owner is responsible for maximizing the return the business
gets on its software development investment (ROI). She achieves it by
directing the scrum team toward the most valuable work. Product owner
controls the implementation order, called priority in the product backlog.
In scrum, only product owner is authorized change the product backlog.
Product owner is responsible for developing requirements, often in the form
of user stories (egg, “As a <role>, I want <a feature>, so that I can
<accomplish something>”) and adding them to product backlog. Each of these

user stories, when implemented, will incrementally increase in the value of
the product.
Product Owner Role in a Nutshell:
• holds product vision represents the interests of the business
• represents business and customers
• owns the product backlog
• orders (prioritizes) the items in the product backlog
• creates acceptance criteria for the backlog items
• is available to answer team members’ questions
Scrum Master
Scrum master acts as a coach, guiding the scrum team to ever-higher levels
of cohesiveness, self-organization, and performance. Scrum master’s
deliverable is a high-performing, self-organizing team. She is team’s good
guide, its champion, and guardian, facilitator, and scrum expert. She
helps the scrum team learn and apply scrum related practices to the team's
best advantage.
She is constantly available to the scrum team to help them remove any
impediments or road-blocks that are keeping them from doing their work. She
is not scrum team. This is a peer position on the team, set apart by
knowledge and responsibilities not rank.
Scrum master role in a Nutshell:
• scrum expert and advisor

• coach
• impediment bulldozer
• facilitator
Scrum team member
High-performing scrum teams are highly collaborative and also self-
organizing. Team members doing the work have total authority over how the
work gets done. They decide which tools and techniques to use, and which
team members will work on which tasks. They create task estimates.
Scrum team should possess all skills needed to create a potentially
shippable product. This means Scrum team will have a team of specialists,
each contributing to the team's success. They do their specialist work
most often but also work outside their area of specialty to complete
backlog items. They need a mindset change from "doing my job" to "doing the
job." It is also a change in focus from "what we are doing" (work) to what
is getting done (results).
Team Member Role in a Nutshell:
• responsible for completing user stories to incrementally increase the
value of the product
• self-organizes to get all of the necessary work done
• creates and owns the estimates
• owns the “ how to do the work” decisions

• avoids siloed “not my job” thinking
Common Scrum team size is seven, plus or minus two. That is, from five to
nine. Fewer team members and the scrum team may not have enough variety of
skills to do all of the work needed to complete user stories. More team
members and the communication overhead starts to get excessive.
Scrum Artefacts
Product Backlog
Product backlog is the list of desired deliverables for the product. This
includes features, user stories, bug fixes, documentation changes, and
anything else that might be meaningful and valuable to produce. Product
backlog is ordered such that the most important backlog item, the one that
the scrum team should do next, is at the top of the list. Then comes 2nd
,
then 3rd
and so on.
Each story includes the following information:
1. Which users will benefit from the story (who it is for)
2. Brief description of the desired functionality (what needs to be built)
3. Reason why the story is valuable (why we should do it)
4. An estimate of work the story requires to implement
5. Acceptance criteria to determine that the story been implemented
correctly
Sprint Backlog
Sprint backlog is the team’s to do list for the sprint. Sprint has a
finite life-span, anywhere between 2 weeks to 2 months. Sprint backlog
includes the stories that the scrum team has committed to delivering this

sprint and their associated tasks. Stories are deliverables and are units
of value. Tasks are things that must be done, in order to deliver the
stories, and so tasks can be thought of as units of work. A story is
something a team delivers; a task is a bit of work that a person does. Each
story will normally require many tasks.
Burn Charts
A burn chart shows us the relationship between time and scope. Time is on
the horizontal X-axis and scope is on the vertical Y-axis.
A burn up chart shows us how much scope the scrum team has got done over a
period of time. Each time a deliverable / task are completed the line on
the chart moves up.
A burn down chart shows us what is left to do. In general remaining goes
down over time as the scrum team gets things done.
Task Board
Task boards make team's tasks are visible to everyone. The simplest task
board consists of three columns: to do, doing and done.
Tasks move across the board, providing visibility regarding which tasks are
done, which are in progress, and which are yet to be started.
Definition of Done

Definition of done defines what should be completed to declare a story to
be done. This may include aspects such as code written, code reviewed, unit
tests passing, regression tests passing, documentation written, product
owner sign-off, and so on.
Sprint Cycle
Sprint cycle is the foundational rhythm of the scrum process. This may be
called as sprint, a cycle or iteration. This is a fixed period of time
within which team completes few backlog items. At the end of each sprint,
the scrum team should deliver a potentially shippable product increment.
That is the quality high enough that the business could ship it to
customers.
The more frequently the scrum team delivers and demonstrates a potentially
shippable product increment, the more frequently the scrum team gets
feedback, which fuels the important inspect-and-adapt cycle.
Sprint Planning Meeting
Sprint planning marks the beginning of the sprint. During sprint planning
scrum team to commit to a set of deliverables for the sprint. Then the
scrum team identifies the tasks that must be completed in order to deliver
the agreed upon user stories. We recommend one to two hours of sprint
planning per week of development.
PART 1: “WHAT WILL SCRUM TEAM DO?”

Goal of this activity is to emerge with a set of “committed” stories that
the whole team believes they can deliver by the end of the sprint. Product
owner leads this part of the meeting.
Product owner presents user stories and acceptance criteria one by one, in
priority order. Scrum team members discuss it with the product owner and
review acceptance criteria to make sure they have a common understanding of
what is expected. Then the scrum team decides if they can commit to
delivering that story by the end of the sprint.
This process repeats for each story, until the scrum team feels that they
have exhausted development capacity.
Note the separation in authority: the product owner decides which stories
will be considered, but the scrum team members doing the actual work are
the ones who decide how much work they can take on.
PART 2: “HOW WILL WE DO IT?”
In this phase, the scrum team decomposes the selected stories into tasks.
Scrum team may also adjust the list of committed stories as they may
realize that they have signed up for too many or too few stories.
Output of the sprint planning meeting is the sprint backlog, list of all
the committed stories, with their associated tasks. Product owner agrees
not to ask for additional stories during the sprint, unless the scrum team
specifically asks for more.
Daily Scrum / Daily stand-up meeting

Agile business analysis v1 sample

More Related Content

What's hot (20)

Similar to Agile business analysis v1 sample (20)

More from LN Mishra CBAP (20)

Recently uploaded (20)

Agile business analysis v1 sample