A Day in the Life of a Business Analyst – Agile Sprint Planning

Tag along with me to uncover a day in the life of a Business Analyst!

Today I’m going to be showing you what I often do in a typical day and some of the things that are part of my day as a Business Analyst. This is a typical day in the life of a Business Analyst working in tech in an agile environment.

Note: if you are working in waterfall environment, the day will be similar except for all the agile scrum ceremonies.

 

 

A day in the life of a business analyst: Getting to work

Usually at about 8:20AM you’d find me on my way to work. I typically drop off my daughter at her school on the way to my job and then generally I get in around 8:45AM. Since the pandemic, however, I am working from home, so I drop off my daughter at her new school which is 5 minutes from our house, then return to my home to work.

Update: since the pandemic,  I have remained as a  remote worker although there is a new push to go back to the office.

First, check the calendar

Once I’m in, I start my day by checking my calendar to see what’s scheduled.

This is often the case for a day in the life of a Business Analyst, we organize everything through our calendars!

A day in the life of a Business Analyst: Sprint Planning

Today in particular because it’s the end of a sprint, I have preparation for sprint planning as the major event on my calendar. The sprint planning is where we define the goal of the sprint and discuss its user stories. Since I wrote all the user stories in the sprint, I have to be there to clarify any questions during sprint planning.



 

A day in the life of a Business Analyst: Daily Stand-ups

On any other day, I would have been a part of the daily standup. This is where the team gets together usually at 9 AM in the morning and briefly talk about the work they are doing in the sprint and bring up any roadblocks. Today because we have sprint planning, we did not do the standup but we do a sprint retrospective instead.

 

A day in the life of a Business Analyst: Sprint Retrospective

So today being the end of the sprint, we do a sprint retrospective. This is where the team comes together and reflect on the last sprint and typically goes over what they did right, what they need to start doing and what they should stop doing and any action items. If you are working on agile software projects, this is a frequent scrum event in  a day in the life of a business analyst.

In this retrospective, we had a number of things we were doing right and needed to keep doing but there were a few things to stop doing and other things to start doing- for example: we decided we needed to start buffering in more estimation points for new UI elements as they often ended up taking more effort and not getting completed on time.

After the retrospective, we get into the sprint planning ( which is a very long meeting!) Our sprint planning takes up the rest of your morning. By the time I get out of that meeting, it’s time for lunch!

When I used to be at the office everyday, its very centrally located in Atlanta so I had  many restaurant choices. Italian and Mexican are my favorite so that’s where I’d go get a taco  or pizza for lunch. Now that I’m working from home – it’s now all left overs for lunch!

 Requirements Elicitation

 

After lunch, its back to prepping for the next sprint. Our sprints always include a percentage of enhancement requests, bug fixes and new innovations.

For enhancements, I look at the list of enhancements together with the rest of the product team and we discuss and agree on the priority.

Once the product manager signs off on the priority and we discuss the best fixes, then I translate that into user stories. Sometimes I can write the stories right away, sometimes I need to do more research.

Other times I need to engage the UX designers, other times I don’t. For small enhancements I have a lot of wiggle room to make the best judgement call.

On new bigger features, it’s much more structured and I like to get buy-in before I make changes to how the feature will work. I setup several discovery sessions for this. These include workshops, MoSCoW sessions, ideation session, stakeholder interviews etc…

There was heavy UX involvement during the requirements elicitation step. I get buy-in on several key decisions and get sign off on the design and workflow with the UX team and product owner.

This is not all happening on the same day of course, but on any given day I would be involved in the planning and executing of any of these.




Get user stories in Definition of Ready

Once the UX designer completes the design based on my requirements and hands it off to me, I determine how best to break these designs into user stories, what epics we need, I clarify the acceptance criteria and mark the stories as ready for development. This is the definition of ready in agile.

 

 

Hand Off to Scrum Master

From there, I hand off to the scrum master.

I still provide support when the stories are being developed in QA, but from there, the scrum master manages the execution of the sprint and I move on to the next set of enhancements or new features for the next sprint.

 Release Planning

Once the stories are built and tested, I re-engage to help with the release planning.

Since I am the most knowledgeable about the details from the business and technical perspective and I am the subject matter expert on the enhancements and features, I help prepare for the release by reviewing the release documentation written by the tech writer to make sure everything stated is accurate.

I then help with providing the use case context for the release demo done by QA and dev. I also help bring the team together to do all the steps required from the product/dev side to prepare for the release. This includes:

  • getting a high level description of the release items out to marketing to put in the email to our account admins
  • Making sure we communicate to admins in a timely way to match our contractual SLA
  • Sending the information to our customer success team of what made it into the release and what did not, so they can be prepared for customer questions

Again, this can happen over a number of days but are part of the activities I do as a business analyst so you can get a better view into a day in the life of a Business Analyst working on a software project.

 End of Day

Usually by 5 PM my work day ends. Sometimes I keep working based on what I need to finish, but I try to have a  good at work-life balance by knowing when to stop.

Before I end each day though, I make a list of what I need to do the next day, send any follow up meeting invites and respond to any emails or slack messages I haven’t responded to yet.

By now, I’m tired, usually I would jump in my car at the end of the day, turn on my favorite reggae or reggaetón music to go pick up my daughter and then start my other job -as mom. However since I’m remote, I only have a 5 minute drive to pickup my daughter and start my mom job  with my little princess sooner!

That is a typical day in my life as a Business Analyst working in an agile environment in tech in Atlanta.

Share this article if you found it useful!! Thanks – love you!

Read these other articles as well:

Business Analyst Interview Questions

Business Analyst Job Market



2 Comments

Leave a Reply

Your email address will not be published.