1 Introduction

1.1 Purpose

The purpose of Plan Business Analysis Approach is to define an appropriate method to conduct business analysis activities. To provide transparency in the processes and improve onboarding.

1.2 Approach Definition Criteria

The described approach has been worked out based on the following project context:

1. Project approach:
   The project processes are based on a change-driven methodology. The project operates in a low-competitive market, but it is not in high demand. The product is out-sourced so all the data are public.

2. Stakeholders:
   The main stakeholders are within the organization and depend on the initiative. The full list is here:

3. Documentation:
   Risk is acceptable, people communication over documentation.

4. Other risks and constraints:

   1. The product is open-sourced, so all the data are public by default.

   2. The team members are rapidly changed due to lack of funding.

The above criteria determine the following approach specifics:

• An informal way of documentation, but capturing main initiatives.

1.3 Acronyms, Abbreviations, and Terms

All used acronyms can be found here: Project Glossary

2 Documentation Storage

The main documentation storage is JDN

Meanwhile, tasks description are presented in GitHub: https://github.com/jdi-testing/jdn-ai

2.1 Communication and Information Management Tools

3 Change Management & Version Control

All documentation tasks should be discussed in daily meetings and added to the board. You should log in to the system before making any changes in documents.

3.1 Manage a new initiative

Ideas can arise spontaneously and unplanned. All emerging ideas should be stored at with the contact person of the initiator.

4 Artifacts List & Template

4.1 User Story Specification Template

Description

The description section of the User Story Specification Template provides a concise summary of the user's role, the desired action they want to perform, and the value or benefit they seek to achieve by completing the action. It serves as a high-level overview of the user story.

AS A <user>
I WANT TO <action>
SO THAT <value/benefit>.

Dependencies

The dependencies section outlines any dependencies or prerequisites that need to be in place for the user story to be successfully implemented. This may include user stories or external sources that are necessary for the story to be completed.

Acceptance criteria

The acceptance criteria section defines the specific conditions or requirements that must be met for the user story to be considered complete and accepted by stakeholders. It is presented in a list format with clear descriptions. The preferable format for acceptance criteria is GHERKIN, which follows the structure:

GIVEN <state of the system, enter point>

WHEN <single action>

THEN <result>

Artefacts

The artefacts section includes any design or other relevant artefacts that are associated with the user story. This may include wireframes, mockups, diagrams, or any other documentation that provides additional context or visual representation for the story.

Comments

The comments section allows the team members to provide additional comments or notes related to the user story. This can be used to share insights, suggestions, or any other information that may be helpful for the implementation or understanding of the story.

4.2 Task Template

Description:

The description section of the Task Template provides a clear and concise explanation of the task at hand. It outlines what needs to be done in a specific task and provides enough information for the team members to understand the scope and requirements of the task.

Definitions of Done:

The Definitions of Done section outlines the criteria or conditions that must be met for the task to be considered complete. It defines the specific outcomes or deliverables that need to be achieved for the task to be considered done. This may include factors such as code review, testing, documentation, and any other relevant criteria.

• DoD1

• DoD2

Dependencies or related tasks:

The dependencies section outlines any dependencies or prerequisites that need to be in place for the task to be successfully completed. This may include dependencies on other tasks, resources, or external factors that are necessary for the task to be finished.

Comments:

The comments section allows team members to provide additional comments or notes related to the task. This can be used to share progress updates, raise questions, provide insights, or any other relevant information related to the task. It helps in facilitating communication and collaboration among team members.

4.3 Features List Template

Presented here:

• User Story ID: The User Story ID field is a unique identifier assigned to each user story. It helps in tracking and referencing specific user stories within the feature list.

• Date Created: The Date Created field indicates the date when the user story was initially created or added to the feature list. It helps in establishing a timeline and understanding the order of user story creation.

• Name: The Name field represents the concise and descriptive title or name of the user story. It provides a clear identification of the user story within the feature list.

• Description: The Description field provides a detailed explanation of the user story, outlining its purpose, functionality, and desired outcome. It helps in understanding the scope and requirements of the user story.

• Status: The Status field indicates the current state or progress of the user story.

• Dependencies: The Dependencies field outlines any dependencies or prerequisites that need to be fulfilled for the user story to be implemented or completed. It helps in identifying any external factors or tasks that are required for the user story's success.

• Comments: The Comments field allows team members to provide additional comments, notes, or updates related to the user story. It serves as a platform for collaboration, communication, and sharing important information or insights regarding the user story.

4.4 Epics List Template

Presented here:

4.5 Meeting Notes Template

Presented here:

Title: [Meeting Date: DD/MM/YYYY] [Meeting Name/Title]
Agenda:

• [Agenda item 1]

• [Agenda item 2]

• [Agenda item 3]

• ...

Open Questions:

1. [Question 1]

   • [Additional details or context]

2. [Question 2]

   • [Additional details or context]

3. [Question 3]

   • [Additional details or context]

[Additional agenda items or open questions can be listed here]

Meeting Summary: [Include a summary of the key discussion points, decisions made, and action items assigned during the meeting.]

Next Steps:

1. [Action item 1]

   • [Assigned to: Name]

   • [Due date: DD/MM/YYYY]

   • [Additional details or context]

2. [Action item 2]

   • [Assigned to: Name]

   • [Due date: DD/MM/YYYY]

   • [Additional details or context]

Attachments: [Include any relevant documents, presentations, or additional resources shared during the meeting.]

Comments: [Additional notes or comments can be added here, if necessary.]

5 Stakeholders Engagement

If a new stakeholder appears, elicit enough information about the stakeholder approach and add it to the table:

The following table can be used to capture key information and effectively engage with stakeholders:

Please complete the table by adding stakeholders' information as follows:

1. Name: The stakeholder's full name.

2. Title: The stakeholder's job title or position.

3. Project Role: The specific role the stakeholder plays in the project.

4. Key Responsibility: The primary responsibilities or tasks the stakeholder is accountable for.

5. Company: The name of the stakeholder's organization or company.

6. Location: The physical location or office where the stakeholder is based.

7. Contact Details: The contact information for the stakeholder (e.g., email address, phone number).

8. Action and Communication: The planned actions and communication strategies for engaging with the stakeholder.

9. Current Status, Impact and Interest: The stakeholder's current status or involvement in the project, their potential impact on the project's success, and their level of interest.

10. Desired Support: The specific support or contributions expected from the stakeholder.

11. Communication Approach (from Power/Interest Grid)*: The communication approach based on the stakeholder's power and interest level (e.g., keep informed, consult, involve, manage closely).

12. Comment: Any additional comments or notes related to the stakeholder.

Remember to update the table when new stakeholders appear, ensuring you elicit enough information about their approach and add it to the respective columns.

• The Power/Interest Grid is a tool used to determine the appropriate level and type of stakeholder engagement based on their power (influence) and interest in the project.

6 Requirements Management

TBD

7 Communication Plan

7.1 Roles and responsibilities

All critical business stakeholders can be found here: Please, ask for access @Valeriia Savinova

Project Team Members are listed here:

7.2 Communication Matrix