Responsibilities

1. Requirement Gathering and Backlog Refinement

o Weekly Sync-Up Call

Purpose: Align on upcoming features, clarify business goals,
and define scope.
Participants: Product Owner (PO), Project Manager (PM), BA,
Design Team, Operations (if required).

 Action Points:

 Discuss potential new requirements, user stories,

and feature enhancements.

 Identify dependencies or design requirements.

 Update the team on the status of current and

pending requirements.

o Task Assignment
After the Sync-Up Call:

 Tasks are assigned to BAs based on discussed priorities.

 BAs are responsible for translating meeting discussions

into actionable tasks and updating the backlog in JIRA.

o Requirement Drafting
Process for Drafting Requirements:

 BAs will create detailed user stories, acceptance criteria,

and other documentation based on task assignments.

 All user stories should include:

 Clear acceptance criteria.

 Dependencies, if any, such as design assets or API

integrations.

 User interface (UI) and user experience (UX)

considerations discussed with the Design Team.

 Risks or assumptions, documented for

transparency.
 o Peer Review

 Perform peer reviews of other BAs’ work to ensure

quality and consistency across documentation.

 Provide constructive feedback and collaborate to ensure

the team follows best practices.

o Backlog Updates

 All requirements are added to the backlog in JIRA with

assigned priority, labels, and due dates.

 Requirements should be linked to corresponding epics,

features, or tasks in JIRA for traceability.

 Regular updates are required to reflect the latest status

of each item.

o Review with Product Owner

 BAs conduct regular reviews of the backlog with the PO

to validate that requirements align with business goals.

 Adjustments and prioritizations are made based on

stakeholder feedback.

2. Preparation for Sprint

o Sprint Planning (Friday before Sprint)

 Ensure that all requirements planned for the sprint are

clear, actionable, and aligned with the team’s goals.

 Review user stories with Development (DEV) and Quality

Assurance (QA) teams to clarify any doubts.

 Move finalized requirements to "Ready for Sprint" status

in JIRA.

o Sprint Kick-Off (Day 1 of Sprint)

 Confirm all sprint goals with DEV, QA, and PM teams.

 Ensure that each team member understands the

requirements and acceptance criteria for each user
story.
3. Ongoing Sprint Activities

o Support During Development

 BAs should be available for questions or clarification

requests from the DEV and QA teams throughout the
sprint.

 Document any change requests or feedback received

during development and update user stories
accordingly.

o Requirement Tracking

 BAs monitor progress in JIRA, ensuring all tasks are

updated by end-of-day and that team members are
actively progressing through their work.

 Verify that completed requirements meet acceptance

criteria before moving to the next phase (e.g., testing).

4. Release Activities

o Release Notes

 Document key changes, new features, and bug fixes in

the release notes, providing a clear understanding of
updates.

 Upload release notes to the defined path, ensuring

accessibility for all relevant stakeholders.

o User Guide Updates

 Update any relevant user guides or documentation to

reflect new features or changes in the release.

 Verify that documentation is clear, concise, and aligns

with user expectations.

o Production Readiness Email

 Once all release-related tasks (QA, bug fixes,

documentation) are marked as complete, send an email
to notify the team and stakeholders that the build is
ready for production.
  Include a link to release notes, updated user guides, and
highlight key points.

5. Post-Sprint and Feedback Review (Weekly sync up)

o Backlog Refinement and Feedback

 Gather feedback from stakeholders and end-users to

update requirements as necessary.

 Review backlog items and reprioritize based on new

information, user feedback, or strategic changes.

 Document lessons learned in each sprint to ensure

process improvement in future cycles.

6. Quality Assurance

o Defects and Issues Management

 Review defects, assigning them to appropriate teams

(BA or DEV) as needed.

 Monitor defect resolution status and ensure timely

updates in JIRA.

 To ensure the summary email is sent everyday from QA

Checklist for Business Analysts

 Statu
Checklist Item
s

Weekly sync-up call held with PO, PM, Design

[]
team

Requirements defined, reviewed, and added

[]
to JIRA

Sprint goals and user stories reviewed with

[]
DEV & QA

Release notes prepared and uploaded []

User guide updated []

Production readiness email sent []

Daily JIRA updates completed []

Summary email sent (if required) []

MOM sent after each planning/review

[]
meeting

Peer review of BA work completed []

Areas and Scenarios for BA Involvement

1. Requirement Gathering and Definition

 When: During the initial project discussions, backlog refinement,

