What Does a Business Analyst Actually Do? A Day-by-Day Breakdown
Job descriptions for business analysts are written in a language nobody actually speaks. "Bridge the gap between business and IT." "Drive organizational change." "Translate requirements into actionable solutions."
Accurate? Technically. Useful for understanding what the work feels like? Not remotely.
If you are considering a career in business analysis, you deserve better than corporate abstractions. Here is what a real BA's week looks like on a mid-sized project, a returns processing system overhaul at a retail company with about 400 employees and a $900,000 budget.
Monday: Stakeholder Alignment
The week starts with catching up on messages that arrived over the weekend. A product manager has questions about a requirement you documented Friday. A developer has flagged an edge case in the refund workflow that your specification does not cover. The VP of Operations wants to add a reporting feature that was not in the original scope.
Your morning meeting has six people in it, each with a different version of "what we need." The product manager wants speed to market. The compliance team wants audit trails on every transaction. The sales lead wants something they can demo to clients next month. The CTO wants minimal technical debt.
Your job is not to decide who wins. Your job is to document what everyone wants, identify where those wants conflict, and surface the trade-offs clearly enough that the right people can make informed decisions. After the meeting, you spend an hour updating your stakeholder map, the document that tracks who has influence, who has interest, and what each person actually cares about beneath the surface of what they said in the meeting.
One thing you learn quickly in this role: what people say in a group meeting and what they tell you privately afterward are often different. The stakeholder map is your cheat sheet for navigating that gap.
Skills at work: stakeholder management, facilitation, active listening, conflict identification.
Tuesday: Elicitation Deep Dive
Tuesday is focused elicitation. Three one-on-one interviews with subject matter experts, the people who actually do the work that is about to change.
The first interview is with a warehouse supervisor whose team processes returns. You ask open questions: "Walk me through what happens when a return arrives at the dock." "What takes the longest?" "Where do things break most often?" You resist the urge to suggest solutions. Right now, your job is to listen and understand, not to fix.
Between interviews, you organize your notes into themes. Three different people have mentioned the same bottleneck: the returns system does not communicate with the inventory system, so staff manually update two databases every time a product comes back. Nobody flagged this in the project brief because it is so embedded in their daily routine that they forgot it was a problem. This is why observation and interviews catch things that requirements documents miss.
The afternoon is spent reviewing existing documentation: the current system specs, last year's process audit report, and a spreadsheet the operations team built as a workaround for a limitation the vendor never fixed. That spreadsheet is a requirements document in disguise. Every workaround is.
Skills at work: elicitation (interviews, document analysis), analytical thinking, documentation.
Wednesday: Requirements Writing
Wednesday is heads-down writing. Based on Monday's stakeholder meeting and Tuesday's interviews, you draft requirements as user stories with acceptance criteria:
As a returns processing clerk, I want to scan a return barcode and see the original order details automatically, so that I do not have to search two separate systems to process the return.
Acceptance criteria:
- Scanning a barcode displays: order number, customer name, items ordered, return reason
- Results appear within 2 seconds
- If barcode is unreadable, system shows manual lookup option
You write twelve stories by lunch. Each one is specific, testable, and tied to something a real person told you they needed.
In the afternoon, you document three business rules, the non-negotiable constraints the system must enforce regardless of what any user prefers:
BR-04: Refunds above $500 require manager approval before processing.
BR-05: Return requests submitted more than 90 days after purchase are automatically declined.
BR-06: Defective items must be routed to quality assessment, not returned to inventory.
Business rules are the law of the system. Features are negotiable. Rules are not. Keeping that distinction clear in your documentation saves weeks of confusion later.
Skills at work: requirements writing, user story formatting, business rules documentation.
Thursday: Process Modeling and Review
Thursday morning, you map the current returns process step by step using a flowchart tool. Every decision point, every handoff between teams, every manual workaround. This is the "as-is" model. Then you draft the "to-be" model, the process after changes. The manual database updates are gone. Barcode scanning is added. The approval workflow is automated for refunds under $500.
Comparing the two models side by side reveals exactly what changes and where the value is created. This visual comparison is far more persuasive in meetings than a bullet-point list, because stakeholders can point at a specific step and say "wait, that is not how we do it" in a way they cannot do with a paragraph of text.
The afternoon is a requirements review with the development team. You walk through your user stories and business rules. The lead developer asks sharp questions: "What happens if the barcode scanner is offline?" "Do we need to support partial refunds?" "What is the expected transaction volume per day?"
Some of these questions expose gaps. That is normal and expected. A requirements review that surfaces zero gaps probably was not thorough enough. You note the open items, mark the affected stories as "needs clarification," and schedule follow-ups with the relevant subject matter experts.
Skills at work: process modeling, current-state and future-state analysis, requirements review, gap analysis.
Friday: Documentation and Communication
Friday is for polishing and communicating. You update the requirements document with clarifications from Thursday's review, close out four stories that are now fully specified and ready for development, and write a status update for the steering committee.
The VP of Operations reads this update every Friday afternoon, so you address the scope addition from Monday directly. You have analyzed the impact: two additional sprints and approximately $45,000 in additional development cost. You recommend deferring it to Phase 2 with clear reasoning. This is not a "no." It is a "not yet, and here is why."
You also update the traceability matrix, a document that maps each requirement back to a business objective and forward to a test case. Traceability sounds bureaucratic until the first time a stakeholder asks "why are we building this feature?" and you can point to the exact business need it addresses and the exact test that will verify it works.
Before logging off, you prepare Monday's sprint planning agenda and send it to the team.
Skills at work: documentation, stakeholder communication, prioritization, traceability.
What BAs Do Not Do
The boundaries of the role matter as much as the tasks.
BAs do not write code. You specify what the system should do, not how it is built technically. You do not need to know Python, though understanding basic technical concepts helps you communicate with developers without wasting their time.
BAs do not manage project timelines. That is the project manager's responsibility. You contribute estimates for requirements work, but you are not accountable for the overall schedule.
BAs do not design user interfaces. You define what information needs to be shown and what actions need to be available. A UX designer decides how it looks.
BAs do not make business decisions. You present options with analysis. The stakeholders decide. Your job is to ensure they have the right information to decide well, not to decide for them.
The Tools
A typical BA toolkit: Jira or Azure DevOps for tracking requirements, Confluence or SharePoint for documentation, Lucidchart or Miro for diagrams, Excel for data analysis and traceability matrices, and Slack or Teams for the constant stream of clarification questions that are really the heartbeat of the role.
You do not need to master every tool before starting. Most organizations standardize on one or two, and you learn them on the job. Your ability to structure information clearly matters more than which software you use to do it.
The Skill That Matters Most
If you read one paragraph in this article, make it this one.
The most successful BAs are not the most technical. They are the best communicators. You will spend more time in conversations than in documents. Your ability to ask the right question, listen without planning your response while the other person is still talking, rephrase what someone said to confirm you understood, and diplomatically push back when a requirement does not make sense, these skills determine your effectiveness more than any framework or certification.
Empathy is underrated in BA work. When a warehouse supervisor is frustrated about a system that makes her job harder, she does not want to hear about BABOK knowledge areas. She wants to feel heard. Start there, and the analytical work follows naturally.
The Fastest Way to Know If This Is Right for You
Do not spend three months reading about business analysis to decide if you like it. Spend 90 minutes actually doing it. Work through a case scenario. Read a stakeholder email and identify what is missing. Write your first user story. Map a process flow.
If the work feels natural and engaging, you have your answer. If it feels tedious and abstract, you have saved yourself months of misdirection. Either way, you know.
BAvolta's first module is free and takes about 80 minutes. You will read real stakeholder communications, answer scenario-based questions, and see what the work actually feels like. Start here.