A day in the life of an agile Business Analyst

Grayce Analyst, Jessica Smith-Lamkin describes the responsibilities of an Agile Business Analyst and some of her day-to-day activities on client site.

What is an agile Business Analyst?

As Agile continues to become an increasingly popular change delivery method, adopted by more and more organisations, new job titles such as Scrum Master and Product Owner have became more prominent. Similarly, a range of more traditional job titles have incorporated the word 'agile'.

The moniker Agile Business Analyst is generally applied to Business Analysts working in an Agile environment, and because organisations are adopting Agile in a wide variety of different ways, it follows that there are many ways to be an Agile Business Analyst.

A ‘typical’ day as an agile Business Analyst (if there is such a thing!)

I work in an organisation that mostly uses Scrum, as well as some Kanban methods. The change portfolio I work on includes changes of varying size and complexity across multiple different systems, so I am always busy juggling several different projects. As I work as part of the delivery teams, my days vary considerably depending on where we are in the two-week sprint cycle. Sprint Planning, Product Owner Prioritisation, Impact Assessments and Backlog Refinement feature either weekly or fortnightly.

A typical day might look something like this...

The first thing I do is check my calendar, so I know what meetings I have coming that day. I then review my to do list (which I try to always write the day before) to remind myself of things I need to complete in the day ahead. I also try to use this time to catch up on emails that have come in overnight from the offshore development team.

Next, it’s time for the Daily Stand Up. The Stand Up is a cornerstone of Agile change approaches, used to report on work done yesterday, work planned for today and any blockers that may prevent work being completed. I work across two delivery teams so attend two Stand Ups a day and these sessions allow me to both give my own updates and easily keep track of the work different team members are doing.

I was reminded in the Stand Up that one of the testers is waiting for my feedback on some test scripts that have been prepared and that this is blocking a story being moved to ‘done’ on our sprint board. The change has been on the team’s backlog for several months, so I spend some time reminding myself of the details and reviewing my original requirements. The test scripts are mostly fine, but I ask for a few points to be clarified and for a couple of extra test cases to be included.

Late morning, I have a meeting with a business user who has raised a request for change. This is when the Agile BA role is closest to a non-Agile BA role as my focus is on eliciting and analysing business requirements. There are a few details on the request where the business value is less clear, so I ask the requester to confirm some of the finer details. We also discuss options for breaking down the requirements into smaller, manageable tasks suitable for iterative development. If the Product Owner agrees, this should allow us to deliver an MVP (minimum viable product) much faster than if we tried to deliver the complete solution.

Next it’s time for one team’s Sprint Retrospective. We discuss things that went well, and less well, in the Sprint concluding that we were slightly too ambitious in the number of stories we tried to deliver. Lessons learnt are recorded and will be carried forward into our next Planning session so that we avoid making the same mistake again.

Finally, as the day starts to wind down and I know I have no more meetings, I can focus on writing up my notes from earlier. While there are still some questions to be answered, I know enough to start writing the user stories and acceptance criteria that will make up the first iteration of the delivery. As the work will include some changes to customer letters, I prepare a mock up of the proposed change, and also make a note on tomorrow’s to do list to review this with the marketing team who manage all documentation. I also set up a meeting with our team’s solution architect to ensure that the requirements so far are feasible. I record all this information in Jira to ensure there is a full audit trail.

The final thing I do at the end of the day is write up a to-do list for tomorrow so that I am ready to hit the ground running first thing in the morning!

How are agile BAs different from BAs?

Being an Agile Business Analyst means working in a fast-paced environment, where you must be very adaptable to change. This is particularly the case in organisations where the adoption of Agile methods is an ongoing journey, and it can often feel like the landscape is shifting underneath your feet.

You also need to be practical and prepared to be hands on. Working in a delivery team means you are equally responsible for getting stories completed in time, which could mean anything from responding quickly to any queries that come in, to assisting with testing. Finally, as well as the usual skills of business analysis, Agile BAs need to enjoy collaborative, fast-paced working and be prepared to champion Agile approaches throughout the change lifecycle.

Find out more about the Grayce Development Programme