and sprint planning sessions.

 Involvement: The BA should collaborate with the Product Owner

(PO), Project Manager (PM), and stakeholders to capture, define, and
prioritize requirements.

 When to Reach Out to BA:

o When any department (especially the design or development

team) needs clarification on user stories, features, or business
goals.

o When any new requirements or changes to existing

requirements arise.

2. Backlog Management and Refinement

  When: Regularly scheduled backlog refinement meetings and
ongoing backlog maintenance.

 Involvement: The BA should continuously refine the backlog by

updating priorities, user stories, and dependencies based on
feedback from other departments.

 When to Reach Out to BA:

o Before each sprint, to understand the requirements for

upcoming tasks.

o When there are questions on priority or if any dependencies

are unclear.

3. Sprint Planning and Kick-Off

 When: At the start of each sprint.

 Involvement: The BA should align with the DEV, QA, and PM teams
on sprint goals, ensuring each requirement is clear and actionable.

 When to Reach Out to BA:

o During sprint planning sessions to clarify user stories,

acceptance criteria, and dependencies.

o If any department has questions on the feasibility or technical

constraints of requirements.

4. Development and Testing Support

 When: Throughout the sprint cycle as developers and testers work

on requirements.

 Involvement: The BA should be available to provide support,

answer questions, and make any necessary adjustments based on
DEV and QA feedback.

 When to Reach Out to BA:

o If the development team encounters issues interpreting

requirements or implementing specific features.

o If QA needs clarification on acceptance criteria or test cases

for specific user stories.

5. Change Management and Requirement Adjustments

 When: Any time a change in requirements, scope, or priorities is

identified.
  Involvement: The BA should review and validate change requests,
update the backlog, and communicate these changes across
departments.

 When to Reach Out to BA:

o If any department receives feedback from stakeholders that

may affect current requirements.

o When there is a need to assess the impact of changes on the

project scope, timeline, or resources.

6. User Acceptance Testing (UAT) Preparation and Support

 When: During the final stages of a sprint or before a release.

 Involvement: The BA should prepare UAT documents, support UAT

sessions, and ensure that acceptance criteria are met.

 When to Reach Out to BA:

o If QA or stakeholders need support in defining or conducting

UAT.

o When issues are encountered during UAT that require

immediate clarification or adjustment of acceptance criteria.

7. Release Preparation and Documentation

 When: Prior to any production release.

 Involvement: The BA should prepare release notes, update user

guides, and ensure documentation is complete for the release.

 When to Reach Out to BA:

o If any department (e.g., DEV, QA, or Operations) needs

clarification on what’s included in the release.

o For final sign-off or confirmation that all release-related tasks

(requirements, user guides) are completed and ready for
production.

8. Post-Release Review and Feedback Gathering

 When: After a release has been deployed to production.

 Involvement: The BA should gather feedback from users,

stakeholders, and other departments to improve future
requirements and processes.

 When to Reach Out to BA:

 o If any team encounters issues or receives feedback from end-
users that may affect future releases.

o When discussing lessons learned to refine requirements,

backlog management, or team collaboration.

9. Cross-Department Communication and Documentation

 When: Throughout the project lifecycle.

 Involvement: The BA is responsible for ensuring that

documentation (requirements, user stories, acceptance criteria) is
clear, updated, and accessible to all departments.

 When to Reach Out to BA:

o If any department needs access to requirement

documentation, templates, or guidelines.

o When clarifications are needed regarding previously

documented requirements or project history.

Summary Table of Scenarios

Scenario When to Involve the BA

During initial discussions, backlog

Requirement Gathering and
refinement, or if requirements need
Definition
clarification or updates

Backlog Management and Before each sprint and whenever new

Refinement dependencies or priority questions arise

Sprint Planning and Kick-Off At the start of each sprint or when there are
questions on user stories and acceptance
Scenario When to Involve the BA

criteria

Development and Testing Throughout the sprint for any requirement-

Support related issues or clarifications

Change Management and When new changes arise or impact

Requirement Adjustments assessment of changes is required

User Acceptance Testing Before release for support with UAT

(UAT) planning, execution, and criteria alignment

Release Preparation and Prior to production release for release

Documentation notes, user guide updates, and final sign-off

Post-Release Review and After release to gather user feedback or

Feedback Gathering address any new issues

Cross-Department Throughout the project lifecycle for

Communication and documentation access, updates, or
Documentation clarification