top of page
DiiTUK Consulting
EUROPE | UK | CANADA | AFRICA | UAE
WELCOME TO THE ROLES AND RESPONSIBILITIES OF A
JUNIOR- MID LEVEL BUSINESS ANALYSTS
The business analyst is the person who serves as the link between the business (Stakeholders) and the development team.
The business analyst gets information (requirements from the stakeholders) and passes on the requirements to the developer.
What are the key roles & responsibilities of a business analyst on a project?
A. Waterfall Project
Step 1: Once the BA has been officially assigned to a project to be delivered using the waterfall methodology approach, the BA is meant to confirm what deliverable/ documents they are expected to create as well as the delivery date for each requested document from the Project Manager. The BA is also to get the stakeholders list from the Project Manager.
Examples of such document could includes: a Scope of Work (SoW), a Business Requirement Document (BRD) or a Requirement Catalogue, one or various Process Flow Diagrams.
Step 2. The next step will be for the BA to get in touch with these stakeholders via email introducing themselves and commence their stakeholder management. This is to enable the BA to know the best way to commence engaging with the business through the key stakeholders.
Step 3: After ensuring the method of engaging with the stakeholders has been established, the next step will be to commence booking/ scheduling requirement gathering meetings or process flow gathering meetings in the calendars of the stakeholders. When this activity is done, a follow-up call/ email is put forward to ensure they are okay with the meeting time scheduled and they are comfortable accepting the meeting invites.
Step 4: Before the requirement/ process gathering meeting commences, the BA is to prepare a set of questions with the intention of asking these questions to the stakeholders. The response from the stakeholders is to be documented as the requirements or the step-by-step journeys in the process flow diagram.
Step 5. After the meeting, the BA will go back to their desk/ laptop/ desktop and begin producing the requirement/process flow description captured in the meeting in the correct format. the requirement documented in the BRD or Requirement Catalogue needs to follow SMART technique. The SMART technique ensures that the requirements are S= Simple, M= Measurable, A= Achievable, R= Relevant and T= Time bound.
In summary, the BA is to ensure that each detailed requirement is simple and specific enough for the developer to understand that requirement. This requirement gathering and documentation step is continuous and only comes to an end if all requirements for the entire project is completed.
Step 6. After all the requirements/ process flow diagrams have been elicited and documented, it's the BA duty to have a walkthrough sessions/ meeting with key stakeholders. The purpose of this walkthrough session is to go over all requirements captured in the BRD/ Requirement Catalogue or the process flow diagram created to ensure no requirement/ process flow step is omitted or mis-interpreted, and to seek/ gain the approval of the document.
It is the approved document that is handed over to the developer at this stage.
Step 7. Once the BRD or Process flow document is completed, its the BA's duty to have another walkthrough session with the developer to go over the approved document. Here, the BA send an email to the developer notifying them that the BRD or Process Flow diagram is completed and you will like to go over the document with them to ensure they have clarity and understand what they are about to build/code for the project.
Note: It is the requirement documented by the BA that the developers work with. If the requirements are not clear, the developer will struggle to read your document and they would always have to call your attention to each un-clear requirement at all times.
To avoid this, the walkthrough session with the developers is always recommended.
What are the key roles & responsibilities of a business analyst on an Agile project?
To understand what is been discussed in this section, it is recommended that you must have gone through the BA Jargons module. It's a free module for all. To visit the BA jargon page, click here.
B. Agile Project (Scrum)
Step 1: Once the BA/ Product Owner has been officially assigned to a project to be delivered using the Agile ways of working, aside from the capturing/ documentation of User Stories & Acceptance Criteria, the BA who is also the Product Owner is meant to confirm from the Product Manager what additional deliverable/ documents they are expected to create. The Product Owner is also to get the stakeholders list from the Product Manager.
Examples of the additional document may include: a Scope of Work (SoW), and one or more Process Flow Diagrams.
Step 2. The next step will be for the Product Owner to get in touch with these stakeholders via email introducing him/herself to commence stakeholder management. This is to enable the Product Owner know the best way to commence engaging with the stakeholders.
Step 3: After ensuring the method of engaging with the stakeholders has been established, the next step will be to commence booking/ scheduling requirement gathering meetings or process flow gathering meetings in the calendars of the stakeholders to capture the User Stories & Acceptance Criteria for each sprint. When this activity is done, a follow-up call/ email is put forward to ensure they are okay with the meeting time scheduled and they are comfortable accepting the meeting invites.
Part of the Agile ceremonies is the daily stand-ups. At this point a sprint (SPRINT 1) has been planned and for each day of SPRINT 1 there would be the daily scrum meeting.
Step 4: Before the user story and acceptance criteria/ process mapping meeting commences, the Product Owner is to prepare a set of questions with the intention of asking these questions to the stakeholders.
There will be EPIC STORIES assigned to the Product Owner. The guide which helps the Product Owner know the types of questions to ask the stakeholders will be based on the objective of that particular planned sprint which will be based around the allocated EPIC STORY for that particular sprint (SPRINT 1).
The response from the stakeholders is to be captured and documented as the user story and acceptance criteria by the Product Owner This is still done within SPRINT 1.
Step 5. After the meeting, the Product Owner will go back to their desk/ laptop/ desktop and begin documenting the user stories and acceptance criteria into JIRA/process flow description captured in the meeting in the correct format. The User Stories & Acceptance Criteria would be documented into JIRA and to ensure that the User Stories are good User Stories, they must:
i). They must have the 3 Ws= Who, What and Why
ii) They must have acceptance criteria
iii). They must be documented using the SMART technique. The SMART technique ensures that the requirements are S= Simple, M= Measurable, A= Achievable, R= Relevant and T= Time bound.
In summary, the Product Owner is to ensure that in each sprint (SPTINT 1), all user stories produced is simple and specific enough for the developer to understand. The documentation of the user stories and acceptance criteria documentation into JIRA is a continuous process for each sprint.
Also, for the duration of each sprint, the Product Owner is to attend the Daily Stand-Up/ Scrum Ceremonies alongside other team members (product managers, other product managers, developers, test analyst).
Step 6. After all the user stories and acceptance criteria have been elicited and documented for a SPRINT 1, it's the product owners duty to have a walkthrough sessions/ meeting with key stakeholders. The purpose of this walkthrough session is to go over all user stories/ acceptance criteria captured or the process flow diagram created to ensure no user story and acceptance criteria/ process flow step is omitted or mis-interpreted, and to seek/ gain the approval of the user story list. It is the approved user story list that is handed over to the developer at this stage.
Note: The act of capturing the user stories/ acceptance criteria and the completion of the user stories/ acceptance criteria is all done within a sprint (e.g SPRINT 1).
Step 7. Once the user story & acceptance criteria or Process flow document is completed for SPRINT 1, its the product owner duty to have another walkthrough session with the developer (requirement refinement call) to go over the approved document. Here, the product owner can notify the product manager, send an email to the developer and test analyst notifying them that the user stories and acceptance criteria or Process Flow diagram is completed and you will like to go over list with them to ensure they have clarity and understand what they are about to build/code for the project. All of these ceremonies is till done within SPRINT 1.
Once the user stories and acceptance criteria are completed, and the requirement refinement call is also completed with the developers and test analyst, the developer will build/ code. The test analyst will tests all that has been built by the developer for that sprint 1.
After the completion of the testing, the development team comes together to perform another ceremony called RETROSPECTIVE.
The retrospective ceremony is simply for the development team to critically analyse that product/ feature that has been built in that sprint (SPRINT 1). This is to ensure that the team inspects the feature or product before it is shown to the stakeholders.
Once the retrospective for SPRINT 1 is completed, the next activity/ ceremony is called DEMOs, SHOW-CASE, or SHOW-N-TELL.
This activity is participated by all the members in the development team working on SPRINT 1 + the key stakeholders. This is to showcase or demo the completed SPRINT 1 to the stakeholders, and to ensure the stakeholders are happy with what has been built.
Once SPRINT 1 has been completed and the stakeholders are happy, then the Product Manager/ Scrum master plans for SPRINT 2. then steps 3 to steps 7 happens again and after step 7 for SPRINT 2 is completed, a new sprint will be planned again called SPRINT 3 and so on and so forth until the entire project is completed.
Note: It is the user stories and acceptance criteria documented by the product owner that the developers work with and the test analyst tests against. If the user stories and acceptance criteria are not clear, the developer will struggle to understand the captured user stories and they would always have to call the attention of the Product Owner each time whenever any user story/ acceptance criteria is un-clear for clarification.
Remember: If there is a need for a developer to always call the attention of the Product Owner to clarify each user story/ acceptance criteria, it means the Product Owner is not producing clear requirement. This is not a good attribute for a Product Owner
To avoid this, the walkthrough session with the developers and test analyst is always recommended.
Did
you
know...
''We are one of UKs Certified & Accredited IT Training
Institution?
You get your very own
IT CPD CERTIFICATE for completing ANY Programs You
Complete''
Now you know, what are you still waiting for?
to Join our next class
bottom of page