What Does a Business Analyst Do? Three Real Day-in-the-Life Stories

If you ask different people what a business analyst does, you will receive vastly different answers. Some describe it as requirements gathering and documentation. Others emphasize stakeholder management. Many point to data analysis and process improvement as key factors. While all these perspectives hold truth, they only capture fragments of the complete picture.

The reality is more nuanced. Business analyst responsibilities vary significantly based on your work environment, company methodology, and industry sector. Rather than providing another generic job description, this article walks you through a typical day for three different business analysts, each working in distinct environments. You will see their actual workflows, the tools they use, and the challenges they navigate.

Story #1: Sarah – Agile Business Analyst in Fintech (Remote Work Environment)

Sarah is a mid-level business analyst working for a fast-growing fintech startup. She specializes in payment processing solutions and works entirely from her home office in Austin. Her company follows Scrum methodology, which means her daily routine revolves around sprint cycles, constant collaboration, and rapid iteration. Unlike traditional environments, Sarah’s world moves at a rapid pace. Requirements change weekly, sometimes daily. Stakeholders expect quick turnarounds. The development team needs immediate clarification.

This is what a typical Wednesday looks like for her.

Morning: The Sprint Rush (7:30 AM to 12:00 PM)

7:30 AM: Sarah wakes up and does something she knows she probably should not do. She checks Slack before making coffee. Three messages from the product owner. Two developers encountered issues overnight. One from the QA lead asking about acceptance criteria. Her brain instantly switches into work mode.

She grabs her laptop, makes that much-needed coffee, and starts triaging messages. The product owner wants to discuss a new feature request from a major client. The developers need clarification on a user story from the current sprint. The QA lead has identified an edge case that was overlooked during the planning process.

8:45 AM: After responding to urgent messages, Sarah opens her calendar using Google Calendar. Today looks packed. Six meetings. She has maybe two hours of actual focus time squeezed between calls. Welcome to the life of an agile business analyst.

She spends the next thirty minutes preparing for the morning standup by opening JIRA to review yesterday’s progress and checking which user stories are in progress, blocked, or need her attention. She updates her own tasks and makes detailed notes about potential questions developers might raise during the meeting.

9:00 AM: Daily standup time. Sarah joins the Zoom call. The entire team is there. Developers, QA engineers, the product owner, and the Scrum master. Everyone shares what they did yesterday, what they plan to do today, and any blockers they face. The meeting lasts exactly fifteen minutes, just like it should.

One developer mentions confusion about the authentication flow for a new feature. Sarah makes a mental note. That needs immediate attention after this call. Another developer says they finished a story, but need Sarah to validate it before moving it to QA. Add that to the list.

9:20 AM: The standup ends, and Sarah immediately messages the confused developer to set up a quick call. She shares her screen, opens Lucidchart, and walks through the process flow diagram she created last week, carefully pointing out the specific authentication steps and clarifying the relevant business rules. The developer understands the requirements now, and they solve the problem in just ten minutes.

9:30 AM: User story refinement session with the product owner. This is where Sarah shines. They review stories planned for the next sprint. The product owner explains what the business needs. Sarah asks probing questions.

Why does the user need this feature? What problem does it solve? What happens if they cannot complete this action? Are there any regulatory requirements? What is the expected volume?

She takes notes in Confluence while they talk. As the product owner describes the requirements, Sarah starts mentally breaking them down. This feature will need at least three user stories. Maybe four if they want to handle all the edge cases correctly.

10:30 AM: Sarah finally gets some focus time. She needs to write user stories for the next sprint. Opens JIRA and starts crafting them. Each story follows the standard format her team uses.

As a payment processor, I want to validate bank account numbers before processing transactions, so that we reduce failed payment attempts.

She adds acceptance criteria and lists out the specific conditions that must be met for the story to be considered complete, then links related stories and adds labels for easy filtering. She attaches mockups from the design team, stored in Figma, and estimates story points based on their complexity.

Before she knows it, forty-five minutes have passed, and she has created five detailed user stories, though they still need review before sprint planning tomorrow.

11:45 AM: Sarah switches back to Confluence to update the sprint planning documentation, where she creates an agenda for tomorrow’s meeting, lists the stories to be discussed, and adds notes about dependencies and risks before uploading the latest version of the product roadmap.

Afternoon: Collaboration and Documentation (12:00 PM to 5:30 PM)

12:00 PM: Lunch break arrives, though it becomes more of a working break as Sarah microwaves leftovers while scrolling through JIRA tickets on her phone. She notices two bugs assigned to her for triage and realizes she will need to review them after lunch to determine whether they are actual bugs or simply misunderstood requirements.

1:00 PM: Sprint planning meeting. This is the big one. The whole team gathers to decide what they will commit to for the next two weeks. Sarah presents each user story she prepared. The team asks questions. Developers provide technical input. QA raises concerns about testability.

One story generates significant debate because the technical approach is unclear, and security implications need careful consideration. Sarah suggests splitting it into two stories, with one focusing on the happy path and another handling error scenarios. The team agrees with this approach, and she makes the changes in JIRA during the meeting.

Two hours later, they have a solid sprint backlog. Everyone knows what they are building and why it matters.

3:00 PM: The stakeholder demo begins, where the team showcases the work they completed in the last sprint. Sarah helps run the demo using Zoom screen sharing, shows the new payment reconciliation dashboard, walks through user workflows, and explains how the new features solve specific business problems.

Stakeholders generally respond positively to most aspects they see, although they naturally provide feedback on specific elements. One feature requires a minor adjustment, while another could benefit from more explicit error messages, and Sarah captures everything in Confluence, knowing that these will become new stories or modifications to existing ones.

4:00 PM: Sprint retrospective. The team reflects on what went well and what could improve. Sarah facilitates the discussion using Miro, a digital whiteboard. Everyone adds sticky notes. What worked? What did not? What should we try in the next sprint?

The team identifies a recurring issue where user stories sometimes lack sufficient detail about data validation rules, and Sarah commits to creating a validation checklist template that ensures she captures all necessary information upfront in future sprints.

4:30 PM: Finally, some quiet time arrives for Sarah to update Confluence documentation. She adds screenshots from today’s demo, updates the product roadmap to reflect new priorities, creates that validation checklist she promised, and documents the key decisions made during sprint planning.

5:00 PM: Email and Slack catch-up time begins as Sarah faces seventeen unread Slack messages and twenty-three emails. She goes through them methodically, responding to questions, delegating tasks, scheduling follow-up meetings, and marking items for tomorrow’s attention.

5:30 PM: Sarah logs off for the day or, instead, closes her laptop, though she keeps Slack notifications active on her phone just in case something urgent comes up. In the fintech world, urgent matters arise frequently enough that staying somewhat connected feels necessary.

Story #2: Marcus – Waterfall Business Analyst in Healthcare (Hybrid Work Model)

Marcus is a senior business analyst working for a large healthcare organization implementing a new electronic health records system. His company follows the traditional waterfall methodology, where projects move through distinct phases with formal approval gates. Marcus works a hybrid schedule, spending Mondays, Wednesdays, and Fridays in the office while working remotely on Tuesdays and Thursdays. His business analyst role emphasizes comprehensive documentation, structured stakeholder interviews, and detailed planning prior to the start of development.

Morning: Documentation and Stakeholder Engagement (8:00 AM to 12:30 PM)

8:00 AM: Marcus arrives at the office after his commute and settles into his cubicle. He starts by checking Microsoft Outlook for overnight emails, prioritizing urgent items from the project manager and clinical stakeholders. His calendar shows three scheduled meetings today, leaving substantial blocks for focused documentation work.

8:30 AM: With coffee in hand, Marcus opens the Business Requirements Document he has been developing for the past two weeks using Microsoft Word. This comprehensive document will capture all functional and non-functional requirements for the patient registration module. He reviews the section on data validation rules, adding details from last week’s stakeholder interviews and referencing the requirements traceability matrix he maintains in Excel.

10:30 AM: Scheduled interview with clinical stakeholders begins in the conference room. Marcus brings his laptop with OneNote open to capture detailed notes. He asks carefully prepared questions about current workflows, pain points, and desired improvements. The head nurse explains how registration errors impact patient care, while the billing manager discusses insurance verification requirements. Marcus documents everything, knowing these insights will inform multiple sections of the BRD.

