EUROPE | UK | CANADA | AFRICA | UAE

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