Roles and responsibilities of a business analyst in a typical agile project
A typical BA workflow for an agile project
When I was trained in Business Analysis, I always tried to join the pieces I had learnt.
I also watched a lot of videos on Youtube about “what a day looks like in the life of a BA” or “how a BA handles every stage of a project”.
But I got the fundamental idea when I actually experienced it in my job role.
Self experiments are a better teacher than anyone else’s tried and tested formulas.
I am talking about this today as I know for a lot of aspiring BAs, it’s always a question as to what roles they have to perform and how.
Hence, this article will walk you through a typical workflow for a BA in an Agile/Scrum project.
Now, there can be 2 possibilities — you enter as a BA either when the project has not even begun or when it is already in progress.
If the project has not yet begun, you may or may not expect some handy documents to get a thorough understanding of what business problem needs to be solved.
If the project is already ongoing, then you can try to find a BRD, FRD or other requirement document that an earlier BA has prepared.
So the initial stage of the project, depending on what situation you face, has to be dealt with accordingly.
The main aim is to get a clear picture of what is happening or going to happen.
Kick-off call
This is nothing but an official announcement of the project initiation.
You have to try hard to understand what business problem is being discussed if that is really discussed in this call.
The extra effort that you can put here is to observe everyone closely and note down the details of important stakeholders for elicitation.
Elicitation
Before this, you can plan how you want to take the requirement-gathering sessions forward and document everything.
The first few calls focus on collecting high-level requirements, which become the features of your product/solution.
The second stage then focuses on the in-depth discussion of each identified feature.
There is no specific timeline on when to do the sessions. It totally depends on how effectively you manage things in advance and the availability of the stakeholders.
Someone from the development team should be there in these calls to understand the requirements and identify technical challenges upfront.
Creation of product backlog
As you start taking requirements during elicitation, it may be required for you to sit with your PM/PO and prepare the product backlog simultaneously.
This is where you’ll dump every requirement in the form of epics, features or user stories into the product backlog.
Release planning
Here, you’re going to identify the features listed in the product backlog according to their priorities so you can add them into release buckets.
Release planning is done before sprint planning, but it usually happens when you see a new release timeline coming in.
Many times, it also occurs that the initial release planning has to be revised as you approach it.
Design & refinement
When you have an idea about what should be done in each release, you’ll start approaching the designers.
They should understand the requirements properly so that a screen/sketch can be built out of it for the dev team to refer to and code.
As the designs get created, you’ll be refining the user stories with acceptance criteria in order to keep everything ready before the actual sprint starts.
Sprint planning
Now is the time to pick the created user stories under the planned release.
Based on the timeline and prioritization that you’ve done, your dev team has to decide on what to add to the sprint backlog.
Sprint starts
Your dev team has started coding according to the user stories you’ve created along with the designs given to them.
There may be a sprint 0 in place before the actual sprints start, in order to build the backbone and architecture of the product/solution.
Daily scrum
Once the sprint starts, every day for 15 minutes, you’ll be on this call.
The scrum master drives it, taking an update from everyone regarding the progress on their tasks towards the sprint goal.
Apart from this, any issue or impediment can be discussed briefly, keeping it within the 15 minutes.
Review & retro meeting
When the sprint is about to end, this session will be scheduled.
You and your PM/PO will be reviewing what the dev team has built over the past sprint and if it matches the user stories and designs.
After this, along with your team, you’ll be discussing what went well and what didn't go well in the previous sprint so that the upcoming ones can be better.
Speak up if you have any action items to resolve those issues.
Testing & demo sessions
After reviewing the sprint work, the functional user stories have to be tested.
You may be required to sit alongside the tester in case they need a functional understanding to test accordingly.
Although it totally depends on how things happen in your company, a project which is huge and has multiple cross-functional teams can plan an additional release demo session to show the built solution as a whole to the external stakeholders.
Repeat, repeat & repeat
The above process is repeated until the product/solution is launched.
Once the launch is done, maintaining the solution and updating it becomes the focus.
You may also be working on the next version of your MVP by following the same process altogether.
Conclusion
I hope the reality check is done as to how a BA gets involved in certain events during the project.
But the picture becomes more clear when you experience the role and get your hands dirty.
You can always connect with me by clicking on the link below to discuss any concerns you have regarding the BA roles and responsibilities.
Follow Bhavini Sapra for more such insights on the BA lifestyle and how you get to live one.
High five!