11:30 AM: Back at his desk, Marcus processes the interview notes while details remain fresh. He updates the requirements traceability matrix in Excel, linking new requirements to business objectives and mapping them to future test cases. He also updates his stakeholder analysis document, noting key concerns and approval requirements for the upcoming requirements review meeting.

Afternoon: Analysis and Cross-Functional Collaboration (12:30 PM to 6:00 PM)

12:30 PM: Lunch in the company cafeteria provides networking opportunities. Marcus catches up with colleagues from other departments, building relationships that prove valuable when he needs information or approvals later.

1:30 PM: Requirements review meeting with IT architects and database administrators. Marcus presents the data flow requirements using diagrams created in Microsoft Visio. The architects question whether the proposed integration approach aligns with the organization’s technical standards. Marcus takes notes in OneNote, agreeing to research alternative integration patterns and update the technical requirements section accordingly.

3:00 PM: Focus time for creating process flow diagrams. Marcus opens Visio and begins mapping the current patient registration process, documenting each step, decision point, and handoff between departments. He uses BPMN notation to ensure consistency and clarity. These diagrams will be included as appendices in the BRD and will serve as training materials later.

4:00 PM: Meeting with the QA manager to discuss test scenarios for the registration module. Marcus walks through each requirement, explaining expected behaviors and edge cases. Together, they identify scenarios requiring detailed test scripts. The QA manager asks clarifying questions, and Marcus realizes he needs to add more specificity around error handling requirements. He makes notes to update the BRD before the formal review next week.

5:00 PM: Project status meeting with the project manager. They review the project schedule using Microsoft Project, discussing progress against milestones. Marcus reports that requirements gathering is ninety percent complete, with the formal requirements review scheduled for next Tuesday. They discuss risks around stakeholder availability and agree on mitigation strategies.

5:30 PM: Marcus finalizes meeting minutes from today’s sessions using Word and distributes them via Outlook to all attendees. He updates action items in his task tracker, ensuring nothing falls through the cracks. Before leaving, he schedules two follow-up meetings for next week and blocks time on his calendar for uninterrupted BRD writing.

6:00 PM: Marcus packs up his laptop and heads home, knowing tomorrow will be a remote work day focused on deep documentation work without meeting interruptions.

Story #3: Priya – Senior Business Analyst in E-commerce (Office-Based)

Priya is a senior business analyst at a major e-commerce company, leading initiatives that impact millions of customers. With eight years of experience, her business analyst responsibilities extend beyond requirements gathering to include strategic planning, mentoring junior analysts, and presenting directly to executive leadership. She works from the company headquarters five days a week, where face-to-face collaboration remains valued for complex projects. Her work blends data analysis, customer behavior insights, and cross-functional leadership.

Morning: Strategic Work and Mentorship (9:00 AM to 1:00 PM)

9:00 AM: Priya arrives at the office and settles into her workspace in the open floor plan. She begins by reviewing overnight metrics in Google Analytics and the company’s internal dashboard, which is built on Tableau. Customer conversion rates dropped slightly over the weekend, and she makes a note to investigate potential causes during her analysis time later today.

9:15 AM: Mentoring session with junior BA Maya begins in a small conference room. Maya has prepared a draft requirements document for a new checkout feature, and Priya reviews it while providing constructive feedback. She explains how to write more testable acceptance criteria and suggests restructuring the document to highlight its business value better. Priya shares lessons from her own early career mistakes, helping Maya understand the thinking process behind practical business analysis.

10:00 AM: Cross-functional workshop with marketing, sales, and IT teams to discuss the upcoming holiday season strategy. Priya facilitates the meeting using Miro on the large screen, where participants add ideas and concerns in real time. The marketing team wants personalized product recommendations, sales need better inventory visibility, and IT raises concerns about system capacity. Priya captures everything, identifying common themes and potential conflicts that will require resolution. She uses Microsoft Teams to share the workshop notes immediately after.

11:30 AM: Back at her desk, Priya opens Tableau to analyze customer behavior data from the past quarter. She builds visualizations showing abandonment rates at different checkout steps, filtering by device type and customer segment. The data reveals that mobile users abandon carts at twice the rate of desktop users, specifically during the payment information step. She documents her findings in PowerPoint, knowing this will become part of her executive presentation this afternoon.

12:30 PM: Working lunch meeting with the product team in the executive dining area. They discuss the product roadmap for next quarter while reviewing priorities. Priya presents her preliminary analysis, which identifies the features most likely to have the highest impact on customer retention, based on user research data collected using the UserTesting platform. The product manager agrees to reprioritize two features based on her data-driven recommendations.

Afternoon: Executive Engagement and Strategic Planning (1:00 PM to 6:30 PM)

1:30 PM: Executive presentation to the VP of Digital Experience and other C-suite members. Priya presents her analysis of the mobile checkout problem using PowerPoint slides enriched with Tableau visualizations. She explains not only what is happening, but also why it matters financially, and recommends three potential solutions, along with their implementation complexity and expected ROI for each. The executives ask probing questions about customer segments, competitive analysis, and the feasibility of the timeline. Priya answers confidently, having anticipated most questions during her preparation.

2:30 PM: Following the presentation, the CFO asks detailed questions about the financial projections. Priya pulls up her supporting analysis in Excel, walking through assumptions and showing sensitivity analysis. The executives approve moving forward with her recommended solution and ask for a detailed implementation plan by next week.

3:00 PM: Collaboration session with UX designers on wireframes for the improved mobile checkout flow. They gather around a large monitor as the lead designer shares prototypes from Figma. Priya reviews each screen against the requirements she documented, ensuring the design addresses the identified pain points. She suggests modifications to the error handling flow and requests that specific field labels be more explicit based on customer feedback data. The designers appreciate her input and commit to revised mockups by Thursday.

4:00 PM: Vendor demo evaluation for a new customer analytics platform. Priya joins the evaluation team to watch the demonstration, taking detailed notes in OneNote. She asks specific questions about data integration capabilities, real-time reporting features, and API documentation. After the demo, she provides the procurement team with her assessment of how well the tool meets their documented requirements using a scoring matrix she created in Excel.

5:00 PM: Project status work begins as Priya updates the program roadmap in Microsoft Project, adjusting timelines based on today’s executive decisions. She also updates the risk register, adding new risks around resource availability and third-party dependencies. She sends status reports to key stakeholders via Outlook, highlighting accomplishments, upcoming milestones, and items requiring attention.

6:00 PM: Final hour dedicated to catching up on emails in Outlook and messages in Microsoft Teams. Priya responds to questions from team members, approves a revised requirements document that Maya has updated based on morning feedback, and schedules three meetings for next week. She also spends time planning tomorrow’s agenda, blocking focus time for writing the detailed implementation plan executives requested.

6:30 PM: Priya wraps up her workday, reviewing her task list one final time before heading home. She feels satisfied with the progress made today, particularly the executive approval that will enable significant improvements in customer experience.

The Real Answer to “What Does a Business Analyst Do?”

These three stories reveal something important about the business analyst profession. There is no single answer to what business analysts do, as their work adapts dramatically to the environment. Sarah spends her days in rapid-fire collaboration and lightweight documentation. Marcus invests weeks building comprehensive requirement specifications before any code gets written. Priya balances strategic analysis with executive presentations and team leadership.

Yet despite these differences, common threads connect all three experiences. Every business analyst bridges communication gaps between technical teams and business stakeholders. Each one translates complex requirements into understandable formats, whether user stories, formal documents, or executive presentations. They all spend significant time in meetings because collaboration sits at the heart of this work. Analysis occurs constantly, although it takes different forms depending on the context.

The tools change based on your company and methodology. Your schedule varies based on seniority and work environment. Your documentation style shifts depending on whether you follow agile or waterfall approaches. But the fundamental purpose remains consistent across all variations. Business analysts ensure that technology solutions actually solve real business problems. They ask the questions others forget, spot the gaps that might cause failures, and keep projects aligned with genuine business needs.

Understanding these variations helps you recognize where you might thrive as a business analyst. Some people excel in the fast-paced environment of agile settings, such as Sarah’s world. Others prefer the structured approach Marcus follows, with time for deep thinking and comprehensive documentation. Many aspire to reach Priya’s level, where strategic influence and leadership opportunities expand significantly. The choice depends on your working style, preferences, and career goals rather than which approach is objectively better.

If you are considering this career path, head on over to our pillar article: The $135K Question: What’s a Business Analyst’s Job Description, a dedicated guide on becoming a business analyst.