Business analysis in a agile software project management:

Set up sustainable process!

The purpose of this article is to describe the requirements management process and artifacts that
are compatible with agile software development, and counting we have a Business Analyst (BA)
during requirements elaboration. That is a process we use in my real projects for the last several
years and I believe and might be useful for you as well.

Stakeholders

Responsibilities

Only BA may change epics/features/user stories scope in JIRA. Business stakeholders approve
requirements in the form stated below in this document (e.g. specifications, epics, user stories) along
with acceptance criteria for development and later accept the implemented functionality.

Business requests can come to BA at any time and should be processed accordingly before taking
to development.

The stakeholders must provide all the necessary information required for successful implementation
and delivery.

New requests may come out of a broad array of methods that lead to new development ideas being
escalated for consideration. Typically those ideas will fall into one of two buckets:

1. Quick Hits - Requests to enhance an existing feature, address a bug, or conduct research
into a potential issue. These requests typically take less than a sprint (two weeks of duration)
for a single development team to complete once prioritized.

2. Strategic Objectives - Requests to modify existing features or develop new features which
will likely require several sprints of effort from the development team. These requests will
require prioritization before being assigned to a BA team member for requirement elicitation.

Communication Plan
Solution Design Planning - to collaboratively work out solution options for the new requirements
that passed the discovery process and reiterate unfinalized solutions from previous discussions. This
is a standing event but can be set up on demand to address immediate needs.

The Solution Design Planning process involves analyzing the problem and requirements specified in
Epics, identifying possible solutions, and selecting the best one based on various factors such as
feasibility, cost, and efficiency. These should serve as inputs to plan for delivery and update the
product roadmap.

Input - Jira issues (Epics for large features). The scope may be big enough so it might take more
than one sprint to design and implement. In this case, the following Solution Design Planning
meeting will be devoted to continuing solution elaboration.

Design is ahead of Development for at least 2 weeks.

Agenda - Prepared list of Epics with specified Purpose, Scenario Acceptance Criteria, etc.

Design Review - a meeting held during the design phase of a project to review and evaluate the
progress of the design work. The purpose of the meeting is to ensure that the design is meeting the
requirements and expectations of the stakeholders and that it is progressing according to schedule.

After the meeting, the feedback is analyzed and incorporated into the design, and any necessary
changes are made. The design is then revised and presented at a subsequent Design Review
meeting until the design is finalized and approved.

Input - Figma, Design Tasks in JIRA Ready for review.

Design check-in - ad-hoc meetings for dev implementation review and Q&A.

Input - Actual Implementation, Figma.

Backlog Grooming - a regular session where backlog items are discussed, reviewed, and
prioritized by BA and other team members. The primary goal of backlog grooming is to keep the
backlog up-to-date and ensure that backlog items are prepared for upcoming sprints.

Agenda - List of user stories labeled as "ForGrooming"

 Link to "ForGrooming" filter in JIRA: [link to your dashboard]

This list of user stories is added to the preliminary sprint in which they potentially can be
implemented. After the Grooming session priorities and an assigned sprint of the user stories may
be changed.

Sprint Planning - to define what can be delivered in the sprint and how that work will be achieved.
Sprint planning is done in collaboration with the whole scrum team.

Input - initially groomed and added to the sprint user stories

Requirements Elicitation
Requirements elicitation is conducted by using the following techniques, but not restricted to:

 Brainstorming
  Interface Analysis
 Interviews
 Observation
 Workshops
 Prototyping
 Market Analysis
 Focus Group
 Survey

Requirements Preparation Approach

The main approach to requirements preparation is Top-Down. This means that BA prepares
requirements from a very high-level (e.g. Business needs and goals) and uses step-by-step
elaboration of requirements to the most detailed level which is User Story with acceptance criteria.

Each User Story must meet the Definition of Ready (DoR) criteria to be included in a sprint scope.

Requirements assignment

Each BA of the team has its primary requirements area of responsibility (epics level) and secondary
ones (BAs Requirements Areas of Responsibility). Knowledge transfer between BAs and their
awareness of the full scope of product requirements is gained through weekly BA meetings.

Requirements Verification
Each requirement must meet the following verification standards:

# Term Description

Self-contained and capable of being understood independently from other requirements or

1 Atomic
designs

Enough to guide further work and at the appropriate level of detail for work to continue. The
2 Complete level of completeness required differs based on perspective or methodology, as well as the
point in the life cycle where the requirement is being examined or represented

Aligned with the identified needs of the stakeholders and not conflicting with other
3 Consistent
requirements

4 Concise Contains no extraneous and unnecessary content

 # Term Description

Reasonable and possible within the agreed-upon-risk, schedule, and budget, or considered
5 Feasible
feasible enough to investigate further through experiments or prototypes

The requirement must be clearly stated in such a way to make it clear whether a solution
6 Unambiguous
does or does not meet the associated need

Able to verify that the requirement or design has been fulfilled. Acceptable levels of
7 Testable
verifying fulfillment depend on the level of abstraction of the requirement or design

Ranked, grouped or negotiated in terms of importance and value against all other
8 Prioritized
requirements

Understandabl
9 Represented using the common terminology of the audience
e

Requirements Validation
Each requirement must have clear value in accordance with business goals and must be included in
the scope of the project/solution. If a requirement doesn't have a clear value, it's not a valid
requirement.

The validation process is ongoing and conducted during all phases of the requirements lifecycle, but
the main step in requirements validation is the approval of requirements by business stakeholders.

Product level: Theme - Success criteria: business goals are reached

Development team level: Epic - Acceptance criteria: validated on Production (close look, 2-3 weeks)
User story - Acceptance criteria: DoD is confirmed during a demo session

Requirements Prioritization
Each type of requirement (epic, user story, etc.) has its priority defined based on business value,
dependencies, efforts, related risks, and architecture.

The requirements prioritization process typically involves the following steps:

1. Identification: The first step is to identify the requirements, which involves gathering and
documenting all the features and functionalities that the software needs to have.
 2. Categorization: The next step is to categorize the requirements based on their business
value, technical feasibility, and user impact.
3. Evaluation: The requirements are evaluated based on various criteria such as their
importance, urgency, complexity, and cost.
4. Prioritization: The most important requirements are then discussed by the business, BA, and
the development team. Requirements are prioritized based on their impact on the business,
the end-users, and the project timeline.
5. Communication: Once the prioritization is done, the business is informed about the aligned
priorities.
6. Re-evaluation: The prioritization process is an iterative one, and requirements may need to
be re-evaluated and reprioritized based on changing circumstances, stakeholder feedback,
or new information.

Repriotization

If the priorities of user stories change during a sprint, it is important for the development team and
BA to communicate and address the changes as soon as possible. Here are some steps that can be
taken:

1. Identify the changes: The first step is to identify which user stories have had their priorities
changed and why. BA should communicate the changes to the development team and
explain the reasons for the change.
2. Assess the impact: The development team should assess the impact of the changes on the
sprint and the project as a whole. They should consider whether the changes will affect the
sprint goal or the project timeline and budget.
3. Re-prioritize: If the changes are significant, the development team and BA should re-
prioritize the user stories based on the new information. The new priorities should be
communicated to the team and any necessary adjustments made to the sprint backlog.
4. Adjust sprint plan: Depending on the extent of the changes, the development team may need
to adjust their sprint plan. They may need to add or remove user stories from the sprint
backlog or make changes to the sprint goal.
5. Communicate with stakeholders: It is important to communicate any changes in priorities to
the business. This helps to ensure that everyone is aware of the changes and can adjust
their expectations accordingly.
If the business wants to add new items to the sprint that have no design or requirements, it can be
challenging for the development team to accommodate these requests without impacting the sprint's
timeline or quality. Here are some steps that can be taken to address this situation:

1. Understand the request: The development team should ask the stakeholders to provide
more information about the new items they want to add. They should try to understand the
purpose of the request, the expected benefits, and the potential impact on the project.
2. Evaluate feasibility: Once the development team has a clear understanding of the request,
they should evaluate its feasibility. They should assess whether the new items can be
realistically added to the sprint without impacting the sprint's goals, quality, or timeline. For
that requirements must be estimable. If they're not then a prerequisite spike is required to
investigate the request.
3. Create requirements and design: If the new items are feasible and valuable, the BA team
should work with the business to gather necessary requirements and the designer should
work on the necessary design for the new items respectively. Once requirements and design
 are ready, it should be groomed, and based on the feedback and estimations from the
development team, it can be added to the current or next sprints.
4. Prioritize: The development team, BA and business should prioritize the new items along
with the existing user stories and tasks. The new items should be prioritized based on their
value, urgency, and impact on the project.
5. Communicate with stakeholders: The development team and BA should communicate the
impact of adding new items to the sprint to the business. They should explain how the new
items will affect the sprint's timeline and goals and what adjustments may be needed to
accommodate them.
6. Adjust the sprint plan: If new items are added to the sprint, the development team may need
to adjust the sprint plan to account for the changes. They may need to remove or defer other
user stories or tasks to make room for the new items.

Acceptance Management
Once a user story is developed, BA or real users test functionality according to the acceptance
management procedure.

User stories acceptance criteria

Each user story has at least one acceptance criterion which includes a short scenario or rule
description.

Acceptance criteria are documented in JIRA tickets.

Author: Olena Kapitanenko, Project Lead | Business Process Analyst